Re: [PATCH] drm/crtc-helper: don't disable disconnected outputs

[Daniel Vetter <daniel.vetter@ffwll.ch>]

On Tue, Jun 25, 2013 at 3:09 AM, Dave Airlie <airlied@gmail.com> wrote:
> On Sun, Jun 16, 2013 at 6:41 AM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>> This has originally been added in
>>
>> commit a3a0544b2c84e1d7a2022b558ecf66d8c6a8dd93
>> Author: Dave Airlie <airlied@redhat.com>
>> Date:   Mon Aug 31 15:16:30 2009 +1000
>>
>>     drm/kms: add explicit encoder disable function and detach harder.
>>
>> I think it's the wrong thing to do for a few reasons:
>> - It's policy in the kernel. Userspace gets hotplug events when an
>>   output disconnects, and it can inquire about all the routing that is
>>   already set up. If userspace wants to disable a disconnected output
>>   it can simply do so itself.
>> - The reason for adding it given in the commit message was to improve
>>   use of shared encoders. But the disable_unused_functions call only
>>   happens after the modeset has been completed, so it won't help too
>>   much in making the modest succeed.
>> - We (at least in drm/i915, but iirc all other drivers work the same)
>>   ensure that if the user accidentally yanks the cable and then
>>   replugs, the same configuration will keep on working without any
>>   userspace actions required. For most outputs that's the case by
>>   default, and DP can have the same semantics with a simple re-train
>>   handler fired off from the hpd replug event. This breaks it since if
>>   the user is unlucky and hits the mouse, resulting in a panning of
>>   e.g. the integrated panel that modeset might kill the accidentally
>>   yanked output. Which isn't too great.
>>
>> i915 has applied this behaviour change as part of the bit modeset
>> review, thus far without resulting in an angry crowd with pitchforks:
>>
>
> The reason is that i915 hardware is nearly impossible to ever set
> something up that could trigger this on. You don't have
> shared encoders in places that could affect this from what I can see.

Actually we do have shared encoders, and on second consideration I
guess we could hit this. We get away with it though since we don't
really implement the connector modeset correctly for shared encoders:
We simply pick what has been last detected as connected ...

Of course that's a bit broken, and we have the bug reports to prove it
(and since the modeset rework they include noisy dmesg spam from the
checker about the inconsistencies even). I guess I should fix that up
first ;-)

> I know this will break the radeon card I have that I wrote this for
> originally, where if you alternate hotplugging a tv-out
> and vga that share the same encoder it won't work. I can probably drag
> that card out of whatever hole if fell into,
> but the given justifications have give me no confidence that this
> patch just isn't reverting the original commit without
> fixing anything else.
>
> I suspect I was testing hotplugging at fbcon not using X also.

Oh, that makes a lot of sense. fbcon kinda wants an atomic modeset
interface, but since it doesn't have one it expects the backend to
paper over any intermediate inconsistencies. I guess we should fix
that first.

For userspace I still think that it makes much more sense to obey
userspace's request and not silently kill outputs. We do that already
if userspace steals the crtc. But that's something userspace can
predict, wheras the exact connector->encoder relationship is more
elusive. So I think the right thing would be to fail such a modeset.

Anyway I agree that this patch needs a bit more prep work.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch