Re: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation
Op 28 dec 2009, om 06:58 heeft Eino-Ville Talvala het volgende geschreven: > On 12/2/2009 1:59 PM, Eino-Ville Talvala wrote: > 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. I'm certainly interested in your patches. Hacky vrfb support is better than no vrfb support :) regards, Koen-- 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
Re: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation
On 12/2/2009 1:59 PM, Eino-Ville Talvala wrote: >>> >>> 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
Re: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation
On 12/2/2009 12:52 PM, Koen Kooi wrote: > Op 2 dec 2009, om 21:02 heeft Eino-Ville Talvala het volgende geschreven: > > >> >> The xorg boot log appears reasonably sane until a crash - 640x480 is what the xf86 omapfb driver picks up, so I assume something else is the problem. I'll try to poke at the omapfb source some to see if something is being passed around wrong - I'd appreciate any suggestions on where to look. === ... (II) LoadModule: "omapfb" (II) Loading /usr/lib/xorg/modules/drivers//omapfb_drv.so (II) Module omapfb: vendor="X.Org Foundation" compiled for 1.6.1, module version = 0.1.1 ABI class: X.Org Video Driver, version 5.0 (II) omapfb: Driver for OMAP framebuffer (omapfb) and external LCD controllers: omap1/2/3, S1D13745, HWA742 (WW) Falling back to old probe method for OMAPFB (II) Running in FRAMEBUFFER Mode (WW) Error opening /sys/devices/platform/omapfb/ctrl/name: No such file or direc tory (WW) Can't autodetect LCD controller, assuming internal (II) LCD controller: internal (II) omapfb(0): VideoRAM: 1920KiB (SDRAM) (--) omapfb(0): Depth 16, (==) framebuffer bpp 16 (==) omapfb(0): RGB weight 565 (==) omapfb(0): Default visual is TrueColor (--) omapfb(0): Virtual size is 640x480 (pitch 640) (**) omapfb(0): Built-in mode "current" (==) omapfb(0): DPI set to (96, 96) (II) Loading sub module "fb" (II) LoadModule: "fb" (II) Loading /usr/lib/xorg/modules//libfb.so (II) Module fb: vendor="X.Org Foundation" compiled for 1.6.1, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.4 (II) omapfb(0): DPMS enabled (II) omapfb(0): Video plane capabilities: (II) omapfb(0): Video plane supports the following image formats: (II) omapfb(0): XVideo extension initialized (==) RandR enabled (II) Initializing built-in extension Generic Event Extension (II) Initializing built-in extension SHAPE (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension BIG-REQUESTS (II) Initializing built-in extension SYNC (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension XC-MISC (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFIXES (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (II) Initializing built-in extension COMPOSITE (II) Initializing built-in extension DAMAGE Backtrace: 0: Xorg(xorg_backtrace+0x28) [0xd2540] Fatal server error: Caught signal 11. Server aborting === >>> Does your xorg.conf enable GLX? You may want to try disabling it. >>> >>> ~sanjeev >>> >>> >>> >> 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
Re: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation
Op 2 dec 2009, om 21:02 heeft Eino-Ville Talvala het volgende geschreven: > >>> The xorg boot log appears reasonably sane until a crash - 640x480 is >>> what the xf86 omapfb driver picks up, so I assume something >>> else is the >>> problem. I'll try to poke at the omapfb source some to see >>> if something >>> is being passed around wrong - I'd appreciate any suggestions on where >>> to look. >>> >>> === >>> ... >>> (II) LoadModule: "omapfb" >>> (II) Loading /usr/lib/xorg/modules/drivers//omapfb_drv.so >>> (II) Module omapfb: vendor="X.Org Foundation" >>>compiled for 1.6.1, module version = 0.1.1 >>>ABI class: X.Org Video Driver, version 5.0 >>> (II) omapfb: Driver for OMAP framebuffer (omapfb) and external LCD >>> controllers: >>>omap1/2/3, S1D13745, HWA742 >>> (WW) Falling back to old probe method for OMAPFB >>> (II) Running in FRAMEBUFFER Mode >>> (WW) Error opening /sys/devices/platform/omapfb/ctrl/name: No >>> such file >>> or direc >>> tory >>> (WW) Can't autodetect LCD controller, assuming internal >>> (II) LCD controller: internal >>> (II) omapfb(0): VideoRAM: 1920KiB (SDRAM) >>> (--) omapfb(0): Depth 16, (==) framebuffer bpp 16 >>> (==) omapfb(0): RGB weight 565 >>> (==) omapfb(0): Default visual is TrueColor >>> (--) omapfb(0): Virtual size is 640x480 (pitch 640) >>> (**) omapfb(0): Built-in mode "current" >>> (==) omapfb(0): DPI set to (96, 96) >>> (II) Loading sub module "fb" >>> (II) LoadModule: "fb" >>> (II) Loading /usr/lib/xorg/modules//libfb.so >>> (II) Module fb: vendor="X.Org Foundation" >>>compiled for 1.6.1, module version = 1.0.0 >>>ABI class: X.Org ANSI C Emulation, version 0.4 >>> (II) omapfb(0): DPMS enabled >>> (II) omapfb(0): Video plane capabilities: >>> (II) omapfb(0): Video plane supports the following image formats: >>> (II) omapfb(0): XVideo extension initialized >>> (==) RandR enabled >>> (II) Initializing built-in extension Generic Event Extension >>> (II) Initializing built-in extension SHAPE >>> (II) Initializing built-in extension MIT-SHM >>> (II) Initializing built-in extension XInputExtension >>> (II) Initializing built-in extension XTEST >>> (II) Initializing built-in extension BIG-REQUESTS >>> (II) Initializing built-in extension SYNC >>> (II) Initializing built-in extension XKEYBOARD >>> (II) Initializing built-in extension XC-MISC >>> (II) Initializing built-in extension XINERAMA >>> (II) Initializing built-in extension XFIXES >>> (II) Initializing built-in extension RENDER >>> (II) Initializing built-in extension RANDR >>> (II) Initializing built-in extension COMPOSITE >>> (II) Initializing built-in extension DAMAGE >>> >>> Backtrace: >>> 0: Xorg(xorg_backtrace+0x28) [0xd2540] >>> >>> Fatal server error: >>> Caught signal 11. Server aborting >>> === >>> >> Does your xorg.conf enable GLX? You may want to try disabling it. >> >> ~sanjeev >> >> > > 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 -- 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
Re: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation
>> The xorg boot log appears reasonably sane until a crash - 640x480 is >> what the xf86 omapfb driver picks up, so I assume something >> else is the >> problem. I'll try to poke at the omapfb source some to see >> if something >> is being passed around wrong - I'd appreciate any suggestions on where >> to look. >> >> === >> ... >> (II) LoadModule: "omapfb" >> (II) Loading /usr/lib/xorg/modules/drivers//omapfb_drv.so >> (II) Module omapfb: vendor="X.Org Foundation" >> compiled for 1.6.1, module version = 0.1.1 >> ABI class: X.Org Video Driver, version 5.0 >> (II) omapfb: Driver for OMAP framebuffer (omapfb) and external LCD >> controllers: >> omap1/2/3, S1D13745, HWA742 >> (WW) Falling back to old probe method for OMAPFB >> (II) Running in FRAMEBUFFER Mode >> (WW) Error opening /sys/devices/platform/omapfb/ctrl/name: No >> such file >> or direc >> tory >> (WW) Can't autodetect LCD controller, assuming internal >> (II) LCD controller: internal >> (II) omapfb(0): VideoRAM: 1920KiB (SDRAM) >> (--) omapfb(0): Depth 16, (==) framebuffer bpp 16 >> (==) omapfb(0): RGB weight 565 >> (==) omapfb(0): Default visual is TrueColor >> (--) omapfb(0): Virtual size is 640x480 (pitch 640) >> (**) omapfb(0): Built-in mode "current" >> (==) omapfb(0): DPI set to (96, 96) >> (II) Loading sub module "fb" >> (II) LoadModule: "fb" >> (II) Loading /usr/lib/xorg/modules//libfb.so >> (II) Module fb: vendor="X.Org Foundation" >> compiled for 1.6.1, module version = 1.0.0 >> ABI class: X.Org ANSI C Emulation, version 0.4 >> (II) omapfb(0): DPMS enabled >> (II) omapfb(0): Video plane capabilities: >> (II) omapfb(0): Video plane supports the following image formats: >> (II) omapfb(0): XVideo extension initialized >> (==) RandR enabled >> (II) Initializing built-in extension Generic Event Extension >> (II) Initializing built-in extension SHAPE >> (II) Initializing built-in extension MIT-SHM >> (II) Initializing built-in extension XInputExtension >> (II) Initializing built-in extension XTEST >> (II) Initializing built-in extension BIG-REQUESTS >> (II) Initializing built-in extension SYNC >> (II) Initializing built-in extension XKEYBOARD >> (II) Initializing built-in extension XC-MISC >> (II) Initializing built-in extension XINERAMA >> (II) Initializing built-in extension XFIXES >> (II) Initializing built-in extension RENDER >> (II) Initializing built-in extension RANDR >> (II) Initializing built-in extension COMPOSITE >> (II) Initializing built-in extension DAMAGE >> >> Backtrace: >> 0: Xorg(xorg_backtrace+0x28) [0xd2540] >> >> Fatal server error: >> Caught signal 11. Server aborting >> === >> > Does your xorg.conf enable GLX? You may want to try disabling it. > > ~sanjeev > > 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). Thanks, Eino-Ville Talvala Stanford University dmesg: omapdss OVERLAY: check_overlay 0: (0,0 480x640 -> 640x480) disp (480x640) omapdss MANAGER: omap_dss_mgr_apply(lcd) omapdss OVERLAY: check_overlay 0: (0,0 480x640 -> 640x480) disp (480x640) omapdss MANAGER: configure_overlay(0) omapdss DISPC: dispc_setup_plane 0, pa 7100, sw 2048, 0,0, 480x640 -> 640x48 0, ilace 0, cmode 40, rot 1, mir 0 omapdss MANAGER error: dispc_setup_plane failed for ovl 0 omapdss DISPC: dispc_enable_plane 0, 0 omapdss MANAGER error: configure_overlay 0 failed omapdss DISPC: GO LCD omapdss MANAGER: omap_dss_mgr_apply(lcd) _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 _XSERVTransOpen: transport open failed for inet6/omap3evm:0 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 (WW) Failed to open protocol names file /usr/lib/xorg/protocol.txt X.Org X Server 1.6.1 Release Date: 2009-4-14 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.24-24-generic i686 Current Operating System: Linux omap3evm 2.6.32-rc7-07
RE: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation
> -Original Message- > From: linux-omap-ow...@vger.kernel.org > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of > Eino-Ville Talvala > Sent: Tuesday, December 01, 2009 4:55 AM > To: Hiremath, Vaibhav > Cc: Tomi Valkeinen; linux-omap@vger.kernel.org > Subject: Re: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation > > On 11/29/2009 9:47 PM, Hiremath, Vaibhav wrote: > >> -Original Message- > >> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > >> ow...@vger.kernel.org] On Behalf Of Tomi Valkeinen > >> Sent: Thursday, November 26, 2009 7:50 PM > >> To: ext Eino-Ville Talvala > >> Cc: linux-omap@vger.kernel.org > >> Subject: Re: Problems using DSS2 on OMAP3 EVM / Angstrom with > >> rotation > >> > >> Hi, > >> > >> On Wed, 2009-11-25 at 01:14 +0100, ext Eino-Ville Talvala wrote: > >> > >>> Hi, > >>> > >>> I'm trying to get Xorg running on an Angstrom distro image on the > >>> > >> OMAP3 > >> > >>> EVM, with a rotated framebuffer. The default screen orientation > >>> > >> on the > >> > >>> EVM is portrait, and I'm trying to change this to landscape. > >>> > >> Without > >> > >>> any tweaking, using a kernel with your latest v5 DSS patches added > >>> > >> on > >> > >>> top (and Vaibhav's OMAP3 EVM DSS patches), DSS works and Angstrom > >>> happily displays both its initial bootup screen, and then the X > >>> > >> server > >> > >>> starts successfully. > >>> > >>> Using the omapfb.rotate=1 kernel command-line option, the initial > >>> > >> bootup > >> > >>> screen still works, but as soon as the X server tries to start up, > >>> > >> I get > >> > >>> the following error on the console: > >>> > >>> Starting GPE display manager: gpe-dm > >>> omapdss MANAGER error: dispc_setup_plane failed for ovl 0 > >>> omapdss MANAGER error: configure_overlay 0 failed > >>> > >> It sounds to me that gpe-dm (or something running after that) is > >> trying > >> to configure the overlay to 480x640 mode, and failing. If the > >> initial > >> > > [Hiremath, Vaibhav] I think this is the issue, I have seen > many peoples doing same mistakes, and it ends up to the > application, which doesn't care about rotation and tries to > set 480x640 in all rotation angles. > > > > > > The xorg boot log appears reasonably sane until a crash - 640x480 is > what the xf86 omapfb driver picks up, so I assume something > else is the > problem. I'll try to poke at the omapfb source some to see > if something > is being passed around wrong - I'd appreciate any suggestions on where > to look. > > === > ... > (II) LoadModule: "omapfb" > (II) Loading /usr/lib/xorg/modules/drivers//omapfb_drv.so > (II) Module omapfb: vendor="X.Org Foundation" > compiled for 1.6.1, module version = 0.1.1 > ABI class: X.Org Video Driver, version 5.0 > (II) omapfb: Driver for OMAP framebuffer (omapfb) and external LCD > controllers: > omap1/2/3, S1D13745, HWA742 > (WW) Falling back to old probe method for OMAPFB > (II) Running in FRAMEBUFFER Mode > (WW) Error opening /sys/devices/platform/omapfb/ctrl/name: No > such file > or direc > tory > (WW) Can't autodetect LCD controller, assuming internal > (II) LCD controller: internal > (II) omapfb(0): VideoRAM: 1920KiB (SDRAM) > (--) omapfb(0): Depth 16, (==) framebuffer bpp 16 > (==) omapfb(0): RGB weight 565 > (==) omapfb(0): Default visual is TrueColor > (--) omapfb(0): Virtual size is 640x480 (pitch 640) > (**) omapfb(0): Built-in mode "current" > (==) omapfb(0): DPI set to (96, 96) > (II) Loading sub module "fb" > (II) LoadModule: "fb" > (II) Loading /usr/lib/xorg/modules//libfb.so > (II) Module fb: vendor="X.Org Foundation" > compiled for 1.6.1, module version = 1.0.0 > ABI class: X.Org ANSI C Emulation, version 0.4 > (II) omapfb(0): DPMS enabled > (II) omapfb(0): Video plane capabilities: > (II) omapfb(0): Video plane supports the following image formats: > (II) omapfb(0): XVideo extension initialized > (==) RandR enabled > (II) Initializing built-in extension Generic Eve
Re: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation
On 11/29/2009 9:47 PM, Hiremath, Vaibhav wrote: >> -Original Message- >> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- >> ow...@vger.kernel.org] On Behalf Of Tomi Valkeinen >> Sent: Thursday, November 26, 2009 7:50 PM >> To: ext Eino-Ville Talvala >> Cc: linux-omap@vger.kernel.org >> Subject: Re: Problems using DSS2 on OMAP3 EVM / Angstrom with >> rotation >> >> Hi, >> >> On Wed, 2009-11-25 at 01:14 +0100, ext Eino-Ville Talvala wrote: >> >>> Hi, >>> >>> I'm trying to get Xorg running on an Angstrom distro image on the >>> >> OMAP3 >> >>> EVM, with a rotated framebuffer. The default screen orientation >>> >> on the >> >>> EVM is portrait, and I'm trying to change this to landscape. >>> >> Without >> >>> any tweaking, using a kernel with your latest v5 DSS patches added >>> >> on >> >>> top (and Vaibhav's OMAP3 EVM DSS patches), DSS works and Angstrom >>> happily displays both its initial bootup screen, and then the X >>> >> server >> >>> starts successfully. >>> >>> Using the omapfb.rotate=1 kernel command-line option, the initial >>> >> bootup >> >>> screen still works, but as soon as the X server tries to start up, >>> >> I get >> >>> the following error on the console: >>> >>> Starting GPE display manager: gpe-dm >>> omapdss MANAGER error: dispc_setup_plane failed for ovl 0 >>> omapdss MANAGER error: configure_overlay 0 failed >>> >> It sounds to me that gpe-dm (or something running after that) is >> trying >> to configure the overlay to 480x640 mode, and failing. If the >> initial >> > [Hiremath, Vaibhav] I think this is the issue, I have seen many peoples doing > same mistakes, and it ends up to the application, which doesn't care about > rotation and tries to set 480x640 in all rotation angles. > > The xorg boot log appears reasonably sane until a crash - 640x480 is what the xf86 omapfb driver picks up, so I assume something else is the problem. I'll try to poke at the omapfb source some to see if something is being passed around wrong - I'd appreciate any suggestions on where to look. === ... (II) LoadModule: "omapfb" (II) Loading /usr/lib/xorg/modules/drivers//omapfb_drv.so (II) Module omapfb: vendor="X.Org Foundation" compiled for 1.6.1, module version = 0.1.1 ABI class: X.Org Video Driver, version 5.0 (II) omapfb: Driver for OMAP framebuffer (omapfb) and external LCD controllers: omap1/2/3, S1D13745, HWA742 (WW) Falling back to old probe method for OMAPFB (II) Running in FRAMEBUFFER Mode (WW) Error opening /sys/devices/platform/omapfb/ctrl/name: No such file or direc tory (WW) Can't autodetect LCD controller, assuming internal (II) LCD controller: internal (II) omapfb(0): VideoRAM: 1920KiB (SDRAM) (--) omapfb(0): Depth 16, (==) framebuffer bpp 16 (==) omapfb(0): RGB weight 565 (==) omapfb(0): Default visual is TrueColor (--) omapfb(0): Virtual size is 640x480 (pitch 640) (**) omapfb(0): Built-in mode "current" (==) omapfb(0): DPI set to (96, 96) (II) Loading sub module "fb" (II) LoadModule: "fb" (II) Loading /usr/lib/xorg/modules//libfb.so (II) Module fb: vendor="X.Org Foundation" compiled for 1.6.1, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.4 (II) omapfb(0): DPMS enabled (II) omapfb(0): Video plane capabilities: (II) omapfb(0): Video plane supports the following image formats: (II) omapfb(0): XVideo extension initialized (==) RandR enabled (II) Initializing built-in extension Generic Event Extension (II) Initializing built-in extension SHAPE (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension BIG-REQUESTS (II) Initializing built-in extension SYNC (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension XC-MISC (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFIXES (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (II) Initializing built-in extension COMPOSITE (II) Initializing built-in extension DAMAGE Backtrace: 0: Xorg(xorg_backtrace+0x28) [0xd2540] Fatal server error: Caught signal 11. Server aborting === Thanks, Eino-Ville Talvala 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
RE: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Tomi Valkeinen > Sent: Thursday, November 26, 2009 7:50 PM > To: ext Eino-Ville Talvala > Cc: linux-omap@vger.kernel.org > Subject: Re: Problems using DSS2 on OMAP3 EVM / Angstrom with > rotation > > Hi, > > On Wed, 2009-11-25 at 01:14 +0100, ext Eino-Ville Talvala wrote: > > Hi, > > > > I'm trying to get Xorg running on an Angstrom distro image on the > OMAP3 > > EVM, with a rotated framebuffer. The default screen orientation > on the > > EVM is portrait, and I'm trying to change this to landscape. > Without > > any tweaking, using a kernel with your latest v5 DSS patches added > on > > top (and Vaibhav's OMAP3 EVM DSS patches), DSS works and Angstrom > > happily displays both its initial bootup screen, and then the X > server > > starts successfully. > > > > Using the omapfb.rotate=1 kernel command-line option, the initial > bootup > > screen still works, but as soon as the X server tries to start up, > I get > > the following error on the console: > > > > Starting GPE display manager: gpe-dm > > omapdss MANAGER error: dispc_setup_plane failed for ovl 0 > > omapdss MANAGER error: configure_overlay 0 failed > > It sounds to me that gpe-dm (or something running after that) is > trying > to configure the overlay to 480x640 mode, and failing. If the > initial [Hiremath, Vaibhav] I think this is the issue, I have seen many peoples doing same mistakes, and it ends up to the application, which doesn't care about rotation and tries to set 480x640 in all rotation angles. > bootup screen (I believe this is drawn from the linux side, not boot > loader?) is fine, it hints that the problem is in the X server or > some > other user space component. > > > My kernel bootargs are: > > mem=128M console=ttyS0,115200n8 noinitrd rw root=/dev/mmcblk0p2 > > rootfstype=ext2 rootdelay=1 nohz=off omapfb.rotate=1 omapfb.vrfb=y > > omapfb.debug=y omapdss.debug=y > > > > Without vrfb=y, the initial boot screen won't show up, with a > console > > message of 'omapdss DISPC error: GFX_FIFO_UNDERFLOW, disabling > GFX', and > > the same error for Xorg. > > In practice you always have to use VRFB rotation on OMAP3, so no > point > in trying without. > > > I'd appreciate any advice you could give me - doing this (in > theory > > simple) screen orientation change is really stumping me. > > It sounds to me that the DSS and omapfb is working fine. I also > tried > booting SDP board with similar boot arguments, and it's working fine > (although I'm not running X). [Hiremath, Vaibhav] Just to add, same bootargs has been tested thoroughly on OMAP3EVM and it is working fine for me. Thanks, Vaibhav > > Perhaps there's some application that checks the display dimensions, > which are 480x640, and tries to use those regardless of the > rotation. > > Tomi > > > -- > 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 -- 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
Re: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation
Op 26 nov 2009, om 15:20 heeft Tomi Valkeinen het volgende geschreven: >> My kernel bootargs are: >> mem=128M console=ttyS0,115200n8 noinitrd rw root=/dev/mmcblk0p2 >> rootfstype=ext2 rootdelay=1 nohz=off omapfb.rotate=1 omapfb.vrfb=y >> omapfb.debug=y omapdss.debug=y Try allocating some more VRAM for fb0 and fb1 and change 'rootdelay=1' to 'rootwait' and remove 'nohz=off' regards, Koen-- 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
Re: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation
Hi, On Wed, 2009-11-25 at 01:14 +0100, ext Eino-Ville Talvala wrote: > Hi, > > I'm trying to get Xorg running on an Angstrom distro image on the OMAP3 > EVM, with a rotated framebuffer. The default screen orientation on the > EVM is portrait, and I'm trying to change this to landscape. Without > any tweaking, using a kernel with your latest v5 DSS patches added on > top (and Vaibhav's OMAP3 EVM DSS patches), DSS works and Angstrom > happily displays both its initial bootup screen, and then the X server > starts successfully. > > Using the omapfb.rotate=1 kernel command-line option, the initial bootup > screen still works, but as soon as the X server tries to start up, I get > the following error on the console: > > Starting GPE display manager: gpe-dm > omapdss MANAGER error: dispc_setup_plane failed for ovl 0 > omapdss MANAGER error: configure_overlay 0 failed It sounds to me that gpe-dm (or something running after that) is trying to configure the overlay to 480x640 mode, and failing. If the initial bootup screen (I believe this is drawn from the linux side, not boot loader?) is fine, it hints that the problem is in the X server or some other user space component. > My kernel bootargs are: > mem=128M console=ttyS0,115200n8 noinitrd rw root=/dev/mmcblk0p2 > rootfstype=ext2 rootdelay=1 nohz=off omapfb.rotate=1 omapfb.vrfb=y > omapfb.debug=y omapdss.debug=y > > Without vrfb=y, the initial boot screen won't show up, with a console > message of 'omapdss DISPC error: GFX_FIFO_UNDERFLOW, disabling GFX', and > the same error for Xorg. In practice you always have to use VRFB rotation on OMAP3, so no point in trying without. > I'd appreciate any advice you could give me - doing this (in theory > simple) screen orientation change is really stumping me. It sounds to me that the DSS and omapfb is working fine. I also tried booting SDP board with similar boot arguments, and it's working fine (although I'm not running X). Perhaps there's some application that checks the display dimensions, which are 480x640, and tries to use those regardless of the rotation. Tomi -- 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
