Has anyone tried fbdev instead of modesetting as Xorg display driver? I need rotation and I am sure I have gotten this to work before, but not any more… @Koen_Kooi
This is on Angstrom.
/var/log/Xorg.0.log shows some hickups, but does load the driver.
You can’t do rotation in X with xf86-video-fbdev, you have a much better chance with xf86-video-modesetting. Having said that: xf86-video-modesetting doesn’t associate a backlight device with the fbdev, so if you need to dim the screen when X blacks, use xf86-video-fbdev.
If you want rotation I think you’ll have to use kernel commandline arguments.
@Koen_Kooi thanks a lot. I’m not sure how I will solve the dimming yet since it is being controlled through a serial over USB. If you mean to dim the screen as X goes to sleepmode or whatever, that is not that important right now.
Are you saying that if i rotate the screen on the command line (fbcon=rotate:3), that will make it rotated also for X? I was under the impression that that was not the case… If so, I’ll have to look into that again.
I think that should work
According to the documentation it does not change the underlying framebuffer, only the console: https://www.kernel.org/doc/Documentation/fb/fbcon.txt
But ther must be a way to change the orientation of the framebuffer itself… I’ll keep looking. I am running some long simulations now, so I have time : )
Does your screen support internal rotation or reflection? With some LCDs you can change that, the LCD on the LCD7 cape is one example. on the beagleboard version there’s an i2c expander hooked up to the pins that control the rotation, which is why it comes up upsidedown by default due to wrong pullups/pulldowns.
The datasheet for the LCD does mention it, but nothing happened when I tried to activate it. The funny thing is, I have gotten this to work before though using fbdev as driver instead of modesetting, so it should be a piece of cake… http://hipstercircuits.com/problems-with-beaglebone-black-and-their-solution/
Ha! Turns out that the fbdev driver works, but only if there is no “video=” on the command line. My software implemented eeprom is not doing it’s job every time (new hardware rev is submitted, but has not yet arrived) so is there a way to load EDID from sysfs? looks like drm_edid_load.c tries it, but I’m not sure about the format…
@Koen_Kooi I know it’s Friday night and I’m just about to get a brewski, but I am getting a waaay to slow pixel clock on the latest kernel. Have you seen anything like this before? It works with a different display… It’s like 400KHz instead of 25MHz.
3.8 or 3.12rc?
I feel a facepalm is coming…
I know what it is, pico/nanoseconds vs hz. In some of the linux timing code the comment says ‘picoseconds’, but it is in hz. For 33MHz that works out, but not the other way
root@testplatform:~# fbset
mode “480x800-0”
# D: 0.000 MHz, H: 0.000 kHz, V: 0.000 Hz
geometry 480 800 480 800 16
timings 0 0 0 0 0 0 0
accel true
rgba 5/11,6/5,5/0,0/0
endmode
Yes, that’s what I thought! I’ll search through unless you remember which file?
No, but I did find this from the beagle irclogs from 5 years ago:
[12:37:07] <ali_as> Is the fbset pixclock in picoseconds?!
[12:43:08] ali_as: no, not picoseconds
[12:43:28] khz IIRC
[12:45:24] <ali_as> I’m getting a lot of references to,
[12:45:25] <ali_as> -pixclock
[12:45:25] <ali_as> set the length of one pixel (in picoseconds). Note that the frame buffer device may only support some pixel lengths
[12:46:01] used to be picoseconds a few revisions back
[12:46:17] <ali_as> Aha, so this is just out of date documentation. Ok.
[12:46:33] also there is a value used internally that is picoseconds
[12:46:47] forget which struct it is
5 years ago? OK, well this will have to wait for tomorrow… Thanks for your help!
The problem is that the LCDC divisor becomes 1 when it states in the data sheet that it must be =< 2. Adding a test solves the problem, but seems like a dirty hack. @Rob_Clark1 your name is in the file : )