On Fri, May 28, 2010 at 4:21 AM, Guennadi Liakhovetski
[off-list ref] wrote:

On Thu, 27 May 2010, Alex Deucher wrote:

quoted

On Thu, May 27, 2010 at 2:56 AM, Guennadi Liakhovetski [off-list ref] wrote:

...

quoted

quoted

Ok, let me explain what exactly I meant. Above I referred to "display
drivers," which is not the same as a "framebuffer controller driver" or
whatever you would call it. By framebuffer controller driver I mean a
driver for the actual graphics engine on a certain graphics card or an
SoC. This is the part, that reads data from the actual framebuffer and
outputs it to some hardware interface to a display device. Now this
interface can be a VGA or a DVI connector, it can be one of several bus
types, used with various LCD displays. In many cases this is all you have
to do to get the output to your display. But in some cases the actual
display on the other side of this bus also requires a driver. That can be
some kind of a smart display, it can be a panel with an attached display
controller, that must be at least configured, say, over SPI, it can be a
display, attached to the host over the MIPI DSI bus, and implementing some
proprietary commands. In each of these cases you will have to write a
display driver for this specific display or controller type, and your
framebuffer driver will have to interface with that display driver. Now,
obviously, those displays can be connected to a variety of host systems,
in which case you will want to reuse that display driver. This means,
there has to be a standard fb-driver - display-driver API. AFAICS, this is
currently not implemented in fbdev, please, correct me if I am wrong.

Another API to consider in the drm kms (kernel modesetting) interface.
 The kms API deals properly with advanced display hardware and
properly handles crtcs, encoders, and connectors.  It also provides
fbdev api emulation.

Well, is KMS planned as a replacement for both fbdev and user-space
graphics drivers? I mean, if you'd be writing a new fb driver for a
relatively simple embedded SoC, would KMS apriori be a preferred API?

It's become the defacto standard for X and things like EGL are being
built onto of the API.  As for the kms vs fbdev, kms provides a nice
API for complex display setups with multiple display controllers and
connectors while fbdev assumes one monitor/connector/encoder per
device.  The fbdev and console stuff has yet to take advantage of this
flexibility, I'm not sure what will happen there.  fbdev emulation is
provided by kms, but it has to hide the complexity of the attached
displays.  For an soc with a single encoder and display, there's
probably not much advantage over fbdev, but if you have an soc that
can do TMDS and LVDS and possibly analog tv out, it gets more
interesting.

drm has historically been tied to pci, but Jordan Crouse recently
posted changes to support platform devices:
http://lists.freedesktop.org/archives/dri-devel/2010-May/000887.html

Alex