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

[David Herrmann]

Hi Philip

On Tue, Jan 22, 2013 at 9:59 PM, Philip Withnall <philip at tecnocode.co.uk> wrote:
> Here's the third version of the fbdev backend. This includes all the
> fixes from the second version, plus a fix to use weston_launcher_open()
> instead of open() for evdev devices, as pointed out by MoD.
>
> This patch is a squashed and tidied up version of various commits on my
> branch:
> https://gitorious.org/~pwithnall/weston/pwithnalls-weston/commits/compositor-fbdev.
> As far as I'm concerned, it's now ready to be merged, pending a final
> round of review (since there weren't any replies to v2 of the patch).
>
>
> Add 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.
>
> The refresh rate is calculated from the frame buffer's metadata. Every frame
> is finished in synchrony with the refresh rate.
>
> Frame buffer devices are currently specified on the command line (or using
> the default of /dev/fb0); udev could be used in future to enumerate them.
>
> pixman is used for compositing, and a suitable pixman format is built from
> the frame buffer's metadata. This doesn't support the full range of
> frame buffer formats, but does support varying BPPs of RGBA and ARGB. That
> should be enough for now.
>
> The following are not currently supported:
>  • FOURCC
>  • Non-packed formats (interleaved, planes, etc.)
>  • Non-true-colour formats (monochrome, greyscale, etc.)
>  • Big-endian formats (with component MSBs on the right)
>  • Non-RGBA and non-ARGB formats
>
> Signed-off-by: Philip Withnall <philip at tecnocode.co.uk>
> ---

I tested it and most of it works like a charm. It's pretty fast thanks
to pixman even on my intel gen3 hardware. However, you need to do a
full modeset on VT-Enter.

That is, if another process uses the fbdev device while weston is
inactive and changes the resolution or whatever, then weston needs to
reset this during VT-enter. Otherwise, the monitor will be dead.
Especially for DRM-fbdev backends this is important as these always
perform a modeset if a DRM user takes over.

So what I recommend is closing the device on VT-Leave and reopen it on
VT-Enter. You should cache the previous state and check whether it
changed. If it didn't, do nothing, otherwise perform a mode-change and
notify weston-core (you probably need to remove and readd the output
then).
Otherwise VT switches will not work reliably.

Everything else works pretty well on inteldrm (i915 fbdev helper),
vesafb and udlfb here.

Regards
David