How to handle disconnection of eDP panels due to dynamic display mux switches

[Daniel Dadap]

On 4/2/20 1:25 PM, Lukas Wunner wrote:
> On Thu, Apr 02, 2020 at 12:56:04PM -0500, Daniel Dadap wrote:
>> I'll check one of the eDP-based systems I've been experimenting on to see if
>> setting the VGA_SWITCHER_NEEDS_EDP_CONFIG capability in the handler is
>> sufficient to make i915 avoid poking the AUX channel when it's mux-switched
>> away.
> That will not be sufficient I'm afraid.  The capability was added in
> preparation for taking advantage of pre-calibration by the active GPU
> as permitted by the DP spec, but that feature only ever existed in the
> experimental patches I linked to and which I never got around to
> completing (so far).


Ah, I see. I'll take a look at those patches and see how far they go, then.


I just remembered another issue that falls out from the assumption that 
eDP is always connected: in my test setup, i915 always sees and 
advertises a connected eDP panel, even if the mux is switched away from 
i915's GPU before e.g. starting X. Presumably the panel was probed when 
starting up i915 to drive the console, and since eDP can't ever be 
disconnected in i915, it just remains "connected" forever. So I'm not 
sure that just proxying the aux channel through the switched-to GPU's 
driver will be quite enough, either, if we're not going to be hiding the 
mux switch from clients.


> BTW, if the inactive GPU sets up the eDP output with the precalibrated
> values and the mux is switched without using the PSR trick you've
> mentioned, will the transition be glitchy?
>
> If so, is there a chance to switch the mux in a vblank to avoid glitches?


I don't know. In my current PoC I'm just using X11 DPMS to shut down the 
head when it's muxed away and bring it back up when it's muxed back in, 
as a way to trigger link training when muxing back in and to shut off 
the head when muxed away. This leads to a rather lengthy and conspicuous 
blanking glitch on systems without PSR, and a conspicuous hesitation on 
systems with PSR. If we can refresh the display without doing a full 
modeset (I think DPMS in X.org's modesetting_drv.so does a full modeset, 
but I didn't investigate particularly closely), then I expect the 
duration of the switch can be reduced substantially, but I don't know to 
what extent it would still glitch.


>
>> (This would be in addition to hacking the can_switch() callback in the
>> GPU drivers to allow switching while there are still active KMS clients for
>> the purposes of this experiment, unless somebody can point me to a tree with
>> the WIP per-output switching Daniel Vetter mentioned.
> I'm not aware anyone ever bothered implementing per-output switching.
> Which hardware supports that anyway?  I documented the situation on
> the MacBook Pro in apple-gmux.c:
>
>   * The external DP port is only fully switchable on the first two unibody
>   * MacBook Pro generations, MBP5 2008/09 and MBP6 2010.
>   * The following MacBook Pro generations replaced the external DP port with a
>   * combined DP/Thunderbolt port and lost the ability to switch it between GPUs,
>   * connecting it either to the discrete GPU or the Thunderbolt controller.
>
> So only very old machines can switch the external DP port separately.
> We just switch it in unison with the LVDS panel on those machines for
> simplicity.


Yes, I noticed that apple-gmux switches both muxes in unison when I was 
initially evaluating vga-switcheroo. Daniel Vetter mentioned per-output 
switching was possible, without shutting down the switched-away-from 
GPU, but I didn't see any evidence of such functionality in the 
torvalds/linux tree or the drm/drm-next tree. I didn't search anywhere 
beyond that. Daniel, could you point out where the per-output switching 
support you mentioned can be found?


> I'm not aware of other contemporary machines besides MacBook Pros
> which allow switching the panel at runtime, let alone switch
> external ports separately.  Are you at liberty to divulge what
> hardware you're working on?  Just curious.


Sorry, not at this time.