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.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
