On Wed, 16 May 2007, Robert Marquardt wrote: > >> 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.
Hi Robert, first, why did you remove me from CC when responding? Anyway, what would be your proposal here? Currently the output reports (for changing the keyboard LEDs, for example) are being submitted as soon as the corresponding input event occurs (on different keyboard), which makes sense. Could you be more elaborate on what are the exact drawbacks you see here, and what would your proposal be? (postponing it into workqueue? why?). Thanks. > 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. If you decide not to write to it, it will get out of sync with all other keyboards attached to the system once it is woken up. > 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). If you think so, please raise this on linux-input mailing list (and CC at least me and Dmitry). Thanks, -- Jiri Kosina ------------------------------------------------------------------------- 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/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
