Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Autosuspend incorrecty enabled for USB keyboards #340

Closed
foutrelis opened this issue Jun 23, 2015 · 8 comments
Closed

Autosuspend incorrecty enabled for USB keyboards #340

foutrelis opened this issue Jun 23, 2015 · 8 comments
Labels
bug 🐛 Programming errors, that need preferential fixing udev

Comments

@foutrelis
Copy link
Contributor

After moving systemd 221 to Arch's stable repos (previously provided systemd v219), we are seeing reports that USB keyboards do not behave as expected. This seems to be caused by a power management change in commit 64713f9.

So far, problems have been reported for the following keyboard models:

  • Ryos MK Pro: Backlight turing off after about 5 seconds of inactivity. [1]
  • Kinesis Advantage: Stops working after a few seconds. [2]
  • SteelSeries Apex: Turns off after a few seconds; needs 3-5 seconds to resume on key press. [3]

[1] https://bugs.archlinux.org/task/45427
[2] https://bbs.archlinux.org/viewtopic.php?id=198972
[3] https://bbs.archlinux.org/viewtopic.php?id=198999
@martinpitt
Copy link
Contributor

Thanks for digging this out! I thought my Kinesis keyboard got broken and ordered a new one, only to find out that the new one doesn't work as well. I'm not sure whether we should start collecting a blacklist of keyboards which don't work with USB autosuspend, or rather a whitelist? Or revert this wholesale?

@foutrelis
Copy link
Contributor Author

Perhaps @mjg59 can suggest what the proper course of action might be (as the author of commit 64713f9).

@wuxb45
Copy link

wuxb45 commented Jun 23, 2015

@foutrelis The problem of Kinesis keyboards is fixed after reverting the commit. Thanks.

@gregkh
Copy link
Contributor

gregkh commented Jun 24, 2015

We can not do autosuspend by default for keyboards, we have to have a whitelist. That's what another major operating system does because keyboards are broken in this aspect.

@kaysievers kaysievers mentioned this issue Jun 24, 2015
Merged
@kaysievers
Copy link
Contributor

Let's remove all the rules. They caused more problems than they ever solved. Things should be sorted out in the kernel, or if impossible, someone should start a project maintaining such a whitelist. It is not udev's job.

#353

@grossws
Copy link

grossws commented Jun 24, 2015

Have same problem on Kinesis Advantage and Das Keyboard Professional keyboards on ArchLinux after upgrading systemd parts from 219 to 221.

@kaysievers kaysievers added the bug 🐛 Programming errors, that need preferential fixing label Jun 26, 2015
@kaysievers
Copy link
Contributor

Merged: #353

@dillongreen
Copy link

My Logitech diNovo Edge stopped working as well, worked at bootup, then after 4 seconds of inactivity it stopped recognizing any keystrokes whatsoever, only swinging back from the dead after holding down a key for about 10 seconds and then spitting a few lines of that character on the screen... same again after a few seconds of inactivity...

After upgrading udev on my Debian box to 221-1 all is back to normal again. Debian bug report to be found here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789723

blueness pushed a commit to eudev-project/eudev that referenced this issue Jul 20, 2015
@kaysievers @blueness
rules: remove all power management from udev
b5ac92f 
It is not udev's task to apply any of these setting that way, or
from udev rules files. Things need to be sortet out in the kernel,
or explicit whitelist can possibly be added to the hardware database.
Until that is sorted out, and general agreement, udev is not
willing to maintain any such lists or power management settings
in general.

"Thanks for digging this out! I thought my Kinesis keyboard got broken
and ordered a new one, only to find out that the new one doesn't work
as well. I'm not sure whether we should start collecting a blacklist
of keyboards which don't work with USB autosuspend, or rather a
whitelist? Or revert this wholesale?"

  systemd/systemd#340

Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
anto pushed a commit to anto/eudev that referenced this issue Jul 23, 2015
@kaysievers @anto
rules: remove all power management from udev
cb77510 
It is not udev's task to apply any of these setting that way, or
from udev rules files. Things need to be sortet out in the kernel,
or explicit whitelist can possibly be added to the hardware database.
Until that is sorted out, and general agreement, udev is not
willing to maintain any such lists or power management settings
in general.

"Thanks for digging this out! I thought my Kinesis keyboard got broken
and ordered a new one, only to find out that the new one doesn't work
as well. I'm not sure whether we should start collecting a blacklist
of keyboards which don't work with USB autosuspend, or rather a
whitelist? Or revert this wholesale?"

  systemd/systemd#340

Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
vjrj pushed a commit to vjrj/tails that referenced this issue Jan 16, 2016
@intrigeri
laptop-mode-tools: don't control autosuspend.
f8fce9d 
Some USB input devices don't support autosuspend, see e.g.:
systemd/systemd#340

This change might help fix #10850, but even if it doesn't, it makes
sense to me that we don't let laptop-mode-tools fiddle with this
on a Live system.

Refs: #10850
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug 🐛 Programming errors, that need preferential fixing udev
Milestone
No milestone
Development

No branches or pull requests
8 participants
@gregkh @foutrelis @grossws @martinpitt @wuxb45 @dillongreen @kaysievers @poettering