Re: Adding rotation to xf86-video-omapfb
On Fri, 28 Dec 2012 12:38:54 +0100 Maarten Maathuis madman2...@gmail.com wrote: I think your approach of swapped width and height was a good idea (if the kernel interface of omapfb defines that behavior) , but you have to find out if the driver reads back those values you send to omapfb. Because somewhere those internal details are showing up in xrandr. My guess is you have to mangle it back in OMAPFBOutputGetModes() based on the rotation mode. Thanks a lot!!!, it works now... Denis. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Adding rotation to xf86-video-omapfb
On Fri, Dec 28, 2012 at 3:50 AM, Daniel Stone dan...@fooishbar.org wrote: Hi, On 28 December 2012 01:08, Maarten Maathuis madman2...@gmail.com wrote: As far as i remember you typically allocate a shadow (there are some driver hooks for that, check existing drivers like intel, radeon or nouveau). This will become the new scanout buffer and this has the rotated dimensions. The original rendering will still be done to the normal framebuffer. Composite with rotation in combination with damage (a system used in X to track what areas have been rendered to i.e. damaged) is used to keep the shadow up to date. You should probably implement the shadow hooks that are present in the crtc structure. You should make sure this shadow allocation gets used as the framebuffer. And you should check if your composite implementation supports rotation, if not it may be necessary to expand it with support for any scaling/rotation matrix or else add a special case for 90 degree rotation if your hardware supports that. As you can see from the linked diff, the fbdev driver implements rotation as the hardware can do it on scanout. It also doesn't support any acceleration, given that OMAP carries an SGX, so neither the shadow nor Composite hooks are relevant here. Cheers, Daniel The shadow + composite rotation seems to be contained in xf86CrtcRotate function (that would be called from the set_mode_major driver hook by drivers that want it), so you can avoid that. To the best of my knowledge (since i can find no sign of rotating modes) the hardware (typically) continues to be driven at the original mode (for example 1280x1024). The X root window is resized to match the new swapped dimensions (for example 1024x1280) and the driver is left to make sure the content ends up in the right way. In your case you probably get a frontbuffer with the swapped size (1024x1280 for example), but the mode you get is 1280x1024 probably. I think your approach of swapped width and height was a good idea (if the kernel interface of omapfb defines that behavior) , but you have to find out if the driver reads back those values you send to omapfb. Because somewhere those internal details are showing up in xrandr. My guess is you have to mangle it back in OMAPFBOutputGetModes() based on the rotation mode. -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Adding rotation to xf86-video-omapfb
On Thu, Dec 27, 2012 at 8:48 PM, Denis 'GNUtoo' Carikli gnu...@no-log.org wrote: Hi, I've been trying to add rotation to the out of tree xf86-video-omapfb(I'm aware of xf86-video-omap but I've an omap3, and beside, it requires a staging kernel driver). So far I got rotation working(xrandr -o 1 works). But when I want to rotate back (xrandr -o 0) Xorg checks if the requested X resolution is smaller or equals to the masimum allowed Xresolution and it fails... The thing is that I've been using a hack to make it work: instead of keeping the same resolution and just making rotate the display content, I've changed the resolution too. My device is the GTA04 and it has a 480x640 display, so when rotating a new mode is created(640x480): root@om-gta04:~# xrandr -q Screen 0: minimum 8 x 8, current 640 x 480, maximum 480 x 640 LCD connected 640x480+0+0 left (normal left inverted right x axis y axis) 0mm x 0mm 640x48066.8 + 480x640 (0x41) 22.2MHz h: width 480 start 504 end 512 total 520 skew0 clock 42.6KHz v: height 640 start 644 end 646 total 648 clock 65.7Hz This shouldn't happen and instead I should use the normal approach, which is not to change the resolution... But that fails too: My display is in portrait mode, and so when rotating the image changes to 640x480, from the point 0.0 and isn't rotated, which result in the image going over the physical screen dimentions... The code I've been developing is here: https://gitorious.org/gnutoo-s-programs-for-shr/xf86-video-omapfb/commit/834a2b938cbff98e6f69ff66789cf422e3e2d483 I'd like to make the correct way work and rotate, but I've no idea of how... Denis. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel As far as i remember you typically allocate a shadow (there are some driver hooks for that, check existing drivers like intel, radeon or nouveau). This will become the new scanout buffer and this has the rotated dimensions. The original rendering will still be done to the normal framebuffer. Composite with rotation in combination with damage (a system used in X to track what areas have been rendered to i.e. damaged) is used to keep the shadow up to date. You should probably implement the shadow hooks that are present in the crtc structure. You should make sure this shadow allocation gets used as the framebuffer. And you should check if your composite implementation supports rotation, if not it may be necessary to expand it with support for any scaling/rotation matrix or else add a special case for 90 degree rotation if your hardware supports that. -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Adding rotation to xf86-video-omapfb
On Fri, Dec 28, 2012 at 2:08 AM, Maarten Maathuis madman2...@gmail.com wrote: On Thu, Dec 27, 2012 at 8:48 PM, Denis 'GNUtoo' Carikli gnu...@no-log.org wrote: Hi, I've been trying to add rotation to the out of tree xf86-video-omapfb(I'm aware of xf86-video-omap but I've an omap3, and beside, it requires a staging kernel driver). So far I got rotation working(xrandr -o 1 works). But when I want to rotate back (xrandr -o 0) Xorg checks if the requested X resolution is smaller or equals to the masimum allowed Xresolution and it fails... The thing is that I've been using a hack to make it work: instead of keeping the same resolution and just making rotate the display content, I've changed the resolution too. My device is the GTA04 and it has a 480x640 display, so when rotating a new mode is created(640x480): root@om-gta04:~# xrandr -q Screen 0: minimum 8 x 8, current 640 x 480, maximum 480 x 640 LCD connected 640x480+0+0 left (normal left inverted right x axis y axis) 0mm x 0mm 640x48066.8 + 480x640 (0x41) 22.2MHz h: width 480 start 504 end 512 total 520 skew0 clock 42.6KHz v: height 640 start 644 end 646 total 648 clock 65.7Hz This shouldn't happen and instead I should use the normal approach, which is not to change the resolution... But that fails too: My display is in portrait mode, and so when rotating the image changes to 640x480, from the point 0.0 and isn't rotated, which result in the image going over the physical screen dimentions... The code I've been developing is here: https://gitorious.org/gnutoo-s-programs-for-shr/xf86-video-omapfb/commit/834a2b938cbff98e6f69ff66789cf422e3e2d483 I'd like to make the correct way work and rotate, but I've no idea of how... Denis. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel As far as i remember you typically allocate a shadow (there are some driver hooks for that, check existing drivers like intel, radeon or nouveau). This will become the new scanout buffer and this has the rotated dimensions. The original rendering will still be done to the normal framebuffer. Composite with rotation in combination with damage (a system used in X to track what areas have been rendered to i.e. damaged) is used to keep the shadow up to date. You should probably implement the shadow hooks that are present in the crtc structure. You should make sure this shadow allocation gets used as the framebuffer. And you should check if your composite implementation supports rotation, if not it may be necessary to expand it with support for any scaling/rotation matrix or else add a special case for 90 degree rotation if your hardware supports that. -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. I forgot to mention that decision/logic for the shadow allocation is done inside the xserver, so it's not a choice you have. -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Adding rotation to xf86-video-omapfb
Hi, On 28 December 2012 01:08, Maarten Maathuis madman2...@gmail.com wrote: As far as i remember you typically allocate a shadow (there are some driver hooks for that, check existing drivers like intel, radeon or nouveau). This will become the new scanout buffer and this has the rotated dimensions. The original rendering will still be done to the normal framebuffer. Composite with rotation in combination with damage (a system used in X to track what areas have been rendered to i.e. damaged) is used to keep the shadow up to date. You should probably implement the shadow hooks that are present in the crtc structure. You should make sure this shadow allocation gets used as the framebuffer. And you should check if your composite implementation supports rotation, if not it may be necessary to expand it with support for any scaling/rotation matrix or else add a special case for 90 degree rotation if your hardware supports that. As you can see from the linked diff, the fbdev driver implements rotation as the hardware can do it on scanout. It also doesn't support any acceleration, given that OMAP carries an SGX, so neither the shadow nor Composite hooks are relevant here. Cheers, Daniel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
