On Wed, Dec 10, 2014 at 3:03 AM, Daniel Martin <[email protected]> wrote: > 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.
IIRC, Dave added a driver option for radeon and intel to pick if you want to keep them or not. Alex _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
