Re: Idea of a v4l -> fb interface driver

["Ville Syrjälä" <syrjala@sci.fi>]

On Fri, May 28, 2010 at 03:41:46PM -0400, Alex Deucher wrote:
> On Fri, May 28, 2010 at 3:15 PM, Florian Tobias Schandinat
> > 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.

But actually getting your data onto the screen is a lot easier with
fbdev. There's no standard API in drm to actually allocate the
framebuffer and manipulate it. You always need a user space driver
to go along with the kernel bits.

I'm not saying fbdev is better than drm/kms but at least it can be
used to write simple applications that work across different
hardware. Perhaps that's something that should be addressed in the
drm API.

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/