Adding rotation to xf86-video-omapfb

[Maarten Maathuis]

On Thu, Dec 27, 2012 at 8:48 PM, Denis 'GNUtoo' Carikli
<GNUtoo at 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 at 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
>    640x480        66.8 +
>   480x640 (0x41)   22.2MHz
>         h: width   480 start  504 end  512 total  520 skew    0 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 at 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.