[PATCH] fbdev: Add an fbdev compositor backend using pixman and evdev

[David Herrmann]

Hi Vasily

On Tue, Jan 15, 2013 at 4:13 PM, Vasily Khoruzhick <anarsoul at gmail.com> wrote:
> On Tue, Jan 15, 2013 at 5:08 PM, Philip Withnall <philip at tecnocode.co.uk> wrote:
>> This is an initial version of an fbdev backend for Weston. I don't
>> consider it polished; I'm just looking for rough feedback at the
>> moment. The work is also available as a gitorious branch if anyone
>> prefers that:
>> https://gitorious.org/~pwithnall/weston/pwithnalls-weston/commits/compositor-fbdev
>>
>> One concern I have is that a lot of the input/evdev code was copied
>> verbatim from the rpi backend. It should probably be factored out into
>> evdev.c or something.
>>
>>
>> Initial version of a frame buffer backend using pixman to render to fbdev.
>> This has been tested against nouveaufb but nothing else. Much of the code
>> came straight from the rpi backend (and copyright has been attributed
>> accordingly).
>>
>> The behaviour of this backend on less modern frame buffers has yet to be
>> tested.
>
> Hi Philip,
>
> in general it looks OK to me, few notes:
>
> 1. It would be nice to use fb memory if there's enough space for 2 framebuffers.
> 2. You can do pageflip using xres_virtual, yres_virtual, and
> xoffset/yoffset from fb_var_screen_info
> 3. Too much code duplication (evdev part, vt switching), maybe it's
> time to unify that code from rpi,drm and fbdev backends?

FB-memory for compositing is slow. You shouldn't read it if possible,
so the shadow buffer is actually faster even though it adds an
additional copy. At least for most DRM drivers that is true.

Also don't do double-buffering via x/y-res_virtual. Many fbdev drivers
allow _any_ values in these fields so there is no reliable way to
detect whether an fbdev device really supports this. I had a lot of
troubles with this. But if we use a shadow buffer we don't need this,
anyway.
However, if you get it to work reliably, I'd love to hear how.

@Philip
One thing: please open FDs with O_CLOEXEC, it's just the way it's
supposed to be by default. We don't want to leak FDs. Will have a
deeper look later on.

Regards
David