[PATCH 2/3] modesetting: add dynamic connector hotplug support (MST) (v2)

[Aaron Plattner]

On 04/19/2015 08:52 PM, Dave Airlie wrote:
> On 14 April 2015 at 13:12, Keith Packard <keithp at keithp.com> wrote:
>> Dave Airlie <airlied at gmail.com> writes:
>>
>>> So we hot unplug, we remove the output XID from the server, in
>>> parallel the client does an operation with the output XID it has
>>> gotten already, and still believe is valid, and it gets BadMatch, and
>>> since hardly anyone handles X errors it falls over.
>>
>> Yeah, I was curious if you'd found an actual race condition that
>> couldn't be solved by correctly written applications. Sounds like it's
>> just 'buggy' clients.
>>
>> Given that there just aren't that many applications which deal with
>> RandR objects, it's pretty tempting to let them experience reality for a
>> year or so and expect that they'll get fixed.
>>
>> As I said, the alternative would be to amend the spec to say that
>> outputs may get added, but will never go away. That would enshrine their
>> behavior as compliant, and ensure that we'd never break them in the
>> future.

I can implement that.

>> Frankly, I think I'd probably be OK with either plan, the only one I'm
>> not up for is supporting both modes with a configuration parameter that
>> no-one in their right mind would enable.

This is what we have today in the nvidia driver. In practice, I don't 
think I've ever heard of anyone enabling the option to delete outputs, 
but it's also not a huge amount of code so no one has felt the need to 
rip it out yet.

> I'm sort of happy to just enshrine the outputs cannot be destroyed behaviour,

Me too.

> But I do wonder how many things would need fixing, it might just be mutter
> and a few things like that, though if gtk falls over then we should
> probably leave things alone.

The big one was gnome-settings-daemon on RHEL 5, IIRC. We have customers 
who run old versions of GNOME with very recent drivers and hardware, so 
unless someone invents a time machine, I don't think that configuration 
can be fixed.

> Aaron, any ideas on how prevalent the issue is, or if nvidia care enough, since
> I took the option from you!

I don't have a strong preference either way. We'll probably keep the 
option in our implementation until we have a reason to delete it, but 
I'd be kind of surprised if anyone ever actually needed it.

If RandR starts mandating that outputs never go away, I'll probably 
delete the option just in the interests of spec compliance.

> Dave.