dma-buf/fbdev: one-to-many support

[David Herrmann]

Hi Laurent and Alan

On Tue, Jul 17, 2012 at 1:24 PM, Alan Cox <alan at lxorguk.ukuu.org.uk> wrote:
>> The main issue is that fbdev has been designed with the implicit assumption
>> that an fbdev driver will always own the graphics memory it uses. All
>> components in the stack, from drivers to applications, have been designed
>> around that assumption.
>>
>> We could of course fix this, revamp the fbdev API and turn it into a modern
>> graphics API, but I really wonder whether it would be worth it. DRM has been
>> getting quite a lot of attention lately, especially from embedded developers
>> and vendors, and the trend seems to me like the (Linux) world will gradually
>> move from fbdev to DRM.
>>
>> Please feel free to disagree :-)
>
> I would disagree on the "main issue" bit. All the graphics cards have
> their own formats and cache management rules. Simply sharing a buffer
> doesn't work - which is why all of the extra gloop will be needed.

This is exactly why I suggested adding an "owner" field. A driver
could then check whether the buffer it is supposed to share/takeover
is from a compatible (or even the same) driver/device. If it is not,
it would simply reject using the buffer. Then again, if we have
multiple devices that are incompatible, we are still unable to share
the buffer. So this attempt would only be useful if we have tons of
DisplayLink devices attached that all use the same driver, for
example.

Regarding DRM: In user-space I prefer DRM over fbdev. With the
introduction of the dumb-buffers there isn't even the need to have
mesa installed. However, fblog runs in kernel space and currently
cannot use DRM as there is no in-kernel DRM API. I looked at
drm-fops.c whether it is easy to create a very simple in-kernel API
but then I dropped the idea as this might be too complex for a simple
debugging-only driver. Another attempt would be making the
drm-fb-helper more generic so we can use this layer as in-kernel DRM
API.

I had a deeper look into this this weekend and so as a summary I think
all in-kernel graphics access is probably not worth optimizing it.
fbcon is already working great and fblog is only used during boot and
oopses/panics and can be restricted to a single device. I will have
another look at the drivers in a few weeks but if you tell me that
this is not easy to implement, I will probably have to let this idea
go.

Thanks
David