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@xxxxxx http://www.sci.fi/~syrjala/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
