On Sun, Apr 14, 2013 at 12:29:46AM -0400, Rob Clark wrote: > On Sat, Apr 13, 2013 at 5:45 PM, Thierry Reding [...] > > I had been thinking about this on and off for a while, but I haven't > > come up with anything concrete. Ideally we could just have some kind of > > event that userspace would listen for, so that new outputs can be > > dynamically added and userspace informed about them. Last time I checked > > most of the helpers assumed that the complete output configuration is > > known when the DRM device is registered, so some major rework will be > > required to efficiently make use of such dynamicity. > > I'm less worried about the kernel re-work.. more worried about the > fact that we have no way to know whether userspace knows to listen for > this new event. So anything down this path could, I think, be > considered as breaking userspace.
Yes, that's probably true. Although the typical use-case would be that the application would run on any of the detected outputs and if there is none to begin with it will just fail. If there already is one, it will try to use that instead and only fail to use a second one if it becomes available. > I think in the end, we need some way to have sort of "dummy" > connectors for output drivers which might or might not be probed, so > that from userspace perspective, non-present panels appear as displays > that are not plugged in. I can imagine that quite a few userspace programs will be broken by this as well. For instance if you have an LVDS panel, I'm pretty sure people will just assume that it can't be in a disconnected state and therefore won't deal with that case.
