On Sat, May 29, 2010 at 6:06 AM, Ville Syrjälä <syrjala@xxxxxx> wrote: > 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. > http://www.mail-archive.com/dri-devel@xxxxxxxxxxxxxxxxxxxxx/msg48461.html I started writing a "dumb" API for KMS, it got stuck on whether to expose cursors or not, I must dig out the branch. It basically was a create + map API. I'll see if I can get it finished off. The main reason we avoided a fully generic interface is there isn't really a generic way to abstract acceleration on a modern GPU, and buffer allocation on most modern GPUs doesn't want a linear simple buffer. We felt doing a compromised generic interface would lead people down the wrong path into believing they could easily move from the "dumb" interface to a real accelerated one. There is a userspace library called libkms that abstracts this stuff, but I'd like to just have the kernel do it. Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
