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.