Re: [systemd-devel] Udev rules hardware database
IIRC there used to be a kernel bug that caused autosuspend to mostly not work on Linux, which they however blamed on crappy devices for a long time. After that kernel bug got fixed I think autosuspend works on most devices now, hence we only need a blacklist? I figure Greg has all the details on this, let's ask him (added to CC): Greg, say something! Is the autosuspend stuff something we can enable safely on most devices now? Do we need a blacklist? Or should we even go for a whitelist? I really don't know. Some other operating system relies on a whitelist due to all of the horrible devices out there that can't handle suspend (keyboards and mice are notorious for being bad.) Thanks for your input. Do you know in which kernel version the above mentioned bug got fixed? I just checked two mice, a keyboard and a bunch of internal devices with a 3.17 kernel. Only one of the mice works completely reliable with activated power saving as input device – no problems with the internal devices. The funny thing is: That mouse is built from the same company as some other operating system – dog feeding does make sense. You might want to ask one of the distro people to see if they have ever turned it on by default and what happened if they tried that. Unfortunately, I do not know anyone from a distribution who is in charge for that area. Do you? A short Google search didn't bring up any distribution which did that, but my search was probably incomplete. But if my results mentioned above should be remotely representative, that might be disastrous, because for an average user it might be close to impossible to deactivate power savings without working input devices. Kind regards Patrick signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Udev rules hardware database
On Sun, 2014-11-09 at 22:39 +0100, Patrick Häcker wrote: I really don't know. Some other operating system relies on a whitelist due to all of the horrible devices out there that can't handle suspend (keyboards and mice are notorious for being bad.) Thanks for your input. Do you know in which kernel version the above mentioned bug got fixed? I just checked two mice, a keyboard and a bunch of internal devices with a 3.17 kernel. Only one of the mice works completely reliable with activated power saving as input device – no problems with the internal devices. The funny thing is: That mouse is built from the same company as some other operating system – dog feeding does make sense. The problem with mice is the usual inability to trigger a remote wakeup when the mouse is moved. They only do a remote wakeup when a button is pressed. (The behavior is within spec. The USB HID spec is deficient.) I took two lessons from that 1. It makes no sense to use the same approach for all USB devices. Some classes need a blacklist others do need a whitelist. 2. The kernel is not really the ideal place to decide when to activate power management. Most mice are built for an operating model which has more grades then Linux usually uses. We see our system either as fully operational or suspended. Those mice are built for reducing power consumption when a system becomes unused and the screen is blanked or the screensaver comes up. You might want to ask one of the distro people to see if they have ever turned it on by default and what happened if they tried that. Unfortunately, I do not know anyone from a distribution who is in charge for that area. Do you? A short Google search didn't bring up any distribution which did that, but my search was probably incomplete. Unlikely. You end up with systems that are practically unusable in the worst and commonest case. But if my results mentioned above should be remotely representative, that might be disastrous, because for an average user it might be close to impossible to deactivate power savings without working input devices. Exactly. Regards Oliver ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Udev rules hardware database
On Fri, 2014-11-07 at 08:26 +0100, Martin Pitt wrote:
Patrick Häcker [2014-11-05 16:55 +0100]:
I you want to have permanent power saving activated for your devices, the
recommended way is to use udev (e.g.
https://wiki.archlinux.org/index.php/Power_saving#USB_autosuspend). Some
[...]
- Is there already something like this?
By coincidence I recently noticed something interesting in sysfs: My
USB devices seem to have an attribute supports_autosuspend. These
They are from the kernel and tell you that the drivers for the devices
support autosuspend. It says nothing about the device itself.
are all 1 except for my USB webcam [1] where it is 0. This sounds very
promising indeed! So apparently the kernel now already grew either a
heuristics or some black/whitelists?
Nothing of this sort. It is a pure driver thing and only the negative
is to be taken at face value.
At least the current state how Linux (3.16.0) and udev (215) configure
autosuspend seems a bit weird:
- Some of my USB devices have power/autosuspend == 2: internal
laptop webcam, USB webcam ([1] again), USB Keyboard, USB mouse.
2 is the kernel's default for the general case.
All others have 0. There is no udev rule or other thing on my
system to set those, so unless it's udev or systemd itself I guess
it's from the kernel.
Drivers in the kernel can change it with
pm_runtime_set_autosuspend_delay()
- Most of my USB devices have power/level==auto (i. e. suspend
enabled), only some of them are on (i. e. suspend disabled).
Curiously those which are on are three of above devices where
autosuspend==2: USB webcam, USB Keyboard, USB mouse.
Again drivers can enable it with usb_enable_autosuspend()
This can not be done for HID devices, because for most mice
remote wakeup isn't usable in the generic case.
- The only udev rule which I'm aware of that does autosuspend is
42-usb-hid-pm.rules:
ACTION==add, SUBSYSTEM==usb, ATTR{bInterfaceClass}==03,
ATTRS{removable}==fixed, TEST==../power/control,
ATTR{../power/control}=auto
So it does not seem to be the case that we don't currently enable
autosuspend at all, but it's currently highly inconsistant and
confusing.
It is inconsistent. That is at least partially to the inability to find
general rules.
Regards
Oliver
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Udev rules hardware database
On Fri, 07.11.14 09:23, Oliver Neukum (oneu...@suse.de) wrote:
By coincidence I recently noticed something interesting in sysfs: My
USB devices seem to have an attribute supports_autosuspend. These
They are from the kernel and tell you that the drivers for the devices
support autosuspend. It says nothing about the device itself.
are all 1 except for my USB webcam [1] where it is 0. This sounds very
promising indeed! So apparently the kernel now already grew either a
heuristics or some black/whitelists?
Nothing of this sort. It is a pure driver thing and only the negative
is to be taken at face value.
At least the current state how Linux (3.16.0) and udev (215) configure
autosuspend seems a bit weird:
- Some of my USB devices have power/autosuspend == 2: internal
laptop webcam, USB webcam ([1] again), USB Keyboard, USB mouse.
2 is the kernel's default for the general case.
All others have 0. There is no udev rule or other thing on my
system to set those, so unless it's udev or systemd itself I guess
it's from the kernel.
Drivers in the kernel can change it with
pm_runtime_set_autosuspend_delay()
- Most of my USB devices have power/level==auto (i. e. suspend
enabled), only some of them are on (i. e. suspend disabled).
Curiously those which are on are three of above devices where
autosuspend==2: USB webcam, USB Keyboard, USB mouse.
Again drivers can enable it with usb_enable_autosuspend()
This can not be done for HID devices, because for most mice
remote wakeup isn't usable in the generic case.
- The only udev rule which I'm aware of that does autosuspend is
42-usb-hid-pm.rules:
ACTION==add, SUBSYSTEM==usb, ATTR{bInterfaceClass}==03,
ATTRS{removable}==fixed, TEST==../power/control,
ATTR{../power/control}=auto
So it does not seem to be the case that we don't currently enable
autosuspend at all, but it's currently highly inconsistant and
confusing.
It is inconsistent. That is at least partially to the inability to find
general rules.
So what would you recommend we do?
Experiment with turning auto-suspend on by default and then start
building a blacklist if we get reports that things stop working?
And that blacklist should that live in hwdb in userspace or be
maintained as quirks list in the kernel, compiled in?
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Udev rules hardware database
On Fri, 2014-11-07 at 12:55 +0100, Lennart Poettering wrote: On Fri, 07.11.14 09:23, Oliver Neukum (oneu...@suse.de) wrote: It is inconsistent. That is at least partially to the inability to find general rules. So what would you recommend we do? Experiment with turning auto-suspend on by default and then start building a blacklist if we get reports that things stop working? No. I suggest giving administrators (users) a really easy way to enable autosuspend and gather the results. That isn't good. We've tried for years to come up with something better. And that blacklist should that live in hwdb in userspace or be maintained as quirks list in the kernel, compiled in? user space Regards Oliver ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Udev rules hardware database
On Fri, 07.11.14 13:07, Oliver Neukum (oneu...@suse.de) wrote: On Fri, 2014-11-07 at 12:55 +0100, Lennart Poettering wrote: On Fri, 07.11.14 09:23, Oliver Neukum (oneu...@suse.de) wrote: It is inconsistent. That is at least partially to the inability to find general rules. So what would you recommend we do? Experiment with turning auto-suspend on by default and then start building a blacklist if we get reports that things stop working? No. I suggest giving administrators (users) a really easy way to enable autosuspend and gather the results. That isn't good. We've tried for years to come up with something better. Well, opt-in for this will never work to get a good dataset. I figure if we want this to really happen, then we should turn on autosuspend globally early in the cycle of fedora rawhide, and then collect as much data as we can during testing, and then turn if off before the release if it happens to be too bad. I figure doing this would require some buy-in from FESCO first though. Given the bureaucracy for that this would need a champion though who's willing to do that work. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Udev rules hardware database
On Wed, 05.11.14 16:55, Patrick Häcker (pa...@web.de) wrote: heya, sorry if this list is not the correct one for my post. In this case please just point me to the correct list. It is the correct list. I you want to have permanent power saving activated for your devices, the recommended way is to use udev (e.g. https://wiki.archlinux.org/index.php/Power_saving#USB_autosuspend). Some devices do not work with active power saving, which is the reason why it's not activated by default. To get it working anyway, users should activated it for all devices and create their own blacklists. I did exactly that and had to copy blacklists to multiple computers when moving my devices around. As this should be distribution agnostic, I wonder if there are upstream blacklists or whitelists to take care of this problem. A power save whitelist would be useful, as distributions could start activating power saving for theses devices immediately. A power save blacklist would be useful as users could try to activate power saving for all devices and if their problematic hardware is already on the blacklist, everything works and they can save even more power as with the whitelist. In the long run there could even be a small please test your hardware tool, where the power saving is activated for, e.g., your mouse. You then have to click to confirm that it is working. Otherwise power saving gets deactivated after a timeout, so you can use your mouse again. This result could then be automatically uploaded (after user confirmation) and added to the blacklist/whitelist. So I have several questions: - Is there already something like this? No there's nothing like that to my knowledge. - If not, is udev the correct piece in the Linux stack to put this? Yes, and the hwdb has been created for things likt this. - What is the general way to contribute udev rules? The matching bits really belong in hwdb. The matching should then set a property and a udev rule should then update the hw device. - Where is it documented? it's tersely documented in the udev man page. systemd already ships some hwdb bits (such as the PCI/USB name databases), and we should add more to this. IIUC we probably can implement this as a blacklist, rather than a whitelist. IIRC there used to be a kernel bug that caused autosuspend to mostly not work on Linux, which they however blamed on crappy devices for a long time. After that kernel bug got fixed I think autosuspend works on most devices now, hence we only need a blacklist? I figure Greg has all the details on this, let's ask him (added to CC): Greg, say something! Is the autosuspend stuff something we can enable safely on most devices now? Do we need a blacklist? Or should we even go for a whitelist? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Udev rules hardware database
On Thu, Nov 06, 2014 at 07:49:38PM +0100, Lennart Poettering wrote: On Wed, 05.11.14 16:55, Patrick Häcker (pa...@web.de) wrote: heya, sorry if this list is not the correct one for my post. In this case please just point me to the correct list. It is the correct list. I you want to have permanent power saving activated for your devices, the recommended way is to use udev (e.g. https://wiki.archlinux.org/index.php/Power_saving#USB_autosuspend). Some devices do not work with active power saving, which is the reason why it's not activated by default. To get it working anyway, users should activated it for all devices and create their own blacklists. I did exactly that and had to copy blacklists to multiple computers when moving my devices around. As this should be distribution agnostic, I wonder if there are upstream blacklists or whitelists to take care of this problem. A power save whitelist would be useful, as distributions could start activating power saving for theses devices immediately. A power save blacklist would be useful as users could try to activate power saving for all devices and if their problematic hardware is already on the blacklist, everything works and they can save even more power as with the whitelist. In the long run there could even be a small please test your hardware tool, where the power saving is activated for, e.g., your mouse. You then have to click to confirm that it is working. Otherwise power saving gets deactivated after a timeout, so you can use your mouse again. This result could then be automatically uploaded (after user confirmation) and added to the blacklist/whitelist. So I have several questions: - Is there already something like this? No there's nothing like that to my knowledge. - If not, is udev the correct piece in the Linux stack to put this? Yes, and the hwdb has been created for things likt this. - What is the general way to contribute udev rules? The matching bits really belong in hwdb. The matching should then set a property and a udev rule should then update the hw device. - Where is it documented? it's tersely documented in the udev man page. systemd already ships some hwdb bits (such as the PCI/USB name databases), and we should add more to this. IIUC we probably can implement this as a blacklist, rather than a whitelist. IIRC there used to be a kernel bug that caused autosuspend to mostly not work on Linux, which they however blamed on crappy devices for a long time. After that kernel bug got fixed I think autosuspend works on most devices now, hence we only need a blacklist? I figure Greg has all the details on this, let's ask him (added to CC): Greg, say something! Is the autosuspend stuff something we can enable safely on most devices now? Do we need a blacklist? Or should we even go for a whitelist? I really don't know. Some other operating system relies on a whitelist due to all of the horrible devices out there that can't handle suspend (keyboards and mice are notorious for being bad.) You might want to ask one of the distro people to see if they have ever turned it on by default and what happened if they tried that. thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Udev rules hardware database
Patrick Häcker [2014-11-05 16:55 +0100]:
I you want to have permanent power saving activated for your devices, the
recommended way is to use udev (e.g.
https://wiki.archlinux.org/index.php/Power_saving#USB_autosuspend). Some
[...]
- Is there already something like this?
By coincidence I recently noticed something interesting in sysfs: My
USB devices seem to have an attribute supports_autosuspend. These
are all 1 except for my USB webcam [1] where it is 0. This sounds very
promising indeed! So apparently the kernel now already grew either a
heuristics or some black/whitelists?
At least the current state how Linux (3.16.0) and udev (215) configure
autosuspend seems a bit weird:
- Some of my USB devices have power/autosuspend == 2: internal
laptop webcam, USB webcam ([1] again), USB Keyboard, USB mouse.
All others have 0. There is no udev rule or other thing on my
system to set those, so unless it's udev or systemd itself I guess
it's from the kernel.
- Most of my USB devices have power/level==auto (i. e. suspend
enabled), only some of them are on (i. e. suspend disabled).
Curiously those which are on are three of above devices where
autosuspend==2: USB webcam, USB Keyboard, USB mouse.
- The only udev rule which I'm aware of that does autosuspend is
42-usb-hid-pm.rules:
ACTION==add, SUBSYSTEM==usb, ATTR{bInterfaceClass}==03,
ATTRS{removable}==fixed, TEST==../power/control,
ATTR{../power/control}=auto
So it does not seem to be the case that we don't currently enable
autosuspend at all, but it's currently highly inconsistant and
confusing.
Martin
[1]
E: ID_MODEL=08af
E: ID_MODEL_FROM_DATABASE=QuickCam Easy/Cool
E: ID_VENDOR=046d
E: ID_VENDOR_FROM_DATABASE=Logitech, Inc.
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
signature.asc
Description: Digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Udev rules hardware database
Dear all, sorry if this list is not the correct one for my post. In this case please just point me to the correct list. I you want to have permanent power saving activated for your devices, the recommended way is to use udev (e.g. https://wiki.archlinux.org/index.php/Power_saving#USB_autosuspend). Some devices do not work with active power saving, which is the reason why it's not activated by default. To get it working anyway, users should activated it for all devices and create their own blacklists. I did exactly that and had to copy blacklists to multiple computers when moving my devices around. As this should be distribution agnostic, I wonder if there are upstream blacklists or whitelists to take care of this problem. A power save whitelist would be useful, as distributions could start activating power saving for theses devices immediately. A power save blacklist would be useful as users could try to activate power saving for all devices and if their problematic hardware is already on the blacklist, everything works and they can save even more power as with the whitelist. In the long run there could even be a small please test your hardware tool, where the power saving is activated for, e.g., your mouse. You then have to click to confirm that it is working. Otherwise power saving gets deactivated after a timeout, so you can use your mouse again. This result could then be automatically uploaded (after user confirmation) and added to the blacklist/whitelist. So I have several questions: - Is there already something like this? - If not, is udev the correct piece in the Linux stack to put this? - What is the general way to contribute udev rules? - Where is it documented? Kind regards Patrick signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Udev rules hardware database
On Wed, Nov 05, 2014 at 04:55:52PM +0100, Patrick Häcker wrote: - If not, is udev the correct piece in the Linux stack to put this? Most likely the kernel should do this by itself. What where the devices that you had to disable power saving on? - What is the general way to contribute udev rules? Send patches to this mailing list. - Where is it documented? Good question. A patch which documents this might not be a bad idea. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
