Re: Idea of a v4l -> fb interface driver

[Florian Tobias Schandinat <FlorianSchandinat@gmx.de>]

Guennadi Liakhovetski schrieb:
> 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?

Yes that's a problem. The thing is that the virtual terminal requires us 
to always be able to switch to a resolution we once supported. Probably 
what I would do in such a case is switching the screen off and let the 
user figure out that he has done something "wrong". As we don't really 
know our users (applications) there is not much we can do but wait for 
the next check_var to solve this. So yes things that force us to be 
incompatible with our previous behaviour can do some harm if the user is 
not aware of it.

Note 1: Interesting that you mentioned viafb, the driver that is 
currently nearly completely incapable to determine any output device 
limitations.

Note 2: set_par returns a value but that's rather a mistake and we can't 
rely anyone to react on a sane way on error. check_var is the only place 
where framebuffers can say that they don't support something after this 
they have to support it regardless of any external events.


Thanks,

Florian Tobias Schandinat