On 9 December 2014 at 08:14, Aaron Plattner <[email protected]> wrote: > On 12/08/2014 01:01 AM, Daniel Martin wrote: >> >> On 5 December 2014 at 17:45, Keith Packard <[email protected]> wrote: >>> >>> Daniel Martin <[email protected]> writes: >>> >>>> From: Daniel Martin <[email protected]> >>>> >>>> When receiving a hotplug uevent, check if we have to add or remove >>>> outputs and act accordingly. >>>> >>>> Signed-off-by: Daniel Martin <[email protected]> >>>> --- >>>> With this patch we create or destroy outputs as a reaction to uevents. >>>> >>>> Due to my limited experience, the solution is either total crap, cause >>>> I'm doing it wrong, or it is that complicated, cause the server never >>>> had disappearing outputs in mind, or a combination of both. >>> >>> >>> Both of these patches look awesome; RandR and the xf86 code is all >>> designed to support output/crtc hot-plugging, but we've never had a >>> driver that did it. >> >> >> The intel driver does it. That's where I borrowed the functional ideas. >> >>> I've reviewed the code, and it looks correct. As it's essentially new >>> functionality, it would normally wait until after 1.17 anyways, but in >>> this case, we should wait until we have some way of testing it before >>> merging it in. >> >> >> I have an idea how one could test this on none-MST hw: add/remove the >> outputs depending on their connection state. So, you would just see >> connected ones. >> >>> For 7/8 and 8/8 in this series: >>> >>> Reviewed-by: Keith Packard <[email protected]> >> >> >> Thanks. Then I'll just move the log message in patch 8 and leave the >> hunk where it is. >> >> v2 with the update for patch 6 and 8, and the patch to test the (fake) >> output hotplug should arrive later this day. > > > Be careful with deleting outputs. The NVIDIA driver did this with MST > devices when we first implemented them and it really confused > gnome-settings-daemon. In general, RandR clients don't have a good way of > avoiding a BadMatch protocol error if an output they're talking about goes > away -- the timestamp mechanism doesn't protect against the actual XID > disappearing. We "fixed" the problem by just leaving outputs around forever > and in practice, stale MST outputs aren't a big deal, especially since they > get reused if the same MST topology reappears later.
Hmm, the awesome Xlib error handling ... Keith, what do you think, should I change the patch to keep the outputs? In case, I have to admin, that I can't manage to do this during this week. _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
