Bug 1097436 - Fedora 20 detects backlight controll on desktop motherboard with Intel CPU and graphic-card
Summary: Fedora 20 detects backlight controll on desktop motherboard with Intel CPU an...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 20
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Hans de Goede
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-05-13 20:04 UTC by karlitos
Modified: 2015-07-29 17:52 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-07-14 07:20:25 UTC


Attachments (Terms of Use)
New patch 1/2 (1.73 KB, patch)
2014-06-12 13:16 UTC, Hans de Goede
no flags Details | Diff
New patch 2/2 (1.46 KB, patch)
2014-06-12 13:17 UTC, Hans de Goede
no flags Details | Diff

Description karlitos 2014-05-13 20:04:28 UTC
Description of problem:

I am running Fedora 20 on Intel I3 Haswell system build around Asus H87I-Plus mainboard. This is a desktop workstation hooked up on 24 LCD display and do not support any backlight controll. After the instalation of Fedora 20, I was surprised to see the backlight controll in the User menu in Gnome shell.

I checked "ls /sys/class/backlight/" and the output was "acpi_video0". So the system is somehow detecting a backlight controll, which is obviously wrong.

I tried adding "acpi_osi=Linux" and "acpi_backlight=vendor" to the boot kernel parameters. Now the system detects my Haswell Mini-ITX mainboard as Asus-eee PC. This can be seen on following output:

lsmod | grep eee :
eeepc_wmi              13151  0 
asus_wmi               23974  1 eeepc_wmi

journalctl -b | grep backlight : 
kernel: Command line: BOOT_IMAGE=/vmlinuz-3.14.3-200.fc20.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap vconsole.font=latarcyrheb-sun16 rd.lvm.lv=fedora/root rhgb quiet acpi_osi=Linux acpi_backlight=vendor 
kernel: Kernel command line: BOOT_IMAGE=/vmlinuz-3.14.3-200.fc20.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap vconsole.font=latarcyrheb-sun16 rd.lvm.lv=fedora/root rhgb quiet acpi_osi=Linux acpi_backlight=vendor 
gdm-Xorg-:0[962]: Kernel command line: BOOT_IMAGE=/vmlinuz-3.14.3-200.fc20.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap vconsole.font=latarcyrheb-sun16 rd.lvm.lv=fedora/root rhgb quiet acpi_osi=Linux acpi_backlight=vendor 
gnome-session[1074]: (gnome-settings-daemon:1118): power-plugin-CRITICAL **: gsd_power_backlight_abs_to_percentage: assertion 'max > min' failed 
gnome-session[1621]: (gnome-settings-daemon:1694): power-plugin-CRITICAL **: gsd_power_backlight_abs_to_percentage: assertion 'max > min' failed 

Here is also the output of grep '.*' /sys/class/dmi/id/*_* 2> /dev/null :


Version-Release number of selected component (if applicable):

/sys/class/dmi/id/bios_date:02/20/2014
/sys/class/dmi/id/bios_vendor:American Megatrends Inc.
/sys/class/dmi/id/bios_version:1006
/sys/class/dmi/id/board_asset_tag:To be filled by O.E.M.
/sys/class/dmi/id/board_name:H87I-PLUS
/sys/class/dmi/id/board_vendor:ASUSTeK COMPUTER INC.
/sys/class/dmi/id/board_version:Rev X.0x
/sys/class/dmi/id/chassis_asset_tag:Asset-1234567890
/sys/class/dmi/id/chassis_type:3
/sys/class/dmi/id/chassis_vendor:Chassis Manufacture
/sys/class/dmi/id/chassis_version:Chassis Version
/sys/class/dmi/id/product_name:All Series
/sys/class/dmi/id/product_version:System Version
/sys/class/dmi/id/sys_vendor:ASUS


How reproducible:
It happens always with a fresh install of Fedora 20.

Steps to Reproduce:
1. Install Fedora 20 on PC with H87I-PLUS.
2. Use Internal Intel HD4600 graphics/hook-up LCD monitor on internal HDMI output
3. Boot up the machine - there is a backlight controll in the user menu in gnome shell

Actual results:
"ls /sys/class/backlight/" gives the output "acpi_video0. Backlight controll present in the user menu in gnome shell.

Expected results:
No backlight controll detected and no backlight controll in the user menu in gnome shell.

Additional info:
I use the internal grahpics Intel HD4600 built in the Haswell Core I3 cpu.

Comment 1 Hans de Goede 2014-05-14 07:58:34 UTC
Hi,

Thanks for the bug report.

Can you please boot without any special kernel cmdline parameters, and then do "cat /sys/class/backlight/acpi_video0/max_brightness" and paste the output here ?

Also can you please try to boot with video.use_native_backlight=1 on the kernel commandline (and with no other special kernel commandline options), and see if that helps ?

Thanks,

Hans

Comment 2 karlitos 2014-05-14 09:43:36 UTC
So here is the output after boot without any  additional parameters:
--------------------------------------------------------------------

cat /sys/class/backlight/acpi_video0/max_brightness :
shows: 100

journalctl -b | grep backlight
- shows nothing

When moving the backlight slider in gnome user-menu there are lot of lines in journalctl:
bumbrlicek pkexec[3152]: gabinka: Executing command [USER=root] [TTY=unknown] [CWD=/home/gabinka] [COMMAND=/usr/libexec/gsd-backlight-helper --set-brightness 23]

The eee modules are still somehow there:
lsmod | grep eee
eeepc_wmi              13151  0 
asus_wmi               23974  1 eeepc_wmi

journalctl -b | grep eee
kvě 14 11:05:24 bumbrlicek kernel: input: Eee PC WMI hotkeys as /devices/platform/eeepc-wmi/input/input15
kvě 14 11:05:26 bumbrlicek gdm-Xorg-:0[906]: (**) Option "config_info" "udev:/sys/devices/platform/eeepc-wmi/input/input15/event12"
I suppose this is a separate issue which I should take care of.

----------------------------------------------------
Now with the  video.use_native_backlight=1 parameter
----------------------------------------------------
ls /sys/class/backlight/
shows: acpi_video0


 journalctl -b | grep backlight :
kernel: Command line: BOOT_IMAGE=/vmlinuz-3.14.3-200.fc20.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap vconsole.font=latarcyrheb-sun16 rd.lvm.lv=fedora/root rhgb quiet video.use_native_backlight=1
kernel: Kernel command line: BOOT_IMAGE=/vmlinuz-3.14.3-200.fc20.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap vconsole.font=latarcyrheb-sun16 rd.lvm.lv=fedora/root rhgb quiet video.use_native_backlight=1
gdm-Xorg-:0[917]: Kernel command line: BOOT_IMAGE=/vmlinuz-3.14.3-200.fc20.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap vconsole.font=latarcyrheb-sun16 rd.lvm.lv=fedora/root rhgb quiet video.use_native_backlight=1

Comment 3 Hans de Goede 2014-05-14 09:58:02 UTC
Hmm, bummer, I was hoping that video.use_native_backlight=1 would help.

Thanks for the info, can you try with acpi_backlight=vendor on the kernel command-line please, and then again collect the output of "ls /sys/class/backlight/" ?

As for the eeepc stuff, it looks like Asus slapped a laptop derived BIOS on your motherboard, as long as those modules are not causing any issues / weird behavior I would just ignore them and any logfile messages caused by them.

Comment 4 karlitos 2014-05-14 11:12:13 UTC
The acpi_backlight=vendor parameter results in no backlight-slider in user-menu in gnome.

The output of ls /sys/class/backlight/ is now eeepc-wmi

journalctl -b | grep backlight :
kernel: Command line: BOOT_IMAGE=/vmlinuz-3.14.3-200.fc20.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap vconsole.font=latarcyrheb-sun16 rd.lvm.lv=fedora/root rhgb quiet acpi_backlight=vendor
kernel: Kernel command line: BOOT_IMAGE=/vmlinuz-3.14.3-200.fc20.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap vconsole.font=latarcyrheb-sun16 rd.lvm.lv=fedora/root rhgb quiet acpi_backlight=vendor
gdm-Xorg-:0[911]: Kernel command line: BOOT_IMAGE=/vmlinuz-3.14.3-200.fc20.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap vconsole.font=latarcyrheb-sun16 rd.lvm.lv=fedora/root rhgb quiet acpi_backlight=vendor
gnome-session[1020]: (gnome-settings-daemon:1079): power-plugin-CRITICAL **: gsd_power_backlight_abs_to_percentage: assertion 'max > min' failed
gnome-session[1562]: (gnome-settings-daemon:1621): power-plugin-CRITICAL **: gsd_power_backlight_abs_to_percentage: assertion 'max > min' failed

cat /sys/class/backlight/eeepc-wmi/max_brightness gives a 0 which lets me understand the two last errors above.

Athought this solution solves the symptom - visible backlight controll slider in gnome - it does not solve the problem in my opinion. There is still a backlight-controll detection under the hood. I can try to blacklist the eee-modules, what do you thing about it ?

Btw. thanks very much for helping me!

Comment 5 Hans de Goede 2014-05-14 12:57:18 UTC
Hi again,

I've just started a scratch build of a kernel which should fix this issue:
http://koji.fedoraproject.org/koji/taskinfo?taskID=6848721

Note it is still building atm. Once it is finished please install it with:
rpm -ivh kernel...rpm

And then boot into the new kernel without using any special kernel command line parameters, and let me know if that resolves the issue.

Regards,

Hans

Comment 6 karlitos 2014-05-14 15:57:21 UTC
So I installed the kernel

$ uname -r :
3.14.4-200.rhbz1097436.fc20.x86_64

And it seems to solved my problem. There is no backlight controll slider in gnome.

ls /sys/class/backlight/ outputs nothing.

And there are no errors/warnings in the log about backlight:

$ journalctl -b | grep backlight
kernel: Command line: BOOT_IMAGE=/vmlinuz-3.14.4-200.rhbz1097436.fc20.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap vconsole.font=latarcyrheb-sun16 rd.lvm.lv=fedora/root rhgb quiet acpi_backlight=vendor LANG=cs_CZ.utf8
kernel: Kernel command line: BOOT_IMAGE=/vmlinuz-3.14.4-200.rhbz1097436.fc20.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap vconsole.font=latarcyrheb-sun16 rd.lvm.lv=fedora/root rhgb quiet acpi_backlight=vendor LANG=cs_CZ.utf8
gdm-Xorg-:0[921]: Kernel command line: BOOT_IMAGE=/vmlinuz-3.14.4-200.rhbz1097436.fc20.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap vconsole.font=latarcyrheb-sun16 rd.lvm.lv=fedora/root rhgb quiet acpi_backlight=vendor LANG=cs_CZ.utf8

So now what ? Should I be using this kernel or can I expect some official update form the Fedora repos ?

Anyway, thank you again for your help1

Comment 7 Hans de Goede 2014-05-14 18:07:37 UTC
Hi,

(In reply to karlitos from comment #6)
> So now what ? Should I be using this kernel or can I expect some official
> update form the Fedora repos ?

For now if you want you can stick to this kernel, it is build the same way the official kernels are build, just with 2 extra patches for your motherboard thrown in.

Given the very minor nature of this bug I don't plan to add these patches to the official Fedora packages, as we always try to keep the amount of patches we carry minimal. I will however be sending the patches upstream, with a CC to the stable maintainers, so once the fix trickles down through upstream the Fedora kernels will have it too.

Regards,

Hans

Comment 8 Hans de Goede 2014-05-15 09:40:36 UTC
Patches send upstream, closing this.

Comment 9 Hans de Goede 2014-06-12 13:15:41 UTC
Hi,

Upstream has asked for some changes to the patches, can you please install and test this kernel (once it has finished building) and confirm that it still fixes your issue ? :

http://koji.fedoraproject.org/koji/taskinfo?taskID=7039560

Once I've confirmation that the new patches still fix things I'll send them upstream

Regards,

Hans

Comment 10 Hans de Goede 2014-06-12 13:16:30 UTC
Created attachment 908124 [details]
New patch 1/2

Comment 11 Hans de Goede 2014-06-12 13:17:03 UTC
Created attachment 908125 [details]
New patch 2/2

Comment 12 Hans de Goede 2014-06-16 07:40:23 UTC
ping?

I really need you to test the build from comment #9, so that I can send updated patches upstream to get this fixed upstream.

Thanks,

Hans

Comment 13 karlitos 2014-06-30 12:03:43 UTC
I am very sorry that I did not reply earlier. Somehow the bugzilla-notifications did not reach me. I will do my best, the computer which was suffering from this issue is not in my direct reach at this moment. I will try to install the patched kernel manually over ssh and will either guide my mother over the phone or get some remote desktop connection to the machine. I will begin this evening, there was noone around this machine for the last two weeks and I do not not the IP. Sorry once again for the delay ,I appreciate you work very much!

Comment 14 Hans de Goede 2014-06-30 12:22:39 UTC
(In reply to karlitos from comment #13)
> I am very sorry that I did not reply earlier. Somehow the
> bugzilla-notifications did not reach me.

No problem, thanks for the status update.

Note that scratch builds like the one from comment #9 don't stay around for ever. Currently the files still seem to be there, but to make sure I've put a copy of the necessary files here:

http://people.fedoraproject.org/~jwrdegoede/rhbz1097436/

Comment 15 karlitos 2014-07-06 21:48:22 UTC
Soooooooo ... I was finaly able to test your kernel build. I had to be at the computer in person, I use UEFI boot and had to disable the secureboot in the bios first.

I have no backlight controll in Gnome with the tested kernel and no special boot parameters.

"cat /sys/class/backlight/acpi_video0/max_brightness" outputs nothing

"journalctl -b | grep backlight" gives:

systemd[1]: Starting Load/Save Screen Backlight Brightness of backlight:acpi_video0...
systemd[1]: Started Load/Save Screen Backlight Brightness of backlight:acpi_video0.

"cat: /sys/class/backlight/acpi_video0/max_brightness:" gives: no such file or directory

Most important the backlight controll is gone and I was not able to find any backlight-related eroor messages in the logs.

I will however stay with the "acpi_backlight=vendor" workaround first and use the kernel shipped with fedora. Thank you very much for your help, I am looking forward to see the fix in one of the comming kernel versions.

Comment 16 Hans de Goede 2014-07-14 07:20:25 UTC
(In reply to karlitos from comment #15)
> Soooooooo ... I was finaly able to test your kernel build. I had to be at
> the computer in person, I use UEFI boot and had to disable the secureboot in
> the bios first.
> 
> I have no backlight controll in Gnome with the tested kernel and no special
> boot parameters.
> 
> "cat /sys/class/backlight/acpi_video0/max_brightness" outputs nothing

Thanks, I've send the new patches for this upstream, and the Fedora kernel also has a set of patches for this, so I'm closing this bug now.

Comment 17 Jason Tibbitts 2015-07-28 15:56:52 UTC
I hate to bump this old bug and I don't really want to reopen it and annoy people but all of my machines with Asus motherboards the eeepc_wmi and asus_wmi modules still load for me, and something tells systemd that there's a backlight it can control.  This causes systemd to complain and mark the system as "degraded".

This happens across pretty much all of my machines with Asus motherboards, although not 100% of the time.  In dmesg I see:

[    1.887257] asus_wmi: ASUS WMI generic driver loaded
[    1.888435] asus_wmi: Initialization: 0x0
[    1.888449] asus_wmi: BIOS WMI version: 0.9
[    1.888468] asus_wmi: SFUN value: 0x0
[    1.888650] input: Eee PC WMI hotkeys as /devices/platform/eeepc-wmi/input/input8
[    1.889059] asus_wmi: Disabling ACPI video driver

And /sys/class/backlight is empty when I look at.  However, I wonder if there's a race somewhere where something tells systemd that there's a backlight which later gets removed.

I've been seeing this for some time, but right now I'm seeing it on kernel-4.0.8-300.fc22.x86_64

The kernel shows:

DMI: ASUS All Series/H87I-PLUS, BIOS 2002 07/22/2014

though I also see this on:

DMI: ASUS All Series/H97I-PLUS, BIOS 2305 11/04/2014

and several other models as well, which I can dig up if it would help.

Comment 18 Hans de Goede 2015-07-29 11:53:22 UTC
Hi,

(In reply to Jason Tibbitts from comment #17)
> I hate to bump this old bug and I don't really want to reopen it and annoy
> people but all of my machines with Asus motherboards the eeepc_wmi and
> asus_wmi modules still load for me, and something tells systemd that there's
> a backlight it can control.  This causes systemd to complain and mark the
> system as "degraded".

Due the way how backlight detection in the kernel works + module load ordering it is possible that
there indeed as an acpi_video0 backlight interface on your system for a short time. But if /sys/class/backlight is empty after module leading, then things are working as expected from the kernel pov, and systemd should not complain.

Can you please open a new bug against systemd with me in the Cc to discuss this further?

Thanks & Regards,

Hans

Comment 19 Jason Tibbitts 2015-07-29 17:52:22 UTC
Thanks, I filed https://bugzilla.redhat.com/show_bug.cgi?id=1248152 and CC'd you.


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