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.
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
