On 12/2/2009 1:59 PM, Eino-Ville Talvala wrote: <snip> >>> >>> Thanks for all the suggestions, but nothing seems to have worked so far. >>> >>> It looks like X picks up all sorts of configuration settings >>> automatically, since xorg.conf is essentially full of 'default internal >>> device' options. What I can't figure out is how it decides on the >>> requested resolution. >>> >>> The defaults, with omapfb.rotate=1 in bootargs, result in omapfb >>> selecting a virtual resolution of 640x480, but Xorg on boot still tries, >>> based on dmesg, to get a 480x640 overlay somehow (at least that's what >>> my interpretation of the situation is). I've tried adding a screen >>> subsection to xorg.confg, with virtual 640 480 - no effect. I've tried >>> adding in a modeline for 640x480, no effect. I tried rebuilding >>> Angstrom with a few extra lines in /conf/machine/omap3evm.conf >>> (MACHINE_DISPLAY_WIDTH_PIXELS=640, etc), with no effect. >>> >>> Does anyone know exactly how Xorg autoconfigures the default panel in >>> this sort of a situation? My current guess is that it's getting 480x640 >>> from some panel driver somewhere, but I haven't been able to find the >>> source. >>> >>> For compleness, I've attached the Xorg log, xorg.conf, and the kernel >>> log when I try to boot up Xorg (just Xorg, no gpe anything). >>> >>> >> check the settings for fb0, fb1 and fb2 with fbset. >> >> regards, >> >> Koen >> >> > r...@omap3evm:~# fbset -fb /dev/fb0 > > mode "640x480-59" > # D: 19.200 MHz, H: 28.614 kHz, V: 59.243 Hz > geometry 640 480 640 480 16 > timings 52083 1 28 1 1 2 1 > accel false > rgba 5/11,6/5,5/0,0/0 > endmode > > r...@omap3evm:~# fbset -fb /dev/fb1 > > mode "640x480-59" > # D: 19.200 MHz, H: 28.614 kHz, V: 59.243 Hz > geometry 640 480 640 480 16 > timings 52083 1 28 1 1 2 1 > accel false > rgba 5/11,6/5,5/0,0/0 > endmode > > r...@omap3evm:~# fbset -fb /dev/fb2 > > mode "0x0-0" > # D: 0.000 MHz, H: 0.000 kHz, V: 0.000 Hz > geometry 0 0 0 0 0 > timings 0 0 0 0 0 0 0 > accel false > rgba 0/0,0/0,0/0,0/0 > endmode > > FB2 is suspicious, since that's what Xorg uses, I believe. Attempting > to set it to something like fb0 and fb1 with: > fbset -fb /dev/fb2 -g 640 480 640 480 16 -t 52083 1 28 1 1 2 1 > made no difference to Xorg, however. I tried upping the amount of > memory allocated to fb2 (I'd forgotten to give it any on the bootargs), > with no luck. So fb0 and fb1 are getting defaults from somewhere, but > fb2 isn't. > > Bootargs currently: > mem=128M console=ttyS0,115200n8 noinitrd rw root=/dev/mmcblk0p2 > rootfstype=ext2 rootwait omapfb.rotate=1 omapfb.vrfb=y omapfb.debug=y > omapdss.debug=y vram=32M omapfb.vram=0:8M,1:8M,2:8M > > Thanks for the suggestion! >
Just in case it would be of use to others later, I did finally find a resolution to this problem. The short story is that the current xf86-video-omafb driver can't handle VRFB rotation, even if it's defined on the kernel command line, because the driver assumes that the output framebuffer is contiguous, which is very much not true with VRFB. There's also a problem with the order in which it reads and writes framebuffer parameters, because with the omapfb driver, the frame buffer fixed info will have to be reread after changing rotation settings or pixel type, as the stride can change. I've hacked up enough of the xf86-video-omapfb driver to get X running in the proper orientation with VRFB and rotation defined on the kernel command line, on the OMAP3 EVM (so X runs at 640x480 on the built-in 480x640 LCD). I haven't gotten the XV extension part of the driver working right yet. If anyone wants the ugly results, I'm happy to share, but I doubt I'll have time to clean them up anytime soon. Thanks, Eino-Ville Talvala Computer Graphics Lab Stanford University -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
