Hi David, On Tuesday 17 July 2012 14:23:18 David Herrmann wrote: > On Tue, Jul 17, 2012 at 1:24 PM, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> 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. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
