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

[Daniel Martin]

On 9 December 2014 at 08:14, Aaron Plattner <aplattner at nvidia.com> wrote:
> 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.

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.