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: 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. 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: 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
Re: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation
snip 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-07318-g8979e82 #320 Wed Nov 25 15:02:04 PST 2009 armv7l Build Date: 02 December 2009 02:23:08AM Before reporting problems, check
Re: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation
Op 2 dec 2009, om 21:02 heeft Eino-Ville Talvala het volgende geschreven: snip 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
On 12/2/2009 12:52 PM, Koen Kooi wrote: Op 2 dec 2009, om 21:02 heeft Eino-Ville Talvala het volgende geschreven: snip 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 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
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 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, 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 -- To unsubscribe from this list: send
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
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
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
