Bug 88965 - screen is not centered when activating second display
Summary: screen is not centered when activating second display
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-02-04 13:21 UTC by José Jorge
Modified: 2017-07-24 22:48 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
SINGLE OK (261.97 KB, image/jpeg)
2015-02-05 07:54 UTC, José Jorge
no flags Details
SINGLE KO (181.84 KB, image/jpeg)
2015-02-05 07:55 UTC, José Jorge
no flags Details
DUAL OK (692.51 KB, image/jpeg)
2015-02-05 07:55 UTC, José Jorge
no flags Details
DUAL KO (494.18 KB, image/png)
2015-02-05 07:55 UTC, José Jorge
no flags Details
Xorg log with comments where is display is buggy (37.97 KB, text/x-log)
2015-02-05 07:58 UTC, José Jorge
no flags Details
xrandr output with display is buggy (11.74 KB, text/plain)
2015-02-05 08:00 UTC, José Jorge
no flags Details
xrandr output with display is ok (11.74 KB, text/plain)
2015-02-05 08:01 UTC, José Jorge
no flags Details

Description José Jorge 2015-02-04 13:21:50 UTC
x11-driver-video-intel-2.99.917 (Mageia 4 Revision: 811713)

I use this two commands to switch from mono display to dual desktops:

SINGLE
xrandr --output VGA1 --off

DUAL
xrandr --output VGA1 --auto;sleep 1;xrandr --output VGA1 --pos 1790x0

Very often, when switching back to SINGLE, the image is only half visible, the rest of the screen is black. BUT THE MOUSE CURSOR CAN GO OVER ALL THE SCREEN. The clicks of mouse are at the good place, so all is like framebuffer comes back in the bad place.

I can workaround this switching back to DUAL and the front SINGLE again several times, till all is good.

This is a regression that does not happen with x11-driver-video-intel-2.21.15.
Comment 1 José Jorge 2015-02-04 13:25:17 UTC
I forgot to mention I experience the same bug on very different hardware :

- Intel Pentium G3220 (HSW GT1 Graphics)
- Old Intel 945GM
Comment 2 Chris Wilson 2015-02-04 13:37:46 UTC
Please attach your Xorg.0.log and "xrandr --verbose --current" before and after the loss of the image. If you could grab a photograph and a screenshot of the corruption that will be very useful. (The photograph shows us what is happening, the screenshot shows us what we think should be happending.)
Comment 3 José Jorge 2015-02-05 07:54:39 UTC
Created attachment 113178 [details]
SINGLE OK
Comment 4 José Jorge 2015-02-05 07:55:04 UTC
Created attachment 113179 [details]
SINGLE KO
Comment 5 José Jorge 2015-02-05 07:55:35 UTC
Created attachment 113180 [details]
DUAL OK
Comment 6 José Jorge 2015-02-05 07:55:59 UTC
Created attachment 113181 [details]
DUAL KO
Comment 7 José Jorge 2015-02-05 07:58:35 UTC
Created attachment 113182 [details]
Xorg log with comments where is display is buggy
Comment 8 José Jorge 2015-02-05 08:00:42 UTC
Created attachment 113187 [details]
xrandr output with display is buggy
Comment 9 José Jorge 2015-02-05 08:01:21 UTC
Created attachment 113188 [details]
xrandr output with display is ok
Comment 10 Chris Wilson 2015-02-05 08:18:11 UTC
Ok, that is consistent with the resizing to a single 1680x1050 framebuffer correctly (as we copy the centre of the old framebuffer onto the new smaller one before we set it on the scanout) and means that nothing was redrawn after the modesetting. Could you please double check with 2.99.917 (the log says 2.99.909)? My guess is that this is actually going to be with sending events to the compositor or the subsequent flip failing... If it still fails with .917 I would really, really like a debug log to see where the rendering stops.
Comment 11 José Jorge 2015-02-05 16:16:36 UTC
You are right : I didn't test with 2.99.917, my system had 2.99.909. With 2.99.917, I could not reproduce this bug anymore with 50+ switchs ;-)

I will open again if it comes back.


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.