Adding rotation to xf86-video-omapfb

[Maarten Maathuis]

On Fri, Dec 28, 2012 at 3:50 AM, Daniel Stone <daniel at fooishbar.org> wrote:
> Hi,
>
>
> On 28 December 2012 01:08, Maarten Maathuis <madman2003 at 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.