Created attachment 113142 [details] Xorg on vt7 log I'm on Gentoo, video card is 945GSE, xorg 1.16.3, xf86-video-intel 2.99.917 (SNA), linux 3.18.5. I also use lightdm and systemd. Important note: I have no fbcon kernel module loaded, so there are no text VTs on my laptop. Suppose we have X session (only terminal emulator in my case) running on vt7 started from lightdm. "dm-tool switch-to-greeter" is a command that should start second X server on vt8, display lightdm greeter there, and switch to vt8 so that I could login as different user or unlock my session on vt7. It works fine if screensaver is not active. If I run the following command: "sleep 0.1; xset s activate; dm-tool switch-to-greeter", second X server on vt8 comes up, greeter also starts, but screen remains blank. I can enter my password blindly and return to vt7, screen turns on then. So the issue is that if I have Xorg running with screensaver active (and the screen blanked), and I start another Xorg (via lightdm, "dm-tool switch-to-greeter"), second Xorg will come up with screen turned off. This is major blocker for me, because normally I use Xfce, lightdm and light-locker, and when screensaver automatically activates after 5 minutes of inactivity, light-locker does the switch to vt8 where lightdm greeter should appear, but screen remains blank, so I can only enter my password blindly. Some other test cases: If I modprobe fbcon, bug disappears. What I think about this: 1. Without fbcon: Xorg on vt7 turns off the screen (xset s activate), then we get switched to vt8 (screen remains off), then Xorg on vt8 starts and does not turn on the screen. 2. With fbcon: Xorg on vt7 turns off the screen (xset s activate), then we get switched to vt8, fbcon turns screen on, then Xorg on vt8 starts with screen already turned on. If I replace "xset s activate" with "xset dpms force on", bug disappears. If I run "DISPLAY=:1 xrandr --auto" when Xorg on vt8 starts, screen turns on. Steps to reproduce (sorry, I failed to start X server without lightdm): 1. Setup lightdm and disable fbcon kernel module. 2. Setup simple minimalistic X session: create file ~/.xsession and put command to start your favorite terminal emulator (xfce4-terminal in my case) into that file. 3. Login using lightdm to this session. 4. Open two tabs in your terminal emulator; get root in one of them (e.g. using "sudo -i"). 5. Put the following command into root shell: sleep 10; DISPLAY=:1 xrandr --current; DISPLAY=:1 xrandr --auto; DISPLAY=:1 xrandr --current 6. Put the following command into your user's shell: sleep 0.1; xset s activate; dm-tool switch-to-greeter 7. Run the first command, then the second one. 8. Screen should go blank (screensaver activates). 9. Second Xorg on vt8 starts. VT8 activates, but screen is blank (bug here). 10. After 10 seconds "xrandr --auto" will run (do you remember the command in root shell?), screen will turn on. 11. Enter your password to return to vt7. 12. Here is my output from xrandr commands: before xrandr --auto (something very wrong): ---- xrandr: Output LVDS1 is not disconnected but has no modes xrandr: Output VGA1 is not disconnected but has no modes xrandr: Output VIRTUAL1 is not disconnected but has no modes Screen 0: minimum 8 x 8, current 1024 x 600, maximum 32767 x 32767 LVDS1 connected (normal left inverted right x axis y axis) VGA1 connected (normal left inverted right x axis y axis) VIRTUAL1 connected (normal left inverted right x axis y axis) ---- after xrandr --auto (good): ---- Screen 0: minimum 8 x 8, current 1024 x 600, maximum 32767 x 32767 LVDS1 connected 1024x600+0+0 (normal left inverted right x axis y axis) 220mm x 129mm 1024x600 60.00*+ 65.00 800x600 60.32 56.25 640x480 59.94 VGA1 disconnected (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis) ---- I also attach logs for two Xorg instances involved. Why do I think it is intel driver bug? Because xrandr --current shows something really messy when Xorg is started with blank screen. Driver should initialize video modes on startup.
Created attachment 113143 [details] Xorg on vt8 log
The driver inherits the video modes as set by the user. If the user has turned off all outputs, that is what the user must want and we wait until the user requests something different.
(In reply to Chris Wilson from comment #2) > The driver inherits the video modes as set by the user. If the user has > turned off all outputs, that is what the user must want and we wait until > the user requests something different. Please explain some things. I understand that if I turn off my output (e.g. xrandr --output LVDS1 --off), I will get second X server with blank screen. But I'm just activating screensaver, it doesn't turn off the output, as I can see from xrandr --current: # screen is on: Screen 0: minimum 8 x 8, current 1024 x 600, maximum 32767 x 32767 LVDS1 connected 1024x600+0+0 (normal left inverted right x axis y axis) 220mm x 129mm 1024x600 60.00*+ 65.00 800x600 60.32 56.25 640x480 59.94 VGA1 disconnected (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis) # after xrandr --output LVDS1 --off: Screen 0: minimum 8 x 8, current 8 x 8, maximum 32767 x 32767 LVDS1 connected (normal left inverted right x axis y axis) 1024x600 60.00 + 65.00 800x600 60.32 56.25 640x480 59.94 VGA1 disconnected (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis) # after xset s activate: Screen 0: minimum 8 x 8, current 1024 x 600, maximum 32767 x 32767 LVDS1 connected 1024x600+0+0 (normal left inverted right x axis y axis) 220mm x 129mm 1024x600 60.00*+ 65.00 800x600 60.32 56.25 640x480 59.94 VGA1 disconnected (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis) As you can see, "xset s activate" does not turn off LVDS1 like "xrandr --output LVDS1 --off" does, because "xrandr --current" output is the same for working screen and for activated screensaver. So when screensaver is working, video output is not actually turned off, so second Xorg should inherit current video mode, doesn't it? But instead of it, driver detects video output states absolutely wrongly: xrandr: Output LVDS1 is not disconnected but has no modes xrandr: Output VGA1 is not disconnected but has no modes xrandr: Output VIRTUAL1 is not disconnected but has no modes Screen 0: minimum 8 x 8, current 1024 x 600, maximum 32767 x 32767 LVDS1 connected (normal left inverted right x axis y axis) VGA1 connected (normal left inverted right x axis y axis) VIRTUAL1 connected (normal left inverted right x axis y axis) Why are they all connected? Looks like a bug, huh. -- Also just now I experienced similar problem with detecting video output states just after boot (no second Xorg, just started first): max@laptop ~ % xrandr --current xrandr: Output VGA1 is not disconnected but has no modes xrandr: Output VIRTUAL1 is not disconnected but has no modes Screen 0: minimum 8 x 8, current 1024 x 600, maximum 32767 x 32767 LVDS1 connected 1024x600+0+0 (normal left inverted right x axis y axis) 220mm x 130mm 1024x600 60.00*+ VGA1 connected (normal left inverted right x axis y axis) VIRTUAL1 connected (normal left inverted right x axis y axis) max@laptop ~ % xrandr --auto max@laptop ~ % xrandr --current Screen 0: minimum 8 x 8, current 1024 x 600, maximum 32767 x 32767 LVDS1 connected 1024x600+0+0 (normal left inverted right x axis y axis) 220mm x 129mm 1024x600 60.00*+ 65.00 800x600 60.32 56.25 640x480 59.94 VGA1 disconnected (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis) As you can see, after a boot driver thought that VGA1 and VIRTUAL1 are connected, but they are not connected, and after xrandr --auto driver determined actual state. Is it also not a bug?
The screensaver does turn off the output, at the device level. > Why are they all connected? Looks like a bug, huh. The status is technically unknown since you have not asked X to query it yet. During startup we only look at the active mode on the active outputs rather than do a slow probe on all outputs. For your peace of mind, they are now reported correctly as unknown.
(In reply to Chris Wilson from comment #4) > The screensaver does turn off the output, at the device level. > > > Why are they all connected? Looks like a bug, huh. > > The status is technically unknown since you have not asked X to query it > yet. During startup we only look at the active mode on the active outputs > rather than do a slow probe on all outputs. > > For your peace of mind, they are now reported correctly as unknown. Thanks for the nice explanation! As lightdm relies on that fbcon will turn on the screen before Xorg starts, and lightdm can come up with no outputs enabled, I will report this bug to lightdm.
(In reply to Maxim Mikityanskiy from comment #5) > As lightdm relies on that fbcon will turn on the screen before Xorg starts, > and lightdm can come up with no outputs enabled, I will report this bug to > lightdm. That's actually a bug. The goal is for the kernel to do nothing and preserve the output configuration from the BIOS. (So whatever configuration is setup in hardware, or in device files, is preserved right up until the user applies their preferences). So that means that even without fbcon, we should basically continue to show the BIOS screen until the splashscreen loads or until the DE fires up (i.e. no flicker boot). The full BIOS preservation is still hidden behind i915.fastboot=1. From my pov, the display manager is the best place for the initial modesetting - precisely because it can store user preferences for different combination of monitors.
(In reply to Chris Wilson from comment #6) > (In reply to Maxim Mikityanskiy from comment #5) > > As lightdm relies on that fbcon will turn on the screen before Xorg starts, > > and lightdm can come up with no outputs enabled, I will report this bug to > > lightdm. > > That's actually a bug. The goal is for the kernel to do nothing and preserve > the output configuration from the BIOS. (So whatever configuration is setup > in hardware, or in device files, is preserved right up until the user > applies their preferences). So that means that even without fbcon, we should > basically continue to show the BIOS screen until the splashscreen loads or > until the DE fires up (i.e. no flicker boot). The full BIOS preservation is > still hidden behind i915.fastboot=1. In my situation, when I boot without fbcon and without i915.fastboot=1, BIOS leaves me text mode 80×25, then i915 module sets 1024×600 resolution on boot, then lightdm starts up with native resolution. The problem only shows up when I turn off the screen in first X session and start second lightdm greeter. Lightdm doesn't reenable the screen. Really, it should do some modesetting to avoid such situations (and to set initial video mode on first start if it is needed). What abount i915.fastboot... I tried booting without fbcon and with i915.fastboot=1. When lightdm started, my screen's resolution was 640×480, but lightdm thought it was 1024×600, so I could see top left corner of the picture. When I tried to move mouse to right edge of screen, screen started flickering. It stopped flickering when I returned my mouse back. Even "xrandr --auto" and "xrandr --output LVDS1 --mode 1024x600" didn't switch to 1024×600, "xrandr --current" thought it was current resolution. Something is broken with i915.fastboot... should it be reported to the kernel bugtracker?
(In reply to Maxim Mikityanskiy from comment #7) > (In reply to Chris Wilson from comment #6) > > (In reply to Maxim Mikityanskiy from comment #5) > > > As lightdm relies on that fbcon will turn on the screen before Xorg starts, > > > and lightdm can come up with no outputs enabled, I will report this bug to > > > lightdm. > > > > That's actually a bug. The goal is for the kernel to do nothing and preserve > > the output configuration from the BIOS. (So whatever configuration is setup > > in hardware, or in device files, is preserved right up until the user > > applies their preferences). So that means that even without fbcon, we should > > basically continue to show the BIOS screen until the splashscreen loads or > > until the DE fires up (i.e. no flicker boot). The full BIOS preservation is > > still hidden behind i915.fastboot=1. > > In my situation, when I boot without fbcon and without i915.fastboot=1, BIOS > leaves me text mode 80×25, then i915 module sets 1024×600 resolution on > boot, then lightdm starts up with native resolution. The problem only shows > up when I turn off the screen in first X session and start second lightdm > greeter. Lightdm doesn't reenable the screen. Really, it should do some > modesetting to avoid such situations (and to set initial video mode on first > start if it is needed). On VT switch, I have to remove the frontbuffer from the CRTC so that the second VT cannot snoop on the original contents. This is done by removing the primary plane, but it is supposed to leave the mode intact. So only if the CRTC are off before we VT switch should we lose the mode information between VT. Once you lose that information, how do we tell that apart from when the user intended for the screens to be off until he sets them? We always want to push the policy as close to the end user as possible, and the default of leaving things as we find them should result in fewer conflicts. > What abount i915.fastboot... I tried booting without fbcon and with > i915.fastboot=1. When lightdm started, my screen's resolution was 640×480, > but lightdm thought it was 1024×600, so I could see top left corner of the > picture. When I tried to move mouse to right edge of screen, screen started > flickering. It stopped flickering when I returned my mouse back. Even > "xrandr --auto" and "xrandr --output LVDS1 --mode 1024x600" didn't switch to > 1024×600, "xrandr --current" thought it was current resolution. Something is > broken with i915.fastboot... should it be reported to the kernel bugtracker? Yeah, if the BIOS was in VGA text mode, we should just have taken over completely and set a native mode (if actually setting anything).
Thanks again for your explanations! I've reported two bugs: https://bugs.launchpad.net/lightdm/+bug/1418019 - about lightdm should manage video modes. https://bugzilla.kernel.org/show_bug.cgi?id=92691 - about kernel setting up 640×480 and reporting 1024×600.
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.