| Summary: | External monitor ("reverse PRIME", Output Sink) updates very slowly (1fps) when laptop screen is off | ||
|---|---|---|---|
| Product: | xorg | Reporter: | Peter Wu <peter> |
| Component: | Driver/intel | Assignee: | Chris Wilson <chris> |
| Status: | RESOLVED MOVED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
| Severity: | normal | ||
| Priority: | medium | CC: | peter |
| Version: | git | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
(In reply to Peter Wu from comment #0) > Other information: > A similar problem existed in the modesetting driver, fixed in Xorg 1.19 with > https://lists.x.org/archives/xorg-devel/2016-August/050797.html > I think that a similar fix can be developed for sna_display.c > (sna_covering_crtc). That is what sna_covering_crtc has been doing that for the last few years. The problem is that you don't have any Intel CRTCs from which we can use as a vblank source and so you suffer from the woeful present fallback, as we don't seem to be able to offload the vblanks onto the slave outputs. To speed up the fake timer, just use
diff --git a/present/present_fake.c b/present/present_fake.c
index 2350638ea..faff0e310 100644
--- a/present/present_fake.c
+++ b/present/present_fake.c
@@ -128,10 +128,7 @@ present_fake_screen_init(ScreenPtr screen)
*
* Otherwise, pretend that the screen runs at 60Hz
*/
- if (screen_priv->info && screen_priv->info->get_crtc)
- screen_priv->fake_interval = 1000000;
- else
- screen_priv->fake_interval = 16667;
+ screen_priv->fake_interval = 16667;
}
The real challenge would be to recognise that the window is only on the slave output (on a different Screen than PresentPixmap was called for) and pass along the request. Then you have the challenge to make sure that any drawing operations go back to the master/slave again.
Another challenge would be handling the case where a drawable overlaps two screens... how would that work? Whoever claims it first. At the moment the rule is user desired crtc, primary output->crtc, greatest covering, anything. Flips between monitors are not coordinated - from the plls up. That drift will only be worse with multiple drivers trying to coordinate the flip. The current solution is that one crtc is chosen as the magic timing source and we hope the others are close enough that no one complains. -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/issues/133. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Scenario: Hybrid graphics laptop with an laptop screen (eDP-1, Intel) and an external monitor connected to the Nvidia GPU (DP-1, nouveau). DP-1 (nouveau) is linked as output slave to the Intel GPU. (When Intel renders a picture, it is shown on the external screen connected to the Nvidia GPU.) Problem: When the lid is closed (and no outputs are active for Intel), stuff on the external monitor updates only every one second. Steps to reproduce: 1. Enable output source: xrandr --setprovideroutputsource nouveau Intel xrandr --output DP-1 --mode 2560x1440 --left-of eDP-1 2. Run "glxgears" and drag it to the external monitor. 3. Turn off Intel screen (e.g. xrandr --output eDP-1 --off or by closing the lid). Expected behavior: glxgears should be updating normally with 60fps. Actual behavior: glxgears updates with 1fps. Other information: A similar problem existed in the modesetting driver, fixed in Xorg 1.19 with https://lists.x.org/archives/xorg-devel/2016-August/050797.html I think that a similar fix can be developed for sna_display.c (sna_covering_crtc). Environment: Arch Linux x86_64 Intel i7-6700HQ, Nvidia GT 965M xorg-server 1.19.0-3 (but it occurred with 1.18.4 too) xf86-video-intel 1:2.99.917+746+g169c74f-2 xf86-video-nouveau 1.0.13+7+g1516d35-2