Re: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation

Re: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation

[Tomi Valkeinen]

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

Re: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation

[Koen Kooi]

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

RE: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation

[Hiremath, Vaibhav]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation

[Eino-Ville Talvala]

On 11/29/2009 9:47 PM, Hiremath, Vaibhav wrote:
>> -----Original Message-----
>> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
>> owner@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

RE: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation

[Premi, Sanjeev]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org 
> [mailto:linux-omap-owner@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-owner@vger.kernel.org [mailto:linux-omap-
> >> owner@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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation

[Eino-Ville Talvala]

[-- Attachment #1: Type: text/plain, Size: 4553 bytes --]

<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 71000000, 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)



[-- Attachment #2: Xorg.0.log --]
[-- Type: text/plain, Size: 5778 bytes --]

_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 http://wiki.x.org
	to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Wed Dec  2 20:00:15 2009
(==) Using config file: "/etc/X11/xorg.conf"
(==) ServerLayout "Builtin Default Layout"
(**) |-->Screen "Builtin Default fbdev Screen 0" (0)
(**) |   |-->Monitor "Builtin Default Monitor"
(**) |   |-->Device "Builtin Default fbdev Device 0"
(==) Automatically adding devices
(==) Automatically enabling devices
(==) FontPath set to:
	/usr/share/fonts/X11/misc,
	built-ins
(==) ModulePath set to "/usr/lib/xorg/modules"
(II) Cannot locate a core pointer device.
(II) Cannot locate a core keyboard device.
(II) The server relies on HAL to provide the list of input devices.
	If no devices become available, reconfigure HAL or disable AllowEmptyInput.
(II) Loader magic: 0x1fd84
(II) Module ABI versions:
	X.Org ANSI C Emulation: 0.4
	X.Org Video Driver: 5.0
	X.Org XInput driver : 4.0
	X.Org Server Extension : 2.0
(II) Loader running on linux
(--) using VT number 3

(II) System resource ranges:
(II) "extmod" will be loaded by default.
(II) "dbe" will be loaded by default.
(II) "glx" will be loaded by default.
(II) "dri" will be loaded by default.
(II) "dri2" will be loaded by default.
(II) LoadModule: "extmod"
(II) Loading /usr/lib/xorg/modules/extensions//libextmod.so
(II) Module extmod: vendor="X.Org Foundation"
	compiled for 1.6.1, module version = 1.0.0
	Module class: X.Org Server Extension
	ABI class: X.Org Server Extension, version 2.0
(II) Loading extension MIT-SCREEN-SAVER
(II) Loading extension XFree86-VidModeExtension
(II) Loading extension XFree86-DGA
(II) Loading extension DPMS
(II) Loading extension XVideo
(II) Loading extension XVideo-MotionCompensation
(II) Loading extension X-Resource
(II) LoadModule: "dbe"
(II) Loading /usr/lib/xorg/modules/extensions//libdbe.so
(II) Module dbe: vendor="X.Org Foundation"
	compiled for 1.6.1, module version = 1.0.0
	Module class: X.Org Server Extension
	ABI class: X.Org Server Extension, version 2.0
(II) Loading extension DOUBLE-BUFFER
(II) LoadModule: "glx"
(WW) Warning, couldn't open module glx
(II) UnloadModule: "glx"
(EE) Failed to load module "glx" (module does not exist, 0)
(II) LoadModule: "dri"
(WW) Warning, couldn't open module dri
(II) UnloadModule: "dri"
(EE) Failed to load module "dri" (module does not exist, 0)
(II) LoadModule: "dri2"
(II) Loading /usr/lib/xorg/modules/extensions//libdri2.so
(II) Module dri2: vendor="X.Org Foundation"
	compiled for 1.6.1, module version = 1.0.0
	ABI class: X.Org Server Extension, version 2.0
(II) Loading extension DRI2
(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 directory
(WW) Can't autodetect LCD controller, assuming internal
(II) LCD controller: internal
(II) omapfb(0): VideoRAM: 1920KiB (SDRAM)
(II) omapfb(0): Creating default Display subsection in Screen section
	"Builtin Default fbdev Screen 0" for depth/fbbpp 16/16
(--) 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) [0xe0b18]

Fatal server error:
Caught signal 11.  Server aborting


Please consult the The X.Org Foundation support 
	 at http://wiki.x.org
 for help. 
Please also check the log file at "/var/log/Xorg.0.log" for additional information.

(NI) OMAPFBLeaveVT

[-- Attachment #3: xorg.conf --]
[-- Type: text/plain, Size: 1330 bytes --]

Section "Module"                                       
#        Load    "extmod"                                
#        Load    "dbe"                           
#        Load    "glx"                                           
#        Load    "freetype"                             
#        Load    "type1"                        
#        Load    "record"                    
#        Load    "dri"                       
EndSection                            

Section "Monitor"
        Identifier      "Builtin Default Monitor"
EndSection                                       

Section "Device"                                  
        Identifier      "Builtin Default fbdev Device 0"
        Driver  "omapfb"
EndSection                                                
Section "Screen"                                        
        Identifier      "Builtin Default fbdev Screen 0"     
        Device  "Builtin Default fbdev Device 0"            
        Monitor "Builtin Default Monitor"               
EndSection                                              

Section "ServerLayout"                                 
        Identifier      "Builtin Default Layout"                                     
        Screen  "Builtin Default fbdev Screen 0"        
EndSection                                              

Re: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation

[Koen Kooi]

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

Re: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation

[Eino-Ville Talvala]

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
>   

root@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

root@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

root@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!

Re: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation

[Eino-Ville Talvala]

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
>>   
>>     
> root@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
>
> root@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
>
> root@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

Re: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation

[Koen Kooi]

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
>>> 
>>> 
>> root@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
>> 
>> root@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
>> 
>> root@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