Fedora got a report that the backlight controls on the Dell XPS 15 9550 w/ a discrete nvidia GPU aren't working. Lots of info here: https://bugzilla.redhat.com/show_bug.cgi?id=1301811 I don't know enough about how backlight controls are supposed to work to easily debug it without having an affected laptop. Help?
Created attachment 202571 [details] acpidump
Created attachment 202581 [details] dmesg
Need the original reporter to tell us the following information: 1 output of /sys/class/backlight 2 does the interface there work? check by: $ cd /sys/class/backlight/XXX $ cat max_brightness YYY # echo(as root) a_value_between_0_and_YYY > brightness
FWIW, the original reporter was running with nomodeset. If that's the root cause, then feel free to close this bug. (Sorry, I didn't notice that before I filed this bug.)
That could be, if the GPU's driver provides such functionality. The firmware claims supporting win8, so ACPI video will not register backlight control interface; if he uses nomodeset, then the GPU driver will not register either, so there is no backlight control interfaces left... Is there a reason why he uses nomodeset? If he doesn't use it, will the GPU interface appear and work? If so, then we can close this bug :-)
Hello all and thanks for this thread. I don't know what you would need, but as I have the same XPS 15 9550 with Intel/Nvidia 960M I can confirm that when I removed nomodeset kernel parameter the backlight started to work on Fedora 23, kernel 4.3.5. When I installed bumblebee stuff, the nouveau was disabled all around, but the original kernel parameter I set to be even able to start X (with nouveau) was left in GRUB config. In this state, when I tried to ls /sys/class/backlight it was all empty. Now that I removed nomodeset param, I got: [kai@localhost ~]$ ls /sys/class/backlight/ intel_backlight which works flawlessly. I can also comment on why the original reporter most probably had the nomodeset. This has to be related to nouveau driver because when I want to start Fedora23/Install in X, I had to use nomodeset boot options, otherwise the GUI/X won't start with lots and lots of error messages on the background. Anyways, thanks to all of you and also the original reporter for this thread!
Thanks for the info, so the intel_backlight interface works, I'll close this bug.
I posted a comment on this to the Red Hat Bugzilla site. See: https://bugzilla.redhat.com/show_bug.cgi?id=1301811 I was the OP for that site on this bug, pertinent also to a Dell XPS 15 (9550). Before I appeal for help on this, by getting others to go through all the trouble of helping me to troubleshoot this bug, I would like to know when this fix is going to get into a kernel update. I am on kernel 4.3.5-300 of Fedora. If this fix is getting into an update soon enough, I will just let it happen, update my PC, and be on my way. I would also like to mention that even though some people say the backlight interface works, I am not too sure I would rush to that conclusion, because deleting the "nomodeset" parameter from the boot configuration breaks the reboot and causes a boot image crash. If this so-called "fix" really does fix the problem, notwithstanding its consequential boot sequence trouble, then if I remove "nomodeset" from the configuration file, is it going to break my bootup? Maybe all of this would just be easier if Linux and Fedora get their heads together and write an update to this problem, and I just let the update take care of it when "upstream" becomes "current" and "stable". Suggestions?
I checked the dmesg you attached at redhat bugzilla, and 8086:191b suggests that you have a skylake GPU. If you have to use nomodeset to make it boot, I would say this is a GPU driver issue. Google 8086:191b showed me this: https://bbs.archlinux.org/viewtopic.php?id=204862 I think you can try the suggestions there: " i915.preliminary_hw_support=1 or install 4.3 kernel. You have a Skylake CPU, and integrated GPU was not enabled by default in 4.2 kernel. " Your attached dmesg suggests you are using "nomodeset" with "i915.preliminary_hw_support=1", which doesn't make much sense: my understanding is that nomodeset asks GPU driver to not do anything about the GPU card, so adding more support by specifying i915.preliminary_hw_support=1 isn't helpful. And it looks like Jozef can boot the computer to console mode at least without nomodeset, is it the same case for you? If so, then the i915 driver seems to work to some extent at least. Anyway, I have no experience in GPU driver and I have no idea which driver of the two is supposed to be used. The i915 bugzilla is at: https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel They may have some idea what to do with your laptop regarding the GPU issue. The backlight on Intel platforms with Intel GPU is taken care of by the GPU driver, i.e. i915 nowadays instead of ACPI, so when you can boot the laptop without using nomodeset but the backlight still doesn't work, you should let them know too. Under current situation, there is nothing we can do about backlight: the i915's interface is not created due to nomodeset, the ACPI video's interface is not created too due to i915 is not working(yes, ACPI video's interface requires i915 working on Intel platforms), there is nothing we can do to fix the backlight issue without solving the GPU issue first(and as Jozef's post indicates, once the i915 driver is working, the backlight will be working too).
(In reply to Aaron Lu from comment #9) > And it looks like Jozef can boot the computer to console mode at least > without nomodeset, is it the same case for you? No, it is not the same case for me. Aaron, I really appreciate all of the effort you developers are putting in to try correcting any errors. But, if I may make a request to help you help me, and any others who have similar/same hardware, could you please break down what I am supposed to do for me to participate in the effort to fix the bug. I am not a developer, and I think you developers have insight into this kind of thing that leaves my Linux knowledge in the pale compared to yours. Please don't send me in all different directions. The only way we are going to resolve this is slowly, carefully, step-by-step, and in a directed and purposeful manner. I know I am dealing with free software with Linux, but we are wasting our time if the process to a bug fix is not deliberate. Thanks. Now, please, what must I do to solve the GPU issue? Red Hat bugzilla is telling me to file a new bug report. But, I do not want this fix to be exclusive to the Fedora distribution kernel. I would like it to be in the general Linux build so that it will work on my laptop with any of several distros I may choose, namely, Debian and Fedora for now. So, again, what must I do to begin solving the GPU issue?
Created attachment 205991 [details] attachment-31284-0.html Hi, disable nouveau - use Intel driver (potentially with Nvidia - Bumblebee), remove nomodeset and you are good to go - and I know I have virtually same hardware :) Jozef On Wed, Feb 24, 2016, 22:24 <bugzilla-daemon@bugzilla.kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=111351 > > --- Comment #10 from John Loring <vftx2z@gmail.com> --- > (In reply to Aaron Lu from comment #9) > > > And it looks like Jozef can boot the computer to console mode at least > > without nomodeset, is it the same case for you? > > No, it is not the same case for me. > > Aaron, I really appreciate all of the effort you developers are putting in > to > try correcting any errors. But, if I may make a request to help you help > me, > and any others who have similar/same hardware, could you please break down > what > I am supposed to do for me to participate in the effort to fix the bug. I > am > not a developer, and I think you developers have insight into this kind of > thing that leaves my Linux knowledge in the pale compared to yours. Please > don't send me in all different directions. The only way we are going to > resolve > this is slowly, carefully, step-by-step, and in a directed and purposeful > manner. I know I am dealing with free software with Linux, but we are > wasting > our time if the process to a bug fix is not deliberate. > > Thanks. Now, please, what must I do to solve the GPU issue? Red Hat > bugzilla is > telling me to file a new bug report. But, I do not want this fix to be > exclusive to the Fedora distribution kernel. I would like it to be in the > general Linux build so that it will work on my laptop with any of several > distros I may choose, namely, Debian and Fedora for now. So, again, what > must I > do to begin solving the GPU issue? > > -- > You are receiving this mail because: > You are on the CC list for the bug. >
Hello, Jozef. Thank you for your response, but so that I have clarity on what I am doing, before I perform what you have suggested, would you allow me the opportunity to ask a few questions about it, please?
(In reply to John Loring from comment #10) > (In reply to Aaron Lu from comment #9) > > > And it looks like Jozef can boot the computer to console mode at least > > without nomodeset, is it the same case for you? > > No, it is not the same case for me. > > Aaron, I really appreciate all of the effort you developers are putting in > to try correcting any errors. But, if I may make a request to help you help > me, and any others who have similar/same hardware, could you please break > down what I am supposed to do for me to participate in the effort to fix the > bug. I am not a developer, and I think you developers have insight into this > kind of thing that leaves my Linux knowledge in the pale compared to yours. Sadly, I'm not a GPU driver developer but a backlight one. All I can say about your backlight is: its functionality should be provided by the i915 GPU driver. Please pay attention to the bug's category. After I get an understanding of the problem, I probably should move the bug to another category but I'm not sure where: i915 is not using kernel bugzilla and I'm not sure if this is their problem; I doubt if there is anyone looking at the nouveau driver issue if I move it to DRM/non-intel. > Please don't send me in all different directions. The only way we are going > to resolve this is slowly, carefully, step-by-step, and in a directed and > purposeful manner. I know I am dealing with free software with Linux, but we > are wasting our time if the process to a bug fix is not deliberate. > > Thanks. Now, please, what must I do to solve the GPU issue? Red Hat bugzilla > is telling me to file a new bug report. But, I do not want this fix to be > exclusive to the Fedora distribution kernel. I would like it to be in the > general Linux build so that it will work on my laptop with any of several > distros I may choose, namely, Debian and Fedora for now. So, again, what > must I do to begin solving the GPU issue? I don't understand GPU driver so... I think Jozef's suggestion is good and you should try that.
Oh I forgot to mention: once a fix is in upstream kernel, it will normally go to distro kernels too.
(In reply to Aaron Lu from comment #14) > Oh I forgot to mention: once a fix is in upstream kernel, it will normally > go to distro kernels too. Well, let's be clear. Jozef's fix was performed ultimately by him modifying his system, even though he was able to perform the fix after a kernel update. It would not be helpful to imply that in this case a kernel update is presently the fix for this problem. It obviously contributed to a fix for the problem, but did not per se fix the bug.
The word "fix" I mentioned in comment #14 doesn't mean Jozef's suggestion, I'm just describing the general rule that distro kernels will pick upstream fix.
Created attachment 206011 [details] attachment-28558-0.html I would say Aaron is right - this is definitely not a bug of Intel driver - which works for me on the same hardware - same laptop. I am no expert but I would say you are using nouveau driver, which is activated upon the Fedora (and probably other distros too) installation and upon detection of Nvidia chip in your (our) laptop. By following this guide: https://fedoraproject.org/wiki/Bumblebee#For_closed_source_solution you would essentially disable nouveau driver, which is buggy to say the least on your very recent hardware, activate Intel driver and install Nvidia closed sourced (proprietary) driver. After this remove the nomodeset option from kernel line in grub and I am sure your back-light will work just fine. Not to mention the possibility to use your high performance graphics on demand by using primusrun/optirun commands. If not, I would suggest opening a thread in support forums of the distro - other, more smart people might help you. Anyways, if a bug should be filled, it should be filled in against nouveau driver, which needs nomodeset option on our laptop to even boot into X, not the Intel one which works fine (at least in regards mentioned earlier). Or you could fill a bug against Fedora - in a sense that you should be able to choose between nouvau/Intel driver during the install process perhaps. On Thu, Feb 25, 2016 at 5:37 AM, <bugzilla-daemon@bugzilla.kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=111351 > > --- Comment #16 from Aaron Lu <aaron.lu@intel.com> --- > The word "fix" I mentioned in comment #14 doesn't mean Jozef's suggestion, > I'm > just describing the general rule that distro kernels will pick upstream > fix. > > -- > You are receiving this mail because: > You are on the CC list for the bug. >
(In reply to Jozef Peterka from comment #17) > Created attachment 206011 [details] > attachment-28558-0.html > After this remove the nomodeset option from kernel line in grub and I am sure > your back-light will work just fine. I did this, as suggested, and the computer would not boot past the grub menu. I had to go into rescue mode and put "nomodeset" back where I deleted them from in order to get a bootable computer. I think I am just going to keep updating and testing, as usual, before I do something that is irreparable to the current OS installation. Thanks for your efforts to assist me, but I think I am done with the tinkering and will just plug along without display brightness adjustment for now. 'Hoping for a fix in upstream, to be carried downstream to stable Fedora. Thanks again.
I must now add that I am running kernel 4.4.8-300 (Fedora 23), and by removing the "nomodeset" parameter from the boot parameters, I get functioning display darken/brighten controls on my keyboard. Thanks!