Bug 1464934 - Modesetting driver fails to set output on Optimus setup
Modesetting driver fails to set output on Optimus setup
Status: NEW
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: X/OpenGL Maintenance List
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2017-06-26 05:17 EDT by leigh scott
Modified: 2018-03-06 11:39 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Xorg.0.log (34.62 KB, text/plain)
2017-06-26 05:17 EDT, leigh scott
no flags Details
nvidia bug report (61.13 KB, application/x-gzip)
2017-06-26 05:22 EDT, leigh scott
no flags Details
nvidia debug report for my Envy 5 laptop (61.13 KB, application/x-gzip)
2017-06-27 14:51 EDT, Jon
no flags Details

  None (edit)
Description leigh scott 2017-06-26 05:17:12 EDT
Created attachment 1291916 [details]

Bug forwarded from https://bugzilla.rpmfusion.org/show_bug.cgi?id=4574

Description of problem:

modesetting driver fails to set output on optimus hardware

Actual results:

Pc boots up with no display set

Expected results:

display should be setup properly
Comment 1 leigh scott 2017-06-26 05:22 EDT
Created attachment 1291918 [details]
nvidia bug report
Comment 2 leigh scott 2017-06-26 05:23:46 EDT
It successfully probes the monitor but never sets it

[    50.460] (II) modeset(G0): Modeline "400x300"x120.6   20.00  400 420 484 528  300 300 302 314 doublescan +hsync +vsync (37.9 kHz d)
[    50.460] (II) modeset(G0): Modeline "400x300"x112.7   18.00  400 412 448 512  300 300 301 312 doublescan +hsync +vsync (35.2 kHz d)
[    50.460] (II) modeset(G0): Modeline "320x240"x120.1   12.59  320 328 376 400  240 245 246 262 doublescan -hsync -vsync (31.5 kHz d)
[    50.469] (II) modeset(G0): EDID for output HDMI-1-1
[    50.469] (==) modeset(G0): Using gamma correction (1.0, 1.0, 1.0)
[    50.469] (==) modeset(G0): DPI set to (96, 96)
[    50.469] (II) Loading sub module "fb"
[    50.469] (II) LoadModule: "fb"
[    50.470] (II) Loading /usr/lib64/xorg/modules/libfb.so
[    50.470] (II) Module fb: vendor="X.Org Foundation"
Comment 3 Hans de Goede 2017-06-26 05:43:04 EDT
For those who were not involved in the irc discussion, as well as a reminder for myself here is some more info:

The problem seems to be that when using an optimus laptop with the nvidia driver and the LCD panel driver as secondary gpu output by the intel gpu / modesetting driver that the mode is then not set on the LCD panel. Normally Xorg.log will say something like this:

[    34.915] (II) modeset(0): Output HDMI-1 connected
[    34.915] (II) modeset(0): Output HDMI-2 connected
[    34.915] (II) modeset(0): Output DP-1 disconnected
[    34.915] (II) modeset(0): Using spanning desktop for initial modes
[    34.915] (II) modeset(0): Output HDMI-1 using initial mode 1920x1080 +0+0
[    34.915] (II) modeset(0): Output HDMI-2 using initial mode 1920x1080 +1920+0

But when the modesetting driver is used for a secondary GPU those lines are missing and depending on the display-manager / desktop environment that may or may not be a problem. With gdm things work just fine (because mutter will setup the modes for all connected outputs itself), but with lightdm a manual "xrandr  --output  eDP-1-1    --mode 1920x1080" is necessary to setup the mode on the LCD panel and get things to work.

This bug is about looking into fixing this for lightdm (and others), note that the conclusion may be that this is too hard to fix on the Xorg side and that lightdm (and others) will need to be fixed instead.
Comment 4 Jon 2017-06-27 14:47:04 EDT
leight from RPM Fusion has requested that I post the hardware details of the two laptops that has this issue. 

HP Envy 7 laptop with 16 gigs memeory, 1TB hard drive and two graphic chips... 

00:02.0 VGA compatible controller: Intel Corporation HD Graphics 520 (rev 07)


01:00.0 3D controller: NVIDIA Corporation GM108M [GeForce 940M] (rev a2)

BTW... this is not the same laptop that I originally reported the problem on. That is a envy 5 with a 500 GB SSD and a 2TB hard drive. The Intel graphic chip is the same as above. I had to look in my first nvidia debug report for that info. 

Just to let the people know, I have posted two nvidia debug reports for the two laptops. 

Comment 5 Jon 2017-06-27 14:51 EDT
Created attachment 1292433 [details]
nvidia debug report for my Envy 5 laptop
Comment 6 Jon 2017-06-29 13:51:11 EDT
(In reply to Jon from comment #5)
> Created attachment 1292433 [details]
> nvidia debug report for my Envy 5 laptop

One thing I want to mention is that this issue happens under Fedora 25 and 26 beta and the work is the same for both. 

Comment 7 Nicolas Chauvet (kwizart) 2017-08-12 18:11:21 EDT

Are you able to reproduce using Gnome ? That would probably helps to redirect the issue to the appropriate Desktop Environment.
Comment 8 Jon 2017-08-19 15:41:53 EDT
I did a test as requested... 

I did this first...

sudo dnf install @gnome-desktop
sudo systemctl disable lightdm.service
sudo systemctl enable gdm.service

I also put back the original lightdm.config file to make sure that it is using the original copy. 

Reboot the laptop...

And it all works... Saw the Gnome logon page... entered the creds... and the desktop came up. 

Comment 9 Nicolas Chauvet (kwizart) 2018-03-06 05:16:49 EST

Thx for the feedback.
I think this should be reproduced using any more recent fedora (with updated xorg-server).

Right now, it seems like gdm is making some magic to have the feature, that lightdm might miss.


Note You need to log in before you can comment on or make changes to this bug.