Am Freitag, 31. Oktober 2008 00:17:38 schrieb Jiri Kosina: > On Thu, 30 Oct 2008, Oliver Neukum wrote: > > > I am looking at runtime power management for usb hid devices. There's a > > problem with hidraw. As we have no idea, what goes on between a device > > and users of hidraw, it seems to me that such a device should not be > > subject to runtime power management without the user's explicit > > agreement. But that would be only a kludge. Therefore this is my first > > draft of an API to cleanly allow this. > > Hi Oliver, > > isn't this just a little bit way too complex? That depends on the eventual goal. If hidraw were the only problem, I could find a simpler solution. > I think the simple and working solution would be never suspedning devices > that have interface open through hidraw, unless user explicitly allows > this through respective power/autosuspend setting in sysfs (which will by > default be set to 'off' for HID devices anyway, right?). That we already have. That's the simple copout. Do not enable autosuspend if you allow hidraw for a device. However, if normal users shall be able to use the hidraw device that means that autosuspend can never be enabled for the device, as we don't know when someone will use the device. For hiddev we can do better, the device is not autosuspended while it is open. This allows allowing ordinary users to use the device. Doing so for hidraw would require to extended the low level hid API. But not as extensively as I suggested. But I consider this to be a lost opportunity. Currently the ll driver must assume that the device is required to be fully operational when it is open. This means different things for ordinary input devices and "raw" devices. Raw devices must not be autosuspended when open at all. Ordinary devices must be able to process input. But that is often overkill. In many situations, for example when a the screen saver is running, you only care that a key has been pressed, not which key. Drivers can save more power if they know this. Quote Alan Stern: > Would it make more sense never to autosuspend a device that has an open > hidraw interface? Then if you want to, you could add an API allowing That is the sane default. > the user to tell the kernel to suspend or to resume (if the existing > sysfs interface isn't sufficient). The existing sysfs interface is clearly not designed for this. It's designed for system administration work. We are talking about ordinary user tasks accessing a generic interface. This leads to the following deficiencies: - the sysfs interface is specific to USB, hidraw is for all HID devices - the sysfs interface operates on physical devices, hidraw on logical devices - the sysfs interface is not designed to be shared among tasks - user space tasks know a device node, not the sysfs directory Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
