Bug 1128309 - Tuning brightness makes my netbook unusable
Summary: Tuning brightness makes my netbook unusable
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 20
Hardware: i686
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-08 22:03 UTC by Massimiliano
Modified: 2014-10-16 12:40 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-10-16 12:40:06 UTC


Attachments (Terms of Use)
# dmesg > dmesg.log (53.83 KB, text/x-log)
2014-08-08 22:03 UTC, Massimiliano
no flags Details
# grep '.*' /sys/class/dmi/id/*_* 2> /dev/null > dmi.log (778 bytes, text/x-log)
2014-08-08 22:05 UTC, Massimiliano
no flags Details
$ cat /proc/bus/input/devices (2.64 KB, text/plain)
2014-08-30 21:54 UTC, Massimiliano
no flags Details

Description Massimiliano 2014-08-08 22:03:59 UTC
Created attachment 925308 [details]
# dmesg > dmesg.log

Description of problem:
An issue similar to bug 1012674. When I use my Fn keys to adjust brightness my netbook slows down till it becomes unusable: I have to switch a console and reboot. Brightness can be adjusted via software without problems.
Doesn't work:
 * video.use_native_backlight=1
 * Option "Backlight" "intel_backlight"

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

# uname -r
3.15.8-200.fc20.i686

Additional info:

# ls -l /sys/class/backlight
totale 0
lrwxrwxrwx 1 root root 0  9 ago  2014 acpi_video0 -> ../../devices/pci0000:00/0000:00:02.0/backlight/acpi_video0

Comment 1 Massimiliano 2014-08-08 22:05:48 UTC
Created attachment 925309 [details]
# grep '.*' /sys/class/dmi/id/*_* 2> /dev/null > dmi.log

Comment 2 Hans de Goede 2014-08-13 12:15:39 UTC
Thanks for the bug report.

You say your system becomes very slow. Have you tried running top to see if something is eating a lot of CPU when this happens ?

Note I'm with vacation next week, so I won't be answering any bugzilla comments then.

Comment 3 Massimiliano 2014-08-26 20:53:06 UTC
Well, top command reports nothing of strange. The most active processes are X (max 18%) and systemd-udevd (max 4%), but both often are less than 5%. It seems that slowness is not due to CPU overload, the cause is the poor response of input commands (like touchpad and especially keyboard). I need to restart X (eg logout-login) to get normal responsiveness.

Comment 4 Hans de Goede 2014-08-27 08:03:57 UTC
(In reply to Massimiliano from comment #3)
> Well, top command reports nothing of strange. The most active processes are
> X (max 18%) and systemd-udevd (max 4%), but both often are less than 5%. It
> seems that slowness is not due to CPU overload, the cause is the poor
> response of input commands (like touchpad and especially keyboard). I need
> to restart X (eg logout-login) to get normal responsiveness.

Hmm, this sounds like it is a userspace issue rather then a kernel issue then. Peter, any idea how to debug this input becoming lagged after a brightness key has been pressed once problem ?

Comment 5 Peter Hutterer 2014-08-28 06:44:28 UTC
Can you try to run evtest first to check that the events aren't somehow delayed in the kernel? If they show up without delay on evtest, then we've at least narrowed it down to X.

For the touchpad, this could be a clock issue, one that we're currently working on. I don't know why the keyboard is affected though, the evdev driver doesn't make use of timestamps, so it's all contained within the server.

Do you notice the delay gets worse or does it remain constant? if the latter, what is the approximate delay in seconds? I'm trying to rule out XKB accessibility activating, easy way to check is install xkbset, then run xkbset q | grep Slow-Keys.

Comment 6 Massimiliano 2014-08-30 21:52:52 UTC
(In reply to Peter Hutterer from comment #5)
> Can you try to run evtest first to check that the events aren't somehow
> delayed in the kernel? If they show up without delay on evtest, then we've
> at least narrowed it down to X.
>
I've never used evtest before. I've detected input devices (see attachment).
But if I try:

# evtest /dev/input/event5
Input driver version is 1.0.1
Input device ID: bus 0x11 vendor 0x2 product 0x7 version 0x1b1
Input device name: "SynPS/2 Synaptics TouchPad"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 272 (BTN_LEFT)
    Event code 273 (BTN_RIGHT)
    Event code 325 (BTN_TOOL_FINGER)
    Event code 330 (BTN_TOUCH)
    Event code 333 (BTN_TOOL_DOUBLETAP)
    Event code 334 (BTN_TOOL_TRIPLETAP)
  Event type 3 (EV_ABS)
    Event code 0 (ABS_X)
      Value   5023
      Min     1472
      Max     5888
      Resolution     121
    Event code 1 (ABS_Y)
      Value   4212
      Min     1408
      Max     5218
      Resolution     182
    Event code 24 (ABS_PRESSURE)
      Value      0
      Min        0
      Max      255
    Event code 28 (ABS_TOOL_WIDTH)
      Value      0
      Min        0
      Max       15
    Event code 47 (ABS_MT_SLOT)
      Value      0
      Min        0
      Max        1
    Event code 53 (ABS_MT_POSITION_X)
      Value      0
      Min     1472
      Max     5888
      Resolution     121
    Event code 54 (ABS_MT_POSITION_Y)
      Value      0
      Min     1408
      Max     5218
      Resolution     182
    Event code 57 (ABS_MT_TRACKING_ID)
      Value      0
      Min        0
      Max    65535
Properties:
  Property type 0 (INPUT_PROP_POINTER)
  Property type 3 (INPUT_PROP_SEMI_MT)
Testing ... (interrupt to exit)
***********************************************
  This device is grabbed by another process.
  No events are available to evtest while the
  other grab is active.
  In most cases, this is caused by an X driver,
  try VT-switching and re-run evtest again.
***********************************************

So I switch to a console (ctrl+alt+f2) to test touchpad after brightness tuning. Touchpad output doesn't seem to have a delay in console, but it remains slow under X.
Keybord ouptput for evtest is slower in X (after brightness tuning) than in console or in normal condition under X.
 
> For the touchpad, this could be a clock issue, one that we're currently
> working on. I don't know why the keyboard is affected though, the evdev
> driver doesn't make use of timestamps, so it's all contained within the
> server.
> 
> Do you notice the delay gets worse or does it remain constant? if the
> latter, what is the approximate delay in seconds? I'm trying to rule out XKB
> accessibility activating, easy way to check is install xkbset, then run
> xkbset q | grep Slow-Keys.

The delay (slowness) after tuning brightness is constant. But I notice that after a while (especially if I switch from console to X many times), then X comes back to work again. The more I press Fn-keys, the more the system becomes slow (and for a longer time).

$ xkbset q | grep Slow-Keys
Slow-Keys = Off

Comment 7 Massimiliano 2014-08-30 21:54:42 UTC
Created attachment 933024 [details]
$ cat /proc/bus/input/devices

Comment 8 Massimiliano 2014-08-31 15:42:59 UTC
Following this: https://bbs.archlinux.org/viewtopic.php?id=178014
I've tried "acpi_osi=" (empty string) as kernel parameter. Now OSD brightness indicator appears after a bit delay (2 secs) and during this time the netbook is still sluggish. But after this interval everything works as expected. It seems a good workaround.

# cat /proc/cmdline 
BOOT_IMAGE=/boot/vmlinuz-3.15.10-201.fc20.i686 root=UUID=37b8d37e-43ff-4795-9d2f-fa88e02715da ro rd.md=0 rd.dm=0 rd.luks=0 rhgb quiet acpi_osi=

Comment 9 Hans de Goede 2014-09-01 15:49:17 UTC
(In reply to Massimiliano from comment #8)
> Following this: https://bbs.archlinux.org/viewtopic.php?id=178014
> I've tried "acpi_osi=" (empty string) as kernel parameter. Now OSD
> brightness indicator appears after a bit delay (2 secs) and during this time
> the netbook is still sluggish. But after this interval everything works as
> expected. It seems a good workaround.
> 
> # cat /proc/cmdline 
> BOOT_IMAGE=/boot/vmlinuz-3.15.10-201.fc20.i686
> root=UUID=37b8d37e-43ff-4795-9d2f-fa88e02715da ro rd.md=0 rd.dm=0 rd.luks=0
> rhgb quiet acpi_osi=

Ok, see this seems to be a kernel problem.

What does "ls /sys/class/backlight" say when you boot with  "acpi_osi=" ?

Can you try with "acpi_backlight=vendor" (and no other special options) on the kernel commandline ?

Comment 10 Massimiliano 2014-09-01 20:56:18 UTC
(In reply to Hans de Goede from comment #9)
> 
> Ok, see this seems to be a kernel problem.
> 
> What does "ls /sys/class/backlight" say when you boot with  "acpi_osi=" ?
>

# ls -l /sys/class/backlight
totale 0
lrwxrwxrwx 1 root root 0  2 set  2014 acpi_video0 -> ../../devices/pci0000:00/0000:00:02.0/backlight/acpi_video0
 
> Can you try with "acpi_backlight=vendor" (and no other special options) on
> the kernel commandline ?

No sluggish anymore with this option:

# cat /proc/cmdline 
BOOT_IMAGE=/boot/vmlinuz-3.15.10-201.fc20.i686 root=UUID=37b8d37e-43ff-4795-9d2f-fa88e02715da ro rd.md=0 rd.dm=0 rd.luks=0 rhgb quiet acpi_backlight=vendor

# ls -l /sys/class/backlight
totale 0
lrwxrwxrwx 1 root root 0  1 set 22.20 acer-wmi -> ../../devices/platform/acer-wmi/backlight/acer-wmi

But OSD display often doesn't appear (delay has been increased). But shouldn't we use option video.use_native_backlight=1 instead?

Comment 11 Hans de Goede 2014-09-02 07:03:02 UTC
Thanks for the testing. Recently there has been a lot of work done to make interaction with the acpi ec controller work more smooth, including some work specifically to work around bugs on some model acer laptops:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/acpi?id=3afcf2ece453e1a8c2c6de19cdf06da3772a1b08
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/acpi?id=558e4736f2e1b0e6323adf7a5e4df77ed6cfc1a4

These commits are part of 3.17-rc3, can you please try installing this kernel build:
http://koji.fedoraproject.org/koji/buildinfo?buildID=574277

Download kernel-3.17... kernel-core-... and kernel-modules-... for your architecture (if you've done a 32 bit install use the PAE versions) and then install them like this:

rpm -ivh kernel*.rpm

Then reboot into the new kernel without any special commandline options and see if that changes anything (e.g. fixes the slow down). If that does not fix thinhgs 100% try the same kernel with "acpi_backlight=vendor".

(In reply to Massimiliano from comment #10)
> But shouldn't we use option video.use_native_backlight=1 instead?

That is for new laptops with a win8 ready BIOS it does not do anything on older laptops.

Regards,

Hans

Comment 12 Massimiliano 2014-09-02 20:07:07 UTC
(In reply to Hans de Goede from comment #11)
> Download kernel-3.17... kernel-core-... and kernel-modules-... for your
> architecture (if you've done a 32 bit install use the PAE versions) and then
> install them like this:
> 
> rpm -ivh kernel*.rpm
> 
> Then reboot into the new kernel without any special commandline options and
> see if that changes anything (e.g. fixes the slow down). If that does not
> fix thinhgs 100% try the same kernel with "acpi_backlight=vendor".
> 

No good:

# cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-3.17.0-0.rc3.git0.1.fc22.i686 root=UUID=37b8d37e-43ff-4795-9d2f-fa88e02715da ro rd.md=0 rd.dm=0 rd.luks=0 rhgb quiet

# ls -l /sys/class/backlight
totale 0
lrwxrwxrwx 1 root root 0  2 set 21.42 acpi_video0 -> ../../devices/pci0000:00/0000:00:02.0/backlight/acpi_video0

Better:

# cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-3.17.0-0.rc3.git0.1.fc22.i686 root=UUID=37b8d37e-43ff-4795-9d2f-fa88e02715da ro rd.md=0 rd.dm=0 rd.luks=0 rhgb quiet acpi_backlight=vendor

# ls -l /sys/class/backlight
totale 0
lrwxrwxrwx 1 root root 0  2 set 21.46 acer-wmi -> ../../devices/platform/acer-wmi/backlight/acer-wmi

I notice no difference between the two kernel (3.15 and 3.17).

Comment 13 Hans de Goede 2014-09-14 20:54:28 UTC
Hi Massimiliano,

Thanks for testing, can you try adding: "acpi_osi=Linux" the kernel command line and see if that helps ? 

Can you please try this by it self, as well as combined with "acpi_backlight=vendor" ?

Thanks,

Hans

Comment 14 Massimiliano 2014-09-15 20:39:14 UTC
(In reply to Hans de Goede from comment #13)
> Hi Massimiliano,
> 
> Thanks for testing, can you try adding: "acpi_osi=Linux" the kernel command
> line and see if that helps ? 
> 
> Can you please try this by it self, as well as combined with
> "acpi_backlight=vendor" ?
> 

Very slow with this option:

# cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-3.17.0-0.rc3.git0.1.fc22.i686 root=UUID=37b8d37e-43ff-4795-9d2f-fa88e02715da ro rd.md=0 rd.dm=0 rd.luks=0 rhgb quiet acpi_osi=Linux

# ls -l /sys/class/backlight
totale 0
lrwxrwxrwx 1 root root 0 16 set  2014 acpi_video0 -> ../../devices/pci0000:00/0000:00:02.0/backlight/acpi_video0

Not slow, but again OSD display often doesn't appear (tipically only at 100%):

# cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-3.17.0-0.rc3.git0.1.fc22.i686 root=UUID=37b8d37e-43ff-4795-9d2f-fa88e02715da ro rd.md=0 rd.dm=0 rd.luks=0 rhgb quiet acpi_osi=Linux acpi_backlight=vendor

# ls -l /sys/class/backlight
totale 0
lrwxrwxrwx 1 root root 0 15 set 22.24 acer-wmi -> ../../devices/platform/acer-wmi/backlight/acer-wmi

Comment 15 Hans de Goede 2014-09-18 12:09:31 UTC
Hi,

Can you try to see where the keypress events for the osd are coming from when using acpi_backlight=vendor ?

Do: "sudo yum install evemu", switch to a text console (ctrl + alt + f2) and then run "sudo evemu-record", select an input device and see if that is generathing keypress events for the brightness keys. Likely suspects for this are the "video bus" input device, and something with "acer" in the name.

It would be also good to know where the events are coming from when not using acpi_backlight=vendor,
and last, but not least, I would also like you to check if when the osd is slow, the events are also slow.

Thanks,

Hans

Comment 16 Massimiliano 2014-09-24 21:47:22 UTC
(In reply to Hans de Goede from comment #15)
> Hi,
> 
> Can you try to see where the keypress events for the osd are coming from
> when using acpi_backlight=vendor ?
> 
> Do: "sudo yum install evemu", switch to a text console (ctrl + alt + f2) and
> then run "sudo evemu-record", select an input device and see if that is
> generathing keypress events for the brightness keys. Likely suspects for
> this are the "video bus" input device, and something with "acer" in the name.
> 
# cat /proc/cmdline 
BOOT_IMAGE=/boot/vmlinuz-3.17.0-0.rc3.git0.1.fc22.i686 root=UUID=37b8d37e-43ff-4795-9d2f-fa88e02715da ro rd.md=0 rd.dm=0 rd.luks=0 rhgb quiet acpi_backlight=vendor

# evemu-record 
Available devices:
/dev/input/event0:      Power Button
/dev/input/event1:      Lid Switch
/dev/input/event2:      Sleep Button
/dev/input/event3:      Power Button
/dev/input/event4:      AT Translated Set 2 keyboard
/dev/input/event5:      Video Bus
/dev/input/event6:      SynPS/2 Synaptics TouchPad
/dev/input/event8:      Webcam
/dev/input/event9:      HDA Intel Mic
/dev/input/event10:     HDA Intel Headphone
Select the device event number [0-10]:

I obtain response only from 4 and 5. In case of 5:

################################
#      Waiting for events      #
################################
E: 0.000000 0001 00e0 0001      # EV_KEY / KEY_BRIGHTNESSDOWN   1
E: 0.000000 0000 0000 0000      # ------------ SYN_REPORT (0) ----------
E: 0.000086 0001 00e0 0000      # EV_KEY / KEY_BRIGHTNESSDOWN   0
E: 0.000086 0000 0000 0000      # ------------ SYN_REPORT (0) ----------
E: 0.400177 0001 00e0 0001      # EV_KEY / KEY_BRIGHTNESSDOWN   1
E: 0.400177 0000 0000 0000      # ------------ SYN_REPORT (0) ----------
E: 0.400290 0001 00e0 0000      # EV_KEY / KEY_BRIGHTNESSDOWN   0
E: 0.400290 0000 0000 0000      # ------------ SYN_REPORT (0) ----------
E: 2.125801 0001 00e1 0001      # EV_KEY / KEY_BRIGHTNESSUP     1
E: 2.125801 0000 0000 0000      # ------------ SYN_REPORT (0) ----------
E: 2.125860 0001 00e1 0000      # EV_KEY / KEY_BRIGHTNESSUP     0
E: 2.125860 0000 0000 0000      # ------------ SYN_REPORT (0) ----------
E: 2.485866 0001 00e1 0001      # EV_KEY / KEY_BRIGHTNESSUP     1
E: 2.485866 0000 0000 0000      # ------------ SYN_REPORT (0) ----------
E: 2.485927 0001 00e1 0000      # EV_KEY / KEY_BRIGHTNESSUP     0
E: 2.485927 0000 0000 0000      # ------------ SYN_REPORT (0) ----------
E: 2.876339 0001 00e1 0001      # EV_KEY / KEY_BRIGHTNESSUP     1
E: 2.876339 0000 0000 0000      # ------------ SYN_REPORT (0) ----------
E: 2.876421 0001 00e1 0000      # EV_KEY / KEY_BRIGHTNESSUP     0
E: 2.876421 0000 0000 0000      # ------------ SYN_REPORT (0) ----------

OSD appears late (tipically at 100%), but the brightness changes and the output is printed regularly.

> It would be also good to know where the events are coming from when not
> using acpi_backlight=vendor,
> and last, but not least, I would also like you to check if when the osd is
> slow, the events are also slow.
>
# cat /proc/cmdline 
BOOT_IMAGE=/boot/vmlinuz-3.17.0-0.rc3.git0.1.fc22.i686 root=UUID=37b8d37e-43ff-4795-9d2f-fa88e02715da ro rd.md=0 rd.dm=0 rd.luks=0 rhgb quiet

# evemu-record 
Available devices:
/dev/input/event0:      Power Button
/dev/input/event1:      Lid Switch
/dev/input/event2:      Sleep Button
/dev/input/event3:      Power Button
/dev/input/event4:      AT Translated Set 2 keyboard
/dev/input/event5:      SynPS/2 Synaptics TouchPad
/dev/input/event6:      Video Bus
/dev/input/event7:      Webcam
/dev/input/event9:      HDA Intel Mic
/dev/input/event10:     HDA Intel Headphone
Select the device event number [0-10]:

I obtain response only from 4 and 6. The output is printed, but the response is slow and the system slows down globally.
It seems there is a bottleneck in event dispatching.

Regards
Massimiliano

Comment 17 Hans de Goede 2014-10-01 12:07:30 UTC
Hi Massimiliano,

So it seems that the best we can do for your system is to add a quirk so that the kernel will automatically behave as if "acpi_backlight=vendor" is passed to the kernel.

Then there still (sometimes) is the delay after pressing the brightness keys, but atleast the slowdown of the entire system goes away, right?

Please let me know if you agree that this is the best way forward, then I'll write a patch for this, and give you a kernel to test.

Regards,

Hans

Comment 18 Massimiliano 2014-10-03 20:36:13 UTC
(In reply to Hans de Goede from comment #17)
> Hi Massimiliano,
> 
> So it seems that the best we can do for your system is to add a quirk so
> that the kernel will automatically behave as if "acpi_backlight=vendor" is
> passed to the kernel.
> 
Yes, this is the best behavior that I've obtained till now.

> Then there still (sometimes) is the delay after pressing the brightness
> keys, but atleast the slowdown of the entire system goes away, right?
> 
Yes.

> Please let me know if you agree that this is the best way forward, then I'll
> write a patch for this, and give you a kernel to test.
> 
OK

Thanks,

Massimiliano

Comment 19 Hans de Goede 2014-10-11 13:38:02 UTC
Hi,

I've started a scratchbuild with a kernel with a quirk for your model, you can find this scratch build here:

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

Note this is still building atm.

The added quirk tell the kernel to always behave as if acpi_backlight=vendor is specified on the kernel commandline.
ace on your machine.

Can you please download the kernel-3.16.5-....x86_64.rpm file, and then install it with:
sudo rpm -ivh kernel-3.16.5-....x86_64.rpm

And boot into it without specifying any special kernel commandline parameters.

After booting this kernel please do:

ls /sys/class/backlight

It should now only list acer-wmi, just like when booting unpatched kernels with acpi_backlight=vendor.

Please let me know if this scratch build works, then I'll send the patch upstream.

Thanks,

Hans

Comment 20 Hans de Goede 2014-10-12 10:37:04 UTC
Ugh, that scratchbuild has failed because the release field was too long, here is a new build I've just started:

https://koji.fedoraproject.org/koji/taskinfo?taskID=7839906

Please follow the previous testing instructions using this build (once it has finished building).

Comment 21 Massimiliano 2014-10-13 21:03:14 UTC
(In reply to Hans de Goede from comment #19)
> 
> Can you please download the kernel-3.16.5-....x86_64.rpm file, and then
> install it with:
> sudo rpm -ivh kernel-3.16.5-....x86_64.rpm
>
No, I can't. This bug is for i686 platform.  ;-)
 
> And boot into it without specifying any special kernel commandline
> parameters.
> 
# cat /proc/cmdline 
BOOT_IMAGE=/boot/vmlinuz-3.16.5-200.rhbz1123661.fc20.i686 root=UUID=37b8d37e-43ff-4795-9d2f-fa88e02715da ro rd.md=0 rd.dm=0 rd.luks=0 rhgb quiet

> After booting this kernel please do:
> 
> ls /sys/class/backlight
>
# ls -l /sys/class/backlight
totale 0
lrwxrwxrwx 1 root root 0 13 ott 22.40 acer-wmi -> ../../devices/platform/acer-wmi/backlight/acer-wmi

> It should now only list acer-wmi, just like when booting unpatched kernels
> with acpi_backlight=vendor.
>
Yes.
 
> Please let me know if this scratch build works, then I'll send the patch
> upstream.
>
It works. Thank you.

Massimiliano

Comment 22 Hans de Goede 2014-10-16 12:40:06 UTC
(In reply to Massimiliano from comment #21)
> > Please let me know if this scratch build works, then I'll send the patch
> > upstream.
> >
> It works. Thank you.

That is good to hear, I've send the patch upstream and it should show up in one of the 3.16.x stable patches eventually. In the mean time please keep using acpi_backlight=vendor on the kernel commandline,

Regards,

Hans


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