Hi, I am still trying to figure out how to set up X11 to properly rotate using X11/DRM/TILER (which is merged into the letux-4.10.0 kernel).
LXDE starts up rotated, but "xrandr -o right" works and LXDE even rearranges the status bar. But requires DISPLAY to be initialized before.
Setting the option "rotate" to whatever rotation in xorg.conf seems to be ignored.
Here is the relevant xorg.conf:
Section "Monitor" Identifier "lcd" VendorName "BOE" ModelName "LH500WF1" Option "Rotate" "right" DisplaySize 111 62 # LCD size in millimeters EndSection
Section "Device" Identifier "display0" Driver "omap" Option "HWcursor" "False" EndSection
Section "Screen" Identifier "Screen 0" Device "display0" Monitor "lcd" EndSection
Any hints are welcome!
BR and thanks, Nikolaus
Am Thu, 9 Mar 2017 10:36:15 +0100 hat "H. Nikolaus Schaller" hns@goldelico.com geschrieben:
AFAIK TILER doesn't need any special setup for X11, as it rotates the display in general.
But I think it uses fbdev, so the problem is either that TILER is not properly working at all in your setup or it doesn't work with driver "omap".
Hi, I am still trying to figure out how to set up X11 to properly rotate using X11/DRM/TILER (which is merged into the letux-4.10.0 kernel).
LXDE starts up rotated, but "xrandr -o right" works and LXDE even rearranges the status bar. But requires DISPLAY to be initialized before.
Setting the option "rotate" to whatever rotation in xorg.conf seems to be ignored.
Here is the relevant xorg.conf:
Section "Monitor" Identifier "lcd" VendorName "BOE" ModelName "LH500WF1" Option "Rotate" "right" DisplaySize 111 62 # LCD size in millimeters EndSection
Section "Device" Identifier "display0" Driver "omap" Option "HWcursor" "False" EndSection
Section "Screen" Identifier "Screen 0" Device "display0" Monitor "lcd" EndSection
Any hints are welcome!
BR and thanks, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Am 09.03.2017 um 12:24 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Thu, 9 Mar 2017 10:36:15 +0100 hat "H. Nikolaus Schaller" hns@goldelico.com geschrieben:
AFAIK TILER doesn't need any special setup for X11, as it rotates the display in general.
Hm. It works if I use xrandr after starting X11 but not with xorg.conf. What I can't tell is if xrandr activates the TILER or not.
And the scripts I recently got from aTc didn't rotate anything for me.
But I think it uses fbdev, so the problem is either that TILER is not properly working at all in your setup or it doesn't work with driver "omap".
AFAIR fbdev drivers are deprecated. And TILER uses DRM and that should be independent of fbdev. Or not?
BR, Nikolaus
Hi, I am still trying to figure out how to set up X11 to properly rotate using X11/DRM/TILER (which is merged into the letux-4.10.0 kernel).
LXDE starts up rotated, but "xrandr -o right" works and LXDE even rearranges the status bar. But requires DISPLAY to be initialized before.
Setting the option "rotate" to whatever rotation in xorg.conf seems to be ignored.
Here is the relevant xorg.conf:
Section "Monitor" Identifier "lcd" VendorName "BOE" ModelName "LH500WF1" Option "Rotate" "right" DisplaySize 111 62 # LCD size in millimeters EndSection
Section "Device" Identifier "display0" Driver "omap" Option "HWcursor" "False" EndSection
Section "Screen" Identifier "Screen 0" Device "display0" Monitor "lcd" EndSection
Any hints are welcome!
BR and thanks, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
On 9 March 2017 at 16:26, H. Nikolaus Schaller hns@goldelico.com wrote:
Hm. It works if I use xrandr after starting X11 but not with xorg.conf.
I wouldn't be surprised if LXDE simply applied its own xrandr settings, thus undoing the rotation you set in xorg.conf.
What I can't tell is if xrandr activates the TILER or not.
If you're using xorg-video-omap then yes, it is using TILER.
AFAIR fbdev drivers are deprecated. And TILER uses DRM and that should be independent of fbdev. Or not?
Correct, but since PyraOS was/is still heavily leaning on fbdev I prioritized getting the fbdev rotated for the GamesCon demo. Part of the reason is that xorg-video-omap was slower than xorg-video-modesetting, which itself was slower than xorg-video-fbturbo. These differences are afaik unrelated to DRM vs fbdev and purely depend on the software rendering implementation, with fbturbo taking explicit care to keep the high latency of framebuffer access in mind and e.g. use large Neon reads whenever it has to read from the framebuffer.
From DRM's perspective, fbdev is simply one framebuffer object which is
retained by the kernel and which drm_kms_helper puts on screen with some default modesetting whenever there's no DRM master. There are also some special considerations needed for allocating the memory for that framebuffer because it has to be mapped in kernelspace to support legacy operations such as write() into /dev/fb0, whereas DRM buffers are normally only mapped into userspace.
So, what my patches do, successively: patch/tiler-memtype -- fixes slowness #1 (I should try to upstream this one) patch/tiler-fast -- fixes slowness #2 (needs polishing). patch/tiler-buf-fbdev -- allocates the legacy fbdev framebuffer in TILER memory in an incredibly hacky way. patch/tiler-fbdev -- hacks a rotation option into the modesetting done by drm_kms_helper
patch/tiler-fast is all that's required to fix the TILER performance problems for users of libdrm_omap (such as xorg-video-omap). The reason libdrm_omap is needed is because special calls are needed to allocate a buffer in TILER memory. Once allocated, displaying it with rotation is standard drm stuff (the "rotation" property of a layer).
This also means that after patch/tiler-buf-fbdev you can use standard drm calls to display the legacy fbdev framebuffer with rotation. That's what was going on in this video: https://www.youtube.com/watch?v=CFjLA9QX_hs The fbdev applications themselves are completely unaware of any of this.
patch/tiler-fbdev finally moves this setting to kernelspace.
patch/tiler-buf-dumb was an experiment to force the generic "dumb buffer" api to allocate all buffers in TILER memory. This is highly excessive and unnecessary, and might risk running out of TILER memory. It also completely broke SGX and would have broken e.g. etnaviv if we had it working, since I discovered that export of TILER-allocated buffers via the dma-buf API is basically not implemented yet (but does nonsense instead of returning an error).
Fixing dma-buf export is probably one of my highest priorities once I get to focus on graphics again. If I fix vmap of buffers as part of this, then that should also allow for a less hacky version of patch/tiler-buf-fbdev.
Matthijs
On 9 March 2017 at 22:45, Matthijs van Duin matthijsvanduin@gmail.com wrote:
This also means that after patch/tiler-buf-fbdev you can use standard drm calls to display the legacy fbdev framebuffer with rotation. That's what was going on in this video: https://www.youtube.com/watch?v=CFjLA9QX_hs The fbdev applications themselves are completely unaware of any of this.
Sorry, wrong video link, I meant https://www.youtube.com/watch?v=PjXHZX4VIqc
Matthijs
Am 09.03.2017 um 22:45 schrieb Matthijs van Duin matthijsvanduin@gmail.com:
On 9 March 2017 at 16:26, H. Nikolaus Schaller <hns@goldelico.com mailto:hns@goldelico.com> wrote: Hm. It works if I use xrandr after starting X11 but not with xorg.conf.
I wouldn't be surprised if LXDE simply applied its own xrandr settings, thus undoing the rotation you set in xorg.conf.
Ah, that is something I will try to find out. E.g. by starting X w/o LXDE and running xterm.
What I can't tell is if xrandr activates the TILER or not.
If you're using xorg-video-omap then yes, it is using TILER.
Fine.
AFAIR fbdev drivers are deprecated. And TILER uses DRM and that should be independent of fbdev. Or not?
Correct, but since PyraOS was/is still heavily leaning on fbdev I prioritized getting the fbdev rotated for the GamesCon demo. Part of the reason is that xorg-video-omap was slower than xorg-video-modesetting, which itself was slower than xorg-video-fbturbo. These differences are afaik unrelated to DRM vs fbdev and purely depend on the software rendering implementation, with fbturbo taking explicit care to keep the high latency of framebuffer access in mind and e.g. use large Neon reads whenever it has to read from the framebuffer.
Ok, I see. Maybe my user space is exceptional because it uses plain xorg-video-omap. The reason is that other drivers made problems on other devices.
BR and thanks, Nikolaus
Am 10.03.2017 um 07:07 schrieb H. Nikolaus Schaller hns@goldelico.com:
Am 09.03.2017 um 22:45 schrieb Matthijs van Duin matthijsvanduin@gmail.com:
On 9 March 2017 at 16:26, H. Nikolaus Schaller hns@goldelico.com wrote: Hm. It works if I use xrandr after starting X11 but not with xorg.conf.
I wouldn't be surprised if LXDE simply applied its own xrandr settings, thus undoing the rotation you set in xorg.conf.
Ah, that is something I will try to find out. E.g. by starting X w/o LXDE and running xterm.
Hm. Is not a specific LXDE effect. Happens with /usr/bin/openbox as displaymanager as well.
After launching X11, xrandr tells "rotation normal". Then, I can xrandr -r right and it is fine.
So somehow the xorg.conf setting is ignored.
What I can't tell is if xrandr activates the TILER or not.
If you're using xorg-video-omap then yes, it is using TILER.
Fine.
AFAIR fbdev drivers are deprecated. And TILER uses DRM and that should be independent of fbdev. Or not?
Correct, but since PyraOS was/is still heavily leaning on fbdev I prioritized getting the fbdev rotated for the GamesCon demo. Part of the reason is that xorg-video-omap was slower than xorg-video-modesetting, which itself was slower than xorg-video-fbturbo. These differences are afaik unrelated to DRM vs fbdev and purely depend on the software rendering implementation, with fbturbo taking explicit care to keep the high latency of framebuffer access in mind and e.g. use large Neon reads whenever it has to read from the framebuffer.
Ok, I see. Maybe my user space is exceptional because it uses plain xorg-video-omap. The reason is that other drivers made problems on other devices.
BR and thanks, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Any hint in /var/log/Xorg.0.log or whatever the log file ?
Le 2017-03-10 09:18, H. Nikolaus Schaller a écrit :
Am 10.03.2017 um 07:07 schrieb H. Nikolaus Schaller hns@goldelico.com:
Am 09.03.2017 um 22:45 schrieb Matthijs van Duin matthijsvanduin@gmail.com:
On 9 March 2017 at 16:26, H. Nikolaus Schaller hns@goldelico.com wrote: Hm. It works if I use xrandr after starting X11 but not with xorg.conf.
I wouldn't be surprised if LXDE simply applied its own xrandr settings, thus undoing the rotation you set in xorg.conf.
Ah, that is something I will try to find out. E.g. by starting X w/o LXDE and running xterm.
Hm. Is not a specific LXDE effect. Happens with /usr/bin/openbox as displaymanager as well.
After launching X11, xrandr tells "rotation normal". Then, I can xrandr -r right and it is fine.
So somehow the xorg.conf setting is ignored.
What I can't tell is if xrandr activates the TILER or not.
If you're using xorg-video-omap then yes, it is using TILER.
Fine.
AFAIR fbdev drivers are deprecated. And TILER uses DRM and that should be independent of fbdev. Or not?
Correct, but since PyraOS was/is still heavily leaning on fbdev I prioritized getting the fbdev rotated for the GamesCon demo. Part of the reason is that xorg-video-omap was slower than xorg-video-modesetting, which itself was slower than xorg-video-fbturbo. These differences are afaik unrelated to DRM vs fbdev and purely depend on the software rendering implementation, with fbturbo taking explicit care to keep the high latency of framebuffer access in mind and e.g. use large Neon reads whenever it has to read from the framebuffer.
Ok, I see. Maybe my user space is exceptional because it uses plain xorg-video-omap. The reason is that other drivers made problems on other devices.
BR and thanks, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Hi,
Am 10.03.2017 um 13:30 schrieb Linux-SWAT openpandora@free.fr:
Any hint in /var/log/Xorg.0.log or whatever the log file ?
Le 2017-03-10 09:18, H. Nikolaus Schaller a écrit :
Am 10.03.2017 um 07:07 schrieb H. Nikolaus Schaller hns@goldelico.com:
Am 09.03.2017 um 22:45 schrieb Matthijs van Duin matthijsvanduin@gmail.com: On 9 March 2017 at 16:26, H. Nikolaus Schaller hns@goldelico.com wrote: Hm. It works if I use xrandr after starting X11 but not with xorg.conf. I wouldn't be surprised if LXDE simply applied its own xrandr settings, thus undoing the rotation you set in xorg.conf.
Ah, that is something I will try to find out. E.g. by starting X w/o LXDE and running xterm.
Hm. Is not a specific LXDE effect. Happens with /usr/bin/openbox as displaymanager as well. After launching X11, xrandr tells "rotation normal". Then, I can xrandr -r right and it is fine. So somehow the xorg.conf setting is ignored.
I had checked before and checked again, but nothing which gives me a good hint. the Option "Rotate" "right" is recognised. And RandR 1.2 enabled is initialized later.
The only questionable part is "Output Unknown16-1 has no monitor section". On the other hand Xserver finds
Modeline "720x1280"x60.0 76.72 720 725 730 888 1280 1330 1390 1440 (86.4 kHz eP)
Here is an excerpt:
[ 122.562] (II) Loading /usr/lib/xorg/modules/input/void_drv.so [ 122.562] (II) Module void: vendor="X.Org Foundation" [ 122.562] compiled for 1.15.99.904, module version = 1.4.0 [ 122.562] Module class: X.Org XInput Driver [ 122.562] ABI class: X.Org XInput driver, version 21.0 [ 122.562] (II) OMAP: Driver for TI OMAP: OMAP3430 with PowerVR SGX530, OMAP3630 with PowerVR SGX530, OMAP4430 with PowerVR SGX540, OMAP4460 with PowerVR SGX540, OMAP5430 with PowerVR SGX544 MP, OMAP5432 with PowerVR SGX544 MP [ 122.562] (--) using VT number 3
[ 122.605] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support [ 122.605] (II) OMAP(0): Creating default Display subsection in Screen section "Screen 0" for depth/fbbpp 24/32 [ 122.605] (==) OMAP(0): Depth 24, (==) framebuffer bpp 32 [ 122.605] (==) OMAP(0): RGB weight 888 [ 122.605] (==) OMAP(0): Using gamma correction (1.0, 1.0, 1.0) [ 122.605] (==) OMAP(0): Default visual is TrueColor [ 122.622] (II) OMAP(0): Found chipset: OMAP5432 with PowerVR SGX544 MP [ 122.622] (**) OMAP(0): Option "HWcursor" "False" [ 122.622] (II) OMAP(0): Using SW cursor [ 122.622] (II) OMAP(0): Setting the video modes ... [ 122.623] (II) OMAP(0): Output HDMI-1 using monitor section lcd [ 122.623] (**) OMAP(0): Option "Rotate" "right" [ 122.623] (II) OMAP(0): Output Unknown16-1 has no monitor section [ 122.623] (II) OMAP(0): EDID for output HDMI-1 [ 122.623] (II) OMAP(0): Printing probed modes for output Unknown16-1 [ 122.623] (II) OMAP(0): Modeline "720x1280"x60.0 76.72 720 725 730 888 1280 1330 1390 1440 (86.4 kHz eP) [ 122.623] (II) OMAP(0): Output HDMI-1 disconnected [ 122.624] (II) OMAP(0): Output Unknown16-1 connected [ 122.624] (II) OMAP(0): Using exact sizes for initial modes [ 122.624] (II) OMAP(0): Output Unknown16-1 using initial mode 720x1280 [ 122.624] (II) OMAP(0): Using default gamma of (1.0, 1.0, 1.0) unless otherwise stated. [ 122.624] (II) OMAP(0): Got KMS resources [ 122.624] (**) OMAP(0): Display dimensions: (111, 62) mm [ 122.624] (**) OMAP(0): DPI set to (164, 524) [ 122.624] (II) Loading sub module "dri2" [ 122.624] (II) LoadModule: "dri2" [ 122.624] (II) Module "dri2" already built-in [ 122.624] (II) Loading sub module "exa" [ 122.624] (II) LoadModule: "exa" [ 122.625] (II) Loading /usr/lib/xorg/modules/libexa.so [ 122.626] (II) Module exa: vendor="X.Org Foundation" [ 122.626] compiled for 1.16.4, module version = 2.6.0 [ 122.626] ABI class: X.Org Video Driver, version 18.0 [ 122.626] (II) Loading sub module "fb" [ 122.626] (II) LoadModule: "fb" [ 122.627] (II) Loading /usr/lib/xorg/modules/libfb.so [ 122.628] (II) Module fb: vendor="X.Org Foundation" [ 122.628] compiled for 1.16.4, module version = 1.0.0 [ 122.628] ABI class: X.Org ANSI C Emulation, version 0.4 [ 122.628] (II) Loading sub module "omap_pvr" [ 122.628] (II) LoadModule: "omap_pvr" [ 122.630] (WW) Warning, couldn't open module omap_pvr [ 122.630] (II) UnloadModule: "omap_pvr" [ 122.630] (II) Unloading omap_pvr [ 122.630] (EE) OMAP: Failed to load module "omap_pvr" (module does not exist, 0) [ 122.630] (II) OMAP(0): Cannot load the omap_pvr sub-module [ 122.630] (--) Depth 24 pixmap format is 32 bpp [ 122.631] (II) OMAP(0): Soft EXA mode [ 122.631] (II) EXA(0): Driver allocated offscreen pixmaps [ 122.631] (II) EXA(0): Driver registered support for the following operations: [ 122.631] (II) Solid [ 122.631] (II) Copy [ 122.631] (II) Composite (RENDER acceleration) [ 122.631] (II) OMAP(0): [DRI2] Setup complete [ 122.631] (II) OMAP(0): [DRI2] DRI driver: omap [ 122.631] (EE) OMAP(0): ERROR: Could not initialize XV [ 122.632] (==) OMAP(0): Backing store enabled [ 122.632] (==) OMAP(0): Silken mouse enabled [ 122.722] (II) OMAP(0): RandR 1.2 enabled, ignore the following RandR disabled message. [ 122.722] (==) OMAP(0): DPMS enabled [ 122.723] (--) RandR disabled
Am 10.03.2017 um 14:23 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi,
Am 10.03.2017 um 13:30 schrieb Linux-SWAT openpandora@free.fr:
Any hint in /var/log/Xorg.0.log or whatever the log file ?
Le 2017-03-10 09:18, H. Nikolaus Schaller a écrit :
Am 10.03.2017 um 07:07 schrieb H. Nikolaus Schaller hns@goldelico.com:
Am 09.03.2017 um 22:45 schrieb Matthijs van Duin matthijsvanduin@gmail.com: On 9 March 2017 at 16:26, H. Nikolaus Schaller hns@goldelico.com wrote: Hm. It works if I use xrandr after starting X11 but not with xorg.conf. I wouldn't be surprised if LXDE simply applied its own xrandr settings, thus undoing the rotation you set in xorg.conf.
Ah, that is something I will try to find out. E.g. by starting X w/o LXDE and running xterm.
Hm. Is not a specific LXDE effect. Happens with /usr/bin/openbox as displaymanager as well. After launching X11, xrandr tells "rotation normal". Then, I can xrandr -r right and it is fine. So somehow the xorg.conf setting is ignored.
I had checked before and checked again, but nothing which gives me a good hint. the Option "Rotate" "right" is recognised. And RandR 1.2 enabled is initialized later.
The only questionable part is "Output Unknown16-1 has no monitor section". On the other hand Xserver finds
Modeline "720x1280"x60.0 76.72 720 725 730 888 1280 1330 1390 1440 (86.4 kHz eP)
Here is an excerpt:
[ 122.562] (II) Loading /usr/lib/xorg/modules/input/void_drv.so [ 122.562] (II) Module void: vendor="X.Org Foundation" [ 122.562] compiled for 1.15.99.904, module version = 1.4.0 [ 122.562] Module class: X.Org XInput Driver [ 122.562] ABI class: X.Org XInput driver, version 21.0 [ 122.562] (II) OMAP: Driver for TI OMAP: OMAP3430 with PowerVR SGX530, OMAP3630 with PowerVR SGX530, OMAP4430 with PowerVR SGX540, OMAP4460 with PowerVR SGX540, OMAP5430 with PowerVR SGX544 MP, OMAP5432 with PowerVR SGX544 MP [ 122.562] (--) using VT number 3
[ 122.605] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support [ 122.605] (II) OMAP(0): Creating default Display subsection in Screen section "Screen 0" for depth/fbbpp 24/32 [ 122.605] (==) OMAP(0): Depth 24, (==) framebuffer bpp 32 [ 122.605] (==) OMAP(0): RGB weight 888 [ 122.605] (==) OMAP(0): Using gamma correction (1.0, 1.0, 1.0) [ 122.605] (==) OMAP(0): Default visual is TrueColor [ 122.622] (II) OMAP(0): Found chipset: OMAP5432 with PowerVR SGX544 MP [ 122.622] (**) OMAP(0): Option "HWcursor" "False" [ 122.622] (II) OMAP(0): Using SW cursor [ 122.622] (II) OMAP(0): Setting the video modes ... [ 122.623] (II) OMAP(0): Output HDMI-1 using monitor section lcd [ 122.623] (**) OMAP(0): Option "Rotate" "right" [ 122.623] (II) OMAP(0): Output Unknown16-1 has no monitor section [ 122.623] (II) OMAP(0): EDID for output HDMI-1 [ 122.623] (II) OMAP(0): Printing probed modes for output Unknown16-1 [ 122.623] (II) OMAP(0): Modeline "720x1280"x60.0 76.72 720 725 730 888 1280 1330 1390 1440 (86.4 kHz eP) [ 122.623] (II) OMAP(0): Output HDMI-1 disconnected [ 122.624] (II) OMAP(0): Output Unknown16-1 connected [ 122.624] (II) OMAP(0): Using exact sizes for initial modes [ 122.624] (II) OMAP(0): Output Unknown16-1 using initial mode 720x1280 [ 122.624] (II) OMAP(0): Using default gamma of (1.0, 1.0, 1.0) unless otherwise stated. [ 122.624] (II) OMAP(0): Got KMS resources [ 122.624] (**) OMAP(0): Display dimensions: (111, 62) mm [ 122.624] (**) OMAP(0): DPI set to (164, 524) [ 122.624] (II) Loading sub module "dri2" [ 122.624] (II) LoadModule: "dri2" [ 122.624] (II) Module "dri2" already built-in [ 122.624] (II) Loading sub module "exa" [ 122.624] (II) LoadModule: "exa" [ 122.625] (II) Loading /usr/lib/xorg/modules/libexa.so [ 122.626] (II) Module exa: vendor="X.Org Foundation" [ 122.626] compiled for 1.16.4, module version = 2.6.0 [ 122.626] ABI class: X.Org Video Driver, version 18.0 [ 122.626] (II) Loading sub module "fb" [ 122.626] (II) LoadModule: "fb" [ 122.627] (II) Loading /usr/lib/xorg/modules/libfb.so [ 122.628] (II) Module fb: vendor="X.Org Foundation" [ 122.628] compiled for 1.16.4, module version = 1.0.0 [ 122.628] ABI class: X.Org ANSI C Emulation, version 0.4 [ 122.628] (II) Loading sub module "omap_pvr" [ 122.628] (II) LoadModule: "omap_pvr" [ 122.630] (WW) Warning, couldn't open module omap_pvr [ 122.630] (II) UnloadModule: "omap_pvr" [ 122.630] (II) Unloading omap_pvr [ 122.630] (EE) OMAP: Failed to load module "omap_pvr" (module does not exist, 0) [ 122.630] (II) OMAP(0): Cannot load the omap_pvr sub-module [ 122.630] (--) Depth 24 pixmap format is 32 bpp [ 122.631] (II) OMAP(0): Soft EXA mode [ 122.631] (II) EXA(0): Driver allocated offscreen pixmaps [ 122.631] (II) EXA(0): Driver registered support for the following operations: [ 122.631] (II) Solid [ 122.631] (II) Copy [ 122.631] (II) Composite (RENDER acceleration) [ 122.631] (II) OMAP(0): [DRI2] Setup complete [ 122.631] (II) OMAP(0): [DRI2] DRI driver: omap [ 122.631] (EE) OMAP(0): ERROR: Could not initialize XV [ 122.632] (==) OMAP(0): Backing store enabled [ 122.632] (==) OMAP(0): Silken mouse enabled [ 122.722] (II) OMAP(0): RandR 1.2 enabled, ignore the following RandR disabled message. [ 122.722] (==) OMAP(0): DPMS enabled [ 122.723] (--) RandR disabled
Some more checks:
root@letux:~# dpkg -l | fgrep xorg-video-omap ii xserver-xorg-video-omap 0.4.3-1+b3 armhf X.Org X server -- OMAP display driver root@letux:~# man omap|fgrep Rotate root@letux:~# man omap|fgrep 0.4 X Version 11 xf86-video-omap 0.4.3 omap(4) root@letux:~# man xorg.conf|fgrep Rotate Option "Rotate" "rotation" root@letux:~#
This means that man page of the installed xorg-video-omap driver does not tell that it understands the option, but it refers to xorg.conf(5) which mentions it should be a default option for any driver.
I have also tried with Option "Debug" "true" but despite telling more it has no new information about rotation.
BR, Nikolaus
https://manpages.debian.org/jessie/xserver-xorg-video-omap/omap.4.en.html https://manpages.debian.org/jessie/xserver-xorg-core/xorg.conf.5.en.html
On 10 March 2017 at 14:23, H. Nikolaus Schaller hns@goldelico.com wrote:
The only questionable part is "Output Unknown16-1 has no monitor section".
That sounds like the problem. Try adding
Option "Monitor-Unknown16-1" "lcd" Option "Monitor-DSI-1" "lcd"
to your Device section. The second line is for when someone notices connector type 16 is defined in the kernel and fixes X11 to recognize it :P
Matthijs
Hi Matthijs,
Am 10.03.2017 um 17:52 schrieb Matthijs van Duin matthijsvanduin@gmail.com:
On 10 March 2017 at 14:23, H. Nikolaus Schaller hns@goldelico.com wrote: The only questionable part is "Output Unknown16-1 has no monitor section".
That sounds like the problem. Try adding
Option "Monitor-Unknown16-1" "lcd" Option "Monitor-DSI-1" "lcd"
to your Device section. The second line is for when someone notices connector type 16 is defined in the kernel and fixes X11 to recognize it :P
Matthijs
Yeah! That's the trick!
Any sufficiently advanced technology is indistinguishable from magic...
BR and thanks, Nikolaus
-
H. Nikolaus Schaller -
Linux-SWAT -
Matthijs van Duin -
Michael Mrozek