Re: Idea of a v4l -> fb interface driver

[Guennadi Liakhovetski <g.liakhovetski@gmx.de>]

On Fri, 28 May 2010, Florian Tobias Schandinat wrote:

> 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.
> If the user wants the same content on multiple outputs just configure the
> driver to do so.
> 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).
> 
> The thing that's really missing in fbdev is a way to allow hardware
> acceleration for userspace.

How about a "simple" use-case, that I asked about in another my mail: how 
do you inform fbdev users, if a (DVI) display has been disconnected and 
another one with a different resolution has been connected?

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