Re: Idea of a v4l -> fb interface driver

[Alex Deucher <alexdeucher@gmail.com>]

On Fri, May 28, 2010 at 3:15 PM, Florian Tobias Schandinat
<FlorianSchandinat@gmx.de> wrote:
> Alex Deucher schrieb:
>>
>> On Fri, May 28, 2010 at 4:21 AM, Guennadi Liakhovetski
>> <g.liakhovetski@gmx.de> wrote:
>>>
>>> On Thu, 27 May 2010, Alex Deucher wrote:
>>>
>>>>
>>>> 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.
>
> Well hiding complexity is actually the job of an API. I don't see any need
> for major changes in fbdev for complex display setups. In most cases as a
> userspace application you really don't want to be bothered how many
> different output devices you have and control each individually, you just
> want an area to draw and to know/control what area the user is expected to
> see and that's already provided in fbdev.

Users want to be able to dynamically change their display config on the fly.

> If the user wants the same content on multiple outputs just configure the
> driver to do so.

KMS provide an API to do that and a nice internal abstraction for handling it.

> If he wants different (independent) content on each output, just provide
> multiple /dev/fbX devices. I admit that we could use a controlling interface
> here that decides which user (application) might draw at a time to the
> interface which they currently only do if they are the active VT.
> If you want 2 or more outputs to be merged as one just configure this in the
> driver.
> The only thing that is impossible to do in fbdev is controlling 2 or more
> independent display outputs that access the same buffer. But that's not an
> issue I think.
> The things above only could use a unification of how to set them up on
> module load time (as only limited runtime changes are permited given that we
> must always be able to support a mode that we once entered during runtime).
>

What about changing outputs on the fly (turn off VGA, turn on DVI,
switch between multi-head and single-head, etc) or encoders shared
between multiple connectors (think a single dac shared between a VGA
and a TV port); how do you expose them easily as separate fbdevs?
Lots of stuff is doable with fbdev, but it's nicer with kms.

Alex

> The thing that's really missing in fbdev is a way to allow hardware
> acceleration for userspace.
>
>
> Regards,
>
> Florian Tobias Schandinat
>
>