[PATCH 8/8] modesetting: Add output hotplug support

[Aaron Plattner]

On 12/08/2014 01:01 AM, Daniel Martin wrote:
> On 5 December 2014 at 17:45, Keith Packard <keithp at keithp.com> wrote:
>> Daniel Martin <daniel.martin at secunet.com> writes:
>>
>>> From: Daniel Martin <consume.noise at gmail.com>
>>>
>>> When receiving a hotplug uevent, check if we have to add or remove
>>> outputs and act accordingly.
>>>
>>> Signed-off-by: Daniel Martin <consume.noise at gmail.com>
>>> ---
>>> 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 <keithp at keithp.com>
>
> 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.