(adding V4L ML to CC and preserving the complete reply for V4L readers)

On Thu, 27 May 2010, Jaya Kumar wrote:

On Wed, May 26, 2010 at 10:09 PM, Guennadi Liakhovetski
[off-list ref] wrote:

quoted

Problem: Currently the standard way to provide graphical output on various
(embedded) displays like LCDs is to use a framebuffer driver. The
interface is well supported and widely adopted in the user-space, many
applications, including the X-server, various libraries like directfb,
gstreamer, mplayer, etc. In the kernel space, however, the subsystem has a
number of problems. It is unmaintained. The infrastructure is not being
further developed, every specific hardware driver is being supported by
the respective architecture community. But as video output hardware

I understand the issue you are raising, but to be clear there are
several developers, Geert, Krzysztof, and others who are helping with
the role of fbdev maintainer while Tony is away. If you meant that it
has no specific currently active maintainer person, when you wrote
"unmaintained", then I agree that is correct.

Exactly, I just interpreted this excerpt from MAINTAINERS:

FRAMEBUFFER LAYER
L:	linux-fbdev@vger.kernel.org
W:	http://linux-fbdev.sourceforge.net/
S:	Orphan

We're not sure where
Tony is and we hope he's okay and that he'll be back soon. But if you
meant that it is not maintained as in bugs aren't being fixed, then
I'd have to slightly disagree. Maybe not as fast as commercial
organizations seem to think should come for free, but still they are
being worked on.

quoted

evolves, more complex displays and buses appear and have to be supported,
the subsystem shows its aging. For example, there is currently no way to
write reusable across multiple platforms display drivers.

At first I misread your point as talking about multi-headed displays
which you're correct is not so great in fbdev. But "write reusable
across multi-platform display driver", I did not understand fully. I
maintain a fbdev driver, broadsheetfb, that we're using on arm and x86
without problems and my presumption is other fbdev drivers are also
capable of this unless the author made it explicitly platform
specific.

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.

In my experience with adding defio to the fbdev infra, the
fbdev community seemed quite good and I did not notice any aging
problems. I realize there's probably issues that you're encountering
where fbdev might be weak, this is good, and if you raise them
specifically, I think the community can work together to address the
issues.

quoted

OTOH V4L2 has a standard video output driver support, it is not very
widely used, in the userspace I know only of gstreamer, that somehow
supports video-output v4l2 devices in latest versions. But, being a part
of the v4l2 subsystem, these drivers already now can take a full advantage
of all v4l2 APIs, including the v4l2-subdev API for the driver reuse.

So, how can we help graphics driver developers on the one hand by
providing them with a capable driver framework (v4l2) and on the other
hand by simplifying the task of interfacing to the user-space?

I think it would help if there were more specific elaborations on the
functionality that you'd want the fbdev community to improve and how
it could reuse v4l2 for this.

Since some time the V4L2 kernel driver API includes a v4l2-subdev API, 
which is used to interface between drivers for various single components. 
Typical examples are USB camera bridges and camera sensors in webcams, 
TV-decoders and PCI framegrabber controllers, any of the above video 
signal sources (sensors or decoders) and a camera interface controller on 
a SoC. In all of the above cases the v4l2-subdev API is used, which allows 
you to use the same video sensor driver in a webcam configuration or with 
an SoC.

quoted

How about a v4l2-output - fbdev translation layer? You write a v4l2-output
driver and get a framebuffer device free of charge... TBH, I haven't given
this too much of a thought, but so far I don't see anything that would
make this impossible in principle. The video buffer management is quite
different between the two systems, but maybe we can teach video-output
drivers to work with just one buffer too? Anyway, feel free to tell me why
this is an absolutely impossible / impractical idea;)

Sounds interesting. I think that idea seems viable but I'm not sure
we'd want every usb webcam to register an fbdev interface if that is
part of the thoughts you're having. If you could elaborate on the
benefits, that'd be great.

No, sorry, webcam is a video-input (capture) device, whereas I am talking 
about video output devices like TV encoders. My example is the sh-mobile 
Video Output Unit (VOU) driver, that I've written recently. For it first 
of all we had to decide which subsystem to select - V4L2 output or fbdev. 
On the one hand, if we used fbdev, using the driver would be dead simple - 
just put a console on it, or the X-server or any other user-space 
software, capable of talking to an fbdev. OTOH we would have to come up 
with some (proprietary) API to interface to tv-encoders. So, we chose to 
use v4l2, which gave us a standard API, but the only user-space solution 
we found to interface to v4l2 output drivers was gstreamer, which also 
just recently acquired this capability and is not yet very well developed 
in that respect. That's why we thought about a v4l2-output - fbdev 
interface driver.

Thanks,
jaya

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/