Description of problem: Display dimmer and display brighten keys are not working. Version-Release number of selected component (if applicable): I ran lspci and I think I am supposed to put here the following: VGA compatible controller: Intel Corporation Device 191b (rev 06). How reproducible: The problem is not typically reproduced, it is just occurring all the time when computer is on. Steps to Reproduce: 1.Turn on computer. 2. 3. Actual results: Display brightness is not adjustable, no matter what. Expected results: Expect to be able to use display darken/brighten keys (equivalent to F11/F12, respectively), to adjust brightness of display. Additional info: The following is the terminal screen of output of dmesg | tail after pressing the display darken (F11) key, and then the display brighten (F12) key. [jloring@jloring ~]$ dmesg | tail [ 46.753944] fuse init (API version 7.23) [ 46.901455] Bluetooth: RFCOMM TTY layer initialized [ 46.901461] Bluetooth: RFCOMM socket layer initialized [ 46.901499] Bluetooth: RFCOMM ver 1.11 [ 53.895617] brcmfmac: brcmf_add_if: ERROR: netdev:wlp2s0 already exists [ 53.895625] brcmfmac: brcmf_add_if: ignore IF event [ 53.928136] brcmfmac: brcmf_add_if: ERROR: netdev:wlp2s0 already exists [ 53.928143] brcmfmac: brcmf_add_if: ignore IF event [ 66.778750] Adjusting tsc more than 11% (5424060 vs 7184618) [ 1904.127575] dell_wmi: Unknown key 152 pressed [jloring@jloring ~]$ dmesg | tail [ 46.753944] fuse init (API version 7.23) [ 46.901455] Bluetooth: RFCOMM TTY layer initialized [ 46.901461] Bluetooth: RFCOMM socket layer initialized [ 46.901499] Bluetooth: RFCOMM ver 1.11 [ 53.895617] brcmfmac: brcmf_add_if: ERROR: netdev:wlp2s0 already exists [ 53.895625] brcmfmac: brcmf_add_if: ignore IF event [ 53.928136] brcmfmac: brcmf_add_if: ERROR: netdev:wlp2s0 already exists [ 53.928143] brcmfmac: brcmf_add_if: ignore IF event [ 66.778750] Adjusting tsc more than 11% (5424060 vs 7184618) [ 1904.127575] dell_wmi: Unknown key 152 pressed [jloring@jloring ~]$
Weird. This really ought to work. The dell_wmi warning is most likely triggered when you press the keyboard backlight button (F10 or Fn+F10 depending on configuration), and the warning will go away when this patch lands: http://lkml.kernel.org/g/a343d7d11816d86d04c51505f6e33c5b99086ff6.1453244706.git.luto@kernel.org but that shouldn't be related. What graphics driver are you using? I've been running a bleeding-edge kernel on my 9350, so I may be out of touch with 4.3. Can you try booting with: i915.preliminary_hw_support=1 and seeing if the problem goes away? My guess is that the backlight keys on these laptops are implemented via the intel video opregion mechanism, and that only works if i915 loads, and Linux 4.3 might still consider i915 on Skylake to be 'preliminary'.
(In reply to Andy Lutomirski from comment #1) > > What graphics driver are you using? > I ran an $ lspci during the process of filing this bug, and I put in the bug description section what I thought was the requested information. I now realize that the requested information was pertinent to the component, which, for me and this bug, is the kernel (version 4.3.3-301.fc23.x86_64). However, when I was filing the bug report I thought it was asking for the version of the graphics driver. The information that I provided, thinking that the bug report template was asking for the graphics driver, was "VGA compatible controller: Intel Corporation Device 191b (rev 06)". Is this not the appropriate information? I am asking because I realize I might be mistaken, and I am not absolutely certain that the information that I provided is useful to you, and is the answer to you asking what graphics driver I am using. So, I might be wrong. Let me know if I am, and, if so, how to retrieve the information you are requesting, please. > > Can you try booting with: > > i915.preliminary_hw_support=1 > > and seeing if the problem goes away? > I am presuming this is an entry in a configuration file. If so, which file has this entry? and where might I find the file?
(In reply to John Loring from comment #2) > (In reply to Andy Lutomirski from comment #1) > > > > What graphics driver are you using? > > > I ran an > > $ lspci What I meant was: what driver actually loaded and is driving your hardware. But that's an annoyingly difficult question to answer if you don't know what you're looking for. The output of: $ dmesg | grep -P 'i915|drm' would do the trick. > > > > Can you try booting with: > > > > i915.preliminary_hw_support=1 > > > > and seeing if the problem goes away? > > > > I am presuming this is an entry in a configuration file. If so, which file > has this entry? and where might I find the file? It's a kernel boot parameter. You can edit it in to /etc/grub2.cfg or /etc/grub2-efi.cfg, depending on which one your system uses. Fedora makes this more complicated and more scary than it deserves to be. But before you do that, you can test it without changing any configuration. Reboot your system. When the boot menu that gives an option like "Fedora" or "Fedora 4.blah.whatever" pops up, press the down arror quickly to keep the screen from disappearing. Then use the up arrow to highlight the topmost item, then press 'e'. That will pop up a screen in which you can edit the boot process temporarily. You should see a line most of the way down that starts with 'linux' or 'linuxefi'. Append i915.preliminary_hw_support=1 (with at least one leading space) to the end of the line. Then press Ctrl-x to accept your change and boot. If my hunch is right, you'll have vastly improved graphics and full backlight control.
The command: $ dmesg | grep -P 'i915|drm' printed [ 1.339209] [drm] Initialized drm 1.1.0 20060810 [ 2.790552] snd_hda_intel 0000:00:1f.3: failed to add i915 component master (-19) I've gotta grab supper. I will work on the second portion of your entry just above a little bit later on this evening, unless directed otherwise.
Alright, I followed your directions in the second portion of your entry above, and in the process saw exactly what you mentioned, so I know I correctly followed you. However, there is still no function to my display darken/brighten buttons. Although, I should probably also mention, while we are on these keys, that my keyboard backlight button does work, and has consistently worked without editing boot parameters and prior to now. So, there is no problem with that.
Can you do: $ sudo cat /sys/module/i915/parameters/preliminary_hw_support and send the output?
The machine is still booted with the modified (edited) kernel parameter. Should I run the cat as is, or reboot normally, and then run the cat?
Run the cat as is, please. I want to make sure it stuck. Can you also paste in the output from: $ dmesg | grep -P 'i915|drm|video' Thanks!
[jloring@jloring ~]$ sudo cat /sys/module/i915/parameters/preliminary_hw_support [sudo] password for jloring: 1 [jloring@jloring ~]$ ================================== [jloring@jloring ~]$ dmesg | grep -P 'i915|drm|video' [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.3.3-301.fc23.x86_64 root=UUID=4330b08b-446f-4c73-b50a-df18835a4604 ro nomodeset rhgb quiet LANG=en_US.UTF-8 i915.preliminary_hw_support=1 [ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.3.3-301.fc23.x86_64 root=UUID=4330b08b-446f-4c73-b50a-df18835a4604 ro nomodeset rhgb quiet LANG=en_US.UTF-8 i915.preliminary_hw_support=1 [ 1.350265] [drm] Initialized drm 1.1.0 20060810 [ 2.718972] Linux video capture interface: v2.00 [ 2.737288] uvcvideo: Found UVC 1.00 device Integrated_Webcam_HD (0c45:6713) [ 2.764593] usbcore: registered new interface driver uvcvideo [ 2.825556] snd_hda_intel 0000:00:1f.3: failed to add i915 component master (-19) [jloring@jloring ~]$
OK, this is weird. I just booted 4.3.3-301.fc23.x86_64 on my XPS 13 9350, which is quite similar. [ 4.503253] [drm] Initialized drm 1.1.0 20060810 [ 4.598813] [drm] Memory usable by graphics device = 4096M [ 4.598818] fb: switching to inteldrmfb from EFI VGA [ 4.598918] [drm] Replacing VGA console driver [ 4.605120] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 4.605123] [drm] Driver supports precise vblank timestamp query. [ 4.624215] [drm] Initialized i915 1.6.0 20150731 for 0000:00:02.0 on minor 0 So John's i915 laptop isn't loading i915 or, if it is leading, it's not initializing. The relevant pci ids are: #define INTEL_SKL_GT2_IDS(info) \ INTEL_VGA_DEVICE(0x1916, info), /* ULT GT2 */ \ INTEL_VGA_DEVICE(0x1921, info), /* ULT GT2F */ \ INTEL_VGA_DEVICE(0x191E, info), /* ULX GT2 */ \ INTEL_VGA_DEVICE(0x1912, info), /* DT GT2 */ \ INTEL_VGA_DEVICE(0x191B, info), /* Halo GT2 */ \ INTEL_VGA_DEVICE(0x191A, info), /* SRV GT2 */ \ INTEL_VGA_DEVICE(0x191D, info) /* WKS GT2 */ (this is in https://git.kernel.org/cgit/linux/kernel/git/jwboyer/fedora.git/tree/include/drm/i915_pciids.h?h=f23) John has 0x191B. I have 0x1916. 0x1916 matches IS_SKL_ULT and 0x191B does not. Everything looks like it's in order, though, and this should work. John, can you check whether the output of 'lsmod' includes i915? After doing so, can you type 'sudo modprobe i915', describe anything obvious that happens, and paste in any output that gets appended to dmesg after running that? Can you attach the complete output from dmesg to this report? Can you also attach the output of: $ sudo lsinitrd /boot/initramfs-`uname -r`.img
Would it help to explain the weirdness if I told you my laptop boots in legacy mode and not UEFI? ******************************** [jloring@jloring ~]$ lsmod | grep i915 i915 1134592 0 i2c_algo_bit 16384 2 i915,nouveau drm_kms_helper 122880 2 i915,nouveau drm 335872 4 ttm,i915,drm_kms_helper,nouveau video 36864 4 i915,dell_wmi,nouveau,dell_laptop [jloring@jloring ~]$ ******************************** <After doing so, can you type 'sudo modprobe i915', describe anything obvious that happens, and paste in any output that gets appended to dmesg after running that?> I ran modprobe and it did not produce any output. Nothing obvious happened, in other words. Then I ran dmesg and I saw some output at the tail that I thought might have been produced by modprobe, so I ran modprobe again to see if I could get the suspected addendum duplicated, but nothing in dmesg changed. In other words my 'sudo modprobe i915' did not add anything to the end of dmesg. ******************************** I ran the dmesg and lsinitrd like you asked, and fed the output to a couple of respective files. I am going to save this entry, then attach those two files to this report directly.
Created attachment 1118666 [details] dmesg output (2016.01.26)
Created attachment 1118667 [details] lsinitrd output (2016.01.26)
Aha, so you have one of the fancy models with a discrete GPU. Let me loop in some people who might be able to help.
Actually, I know what their first question is likely to be. Can you run: $ sudo acpidump -o acpi.txt and attach acpi.txt?
Upstream bug: https://bugzilla.kernel.org/show_bug.cgi?id=111351
Created attachment 1118675 [details] 2016.01.26 (acpidump)
I am signing off for the night. Good night.
(In reply to John Loring from comment #9) > [jloring@jloring ~]$ sudo cat > /sys/module/i915/parameters/preliminary_hw_support > [sudo] password for jloring: > 1 > [jloring@jloring ~]$ > ================================== > [jloring@jloring ~]$ dmesg | grep -P 'i915|drm|video' > [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.3.3-301.fc23.x86_64 > root=UUID=4330b08b-446f-4c73-b50a-df18835a4604 ro nomodeset rhgb quiet > LANG=en_US.UTF-8 i915.preliminary_hw_support=1 Why do you have nomodset specified? That is going to tell the i915 driver to not do anything it is supposed to do. What happens if you remove that?
Josh, In this next trial bootup where I remove nomodeset, should I also leave out "i915.preliminary_hw_support=1", or should I include it in the kernel boot parameters like it did last time?
You can leave that enabled. It can only help as far as I can see.
I performed editing of kernel boot parameters as instructed, pressed Ctrl-x, and the computer didn't boot. It went to a completely black screen and stayed there. I gave it a couple of minutes to do something, but it just stayed there. I used the power switch for five seconds to turn it off. There it now is.
(In reply to Josh Boyer from comment #19) > (In reply to John Loring from comment #9) > > [jloring@jloring ~]$ sudo cat > > /sys/module/i915/parameters/preliminary_hw_support > > [sudo] password for jloring: > > 1 > > [jloring@jloring ~]$ > > ================================== > > [jloring@jloring ~]$ dmesg | grep -P 'i915|drm|video' > > [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.3.3-301.fc23.x86_64 > > root=UUID=4330b08b-446f-4c73-b50a-df18835a4604 ro nomodeset rhgb quiet > > LANG=en_US.UTF-8 i915.preliminary_hw_support=1 > > Why do you have nomodset specified? That is going to tell the i915 driver > to not do anything it is supposed to do. What happens if you remove that? I booted up normally to check something, and when I got into Gnome, the first thing I saw on the screen was a message stating that the Boot Image had crashed. Just an FYI.
I will repost my comment I put on kernel bugzilla here: https://bugzilla.kernel.org/show_bug.cgi?id=111351 I will just add that I had the boot image crash as well... but backlight control works without nomodeset parameter. Also I didn't use i915.preliminary_hw_support=1. " 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!
I really appreciate the latest post on this, but I do not understand how something can be a fix if it is breaking something else. For example, I am understanding that the backlight interface (display darken/brighten buttons on keyboard) is fixed. But, if now that it is fixed, your boot image is crashing on boot (or you are getting a message to that effect), then how does that "fix" the problem? Your "fix" creates another problem, and one that seems more detrimental to the normal course of your day's work, than the first. Is the boot image crash reproducible upon every boot, now that your display darken/brighten buttons are operable?
What is a "boot image crash", anyway? If you're getting an error message on the screen, can you describe it *exactly* or perhaps attach a picture of it to this bug report?
(In reply to Andy Lutomirski from comment #26) > What is a "boot image crash", anyway? > > If you're getting an error message on the screen, can you describe it > *exactly* or perhaps attach a picture of it to this bug report? This problem goes back to Comment 22 & 23 of this bug report. As it is now happening (which I will explain in a second), it may not technically be a "boot image crash" anymore. What is now happening when I remove "nomodeset" from kernel boot parameters, is I press Ctrl-x, and the computer begins to cycle out of its normal booting effort, to be rebooted, but somewhere along the way it hangs with a blank screen and only a blinking cursor in the upper left of the screen. So, I am not sure it is a technical "boot image crash" anymore. But, it's just not rebooting from the boot parameter edition screen if I remove "nomodeset" and tell it to boot up from that screen.
Here's what's going on: For the backlight controls to work on your laptop, you need a real display driver. On your device, it's presumably i915. This is by design of your laptop. No display driver, no backlight. For mostly historical reasons, x86 machines are capable of operating in a degraded mode without a real display driver. This gives limited resolution control, basically no support for external monitors, awful performance, and no nice extras like backlight control. nomodeset forces use of that degraded mode. (Not quite. I think that, on at least some kernels, it can force use of some intermediate legacy mode. On your hardware, I'm reasonably sure that nomodeset will turn i915 all the way off, though.) Your problem appears to be that the video driver doesn't work. nomodeset turns off the video driver, thus working around whatever problem you're having but introducing new, expected problems. I'm going to close this bug, because the actual issue you reported here (backlight controls not working if you specify the nomodeset parameter) is not a bug and neither can nor will be fixed as such. Please file a new bug about the problem you have with your graphics when you don't set nomodeset. It would be helpful if you boot with the nomodeset, rhgb, and quiet options all removed from the kernel command line. In that bug, give any information that shows up on the screen when the failure occurs. Also, describe how far into the boot process you get. Also, please try to attach the kernel logs. If you can't boot far enough to get them using 'dmesg', then boot up with nomodeset after a failed boot and run something like 'journalctl -b-1' to dump the logs from the previous boot.
As it has happened, I am now running kernel 4.4.8-300, and if I remove "nomodeset" from the boot parameters, my backlight controllers on the keyboard work.