Hi David,

On Tuesday 17 July 2012 14:23:18 David Herrmann wrote:

On Tue, Jul 17, 2012 at 1:24 PM, Alan Cox [off-list ref] wrote:

quoted

quoted

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.

My gut feeling is that, given the effort required to add new APIs, it would be 
more interesting to work on an in-kernel DRM API to make drmcon and drmlog 
implementations possible without any fbdev compatibility layer. That's rather 
a long term goal though.

-- 
Regards,

Laurent Pinchart