Re: [PATCH 1/2] Revert "drm: hide unregistered connectors from GETCONNECTOR IOCTL"

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Tue, Oct 18, 2022 at 12:07:43PM +0200, Jonas Ådahl wrote:
> On Tue, Oct 18, 2022 at 12:58:53PM +0300, Ville Syrjälä wrote:
> > On Tue, Oct 18, 2022 at 11:27:19AM +0200, Jonas Ådahl wrote:
> > > On Tue, Oct 18, 2022 at 12:14:09PM +0300, Ville Syrjälä wrote:
> > > > On Mon, Oct 17, 2022 at 03:31:57PM +0000, Simon Ser wrote:
> > > > > This reverts commit 981f09295687f856d5345e19c7084aca481c1395.
> > > > > 
> > > > > It turns out this breaks Mutter.
> > > > 
> > > > A bit more detail would be a good to help future archaeologists.
> > > 
> > > Perhaps a better explanation is
> > > 
> > > It turns out this causes logically active but disconnected MST display
> > > port connectors to disappear from the drmModeGetResources() list,
> > 
> > That was the whole point was it not? So I'd drop the
> > "it turns out" part.
> > 
> > > meaning userspace is made to believe the connector is already disabled.
> > 
> > That wording to me implies its a generic issue affecting all
> > userspace when so far it looks like only mutter is affected.
> 
> Maybe other userspace was? I only found out by testing drm-next, and
> only tried using mutter when bisecting.
> 
> > So apparently mutter (for some reason) assumes that the
> > connector has somehow magically been disabled by someone
> > else if it disappears from the list of resources?
> 
> Mutter makes the assumption that connectors it can interact with are the
> ones that drmModeGetResources() return

I agree that on the face of it that assumption does seem
perfectly reasonable.

> - nothing magic about that.

Well it's expecting a bit magic from the kernel if it decides
that it doesn't need to disable what it already enabled.
But I guess it's more of a case that the code just never
expected this specific situation to happen, and thus the
results are what they are.

I suppose the only concern with the change is what happens
when you replug something back in before the old stuff has
disappeared and you now have two connectors for the same
thing on the list. IIRC the ddxen at least try to reuse
the same xrandr output for the connector when the path
prop matches. I suspect it might work by accident due
to the new connector appearing (hopefully) later in the
list than the old connector. But would probably need to
test this to make sure.

-- 
Ville Syrjälä
Intel