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

[Alex Deucher]

On Wed, Dec 10, 2014 at 3:03 AM, Daniel Martin <consume.noise at gmail.com> wrote:
> 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.

IIRC, Dave added a driver option for radeon and intel to pick if you
want to keep them or not.

Alex