Created attachment 1291916 [details] Xorg.0.log 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
Created attachment 1291918 [details] nvidia bug report
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"
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.
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) and 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. Jon
Created attachment 1292433 [details] nvidia debug report for my Envy 5 laptop
(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. Jon
@Jon, Are you able to reproduce using Gnome ? That would probably helps to redirect the issue to the appropriate Desktop Environment. Thx
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. Jon
@Jon, 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. Thx
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Just encountered a system that had this problem. An Asus FX53V laptop with an nvidia GTX1050 card running F29, kernel 4.18.14 and the 396.54 nvidia drivers from rpmfusion. In this case the machine is running a KDE install so the display manager is SDDM. The symptoms are the same: the screen is black (with no backlight) when the display manager runs. If you switch to a console VT it appears fine. If you enter the login credentials at the SDDM greater, the desktop appears (presumably because kscreen always sets the screen parameters at login using the equivalent of an xrandr call). Things are fine upon switching to gdm. I won't be able to supply any useful additional information because I don't have any continued access to the problematic laptop. I've asked the person who showed me the problem to sign up here; hopefully they can do so and provide any additional information that might be needed.
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.