Re: autosuspend for hid
Oliver Neukum <[email protected]>
| Newsgroups | gmane.linux.usb.devel |
|---|---|
| Organization | Novell |
| Message-ID | <[email protected]> |
Am Mittwoch, 16. Mai 2007 10:24 schrieb Robert Marquardt: > Oliver Neukum schrieb: > > >> Writing reports to a device from kernel? Why would that be needed? > > > > It is in my experience mainly needed for setting and clearing the LEDs. > > But I don't claim to know all input devices in the kernel tree. > > Does hat really have to be handled on low-level? It should be possible > to forbid such interactions on the lower levels without getting regressions. Where would you put it? To make things easier it would have to be on a work queue and thus subject to kernel threads being scheduled. > > Preserving the LEDs working under the worst circumstances is important. > > I am not sure whether it is a good thing that all keyboards share CAPS LOCK, > > etc... , but that's a wider issue. > > If handled at higher levels there are two way to handle suspended > keyboard. Either first wake it up or decide to not write to it. Yes, but we cannot drop the LEDs if CAPS_LOCK is common to all keyboards. > I do know about special keyboards which do not have a concept of CAPS > LOCK, SCROLL LOCK or NUM LOCK at all for the simple reason of not having > the corresponding keys. > Personally i do not think the keyboards should be held in sync (aka > having a single virtual keyboard). That is a whole new debate. Feel free to start it on the input list. Regards Oliver ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel