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/ -- 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
