Jiri Kosina schrieb: > first, why did you remove me from CC when responding?
Sorry, on too many lists with widely varying reply rules. Just goofed. > 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?). The basic problem is the difference between CAPS LOCK event and CAPS LOCK state. The state may be in user space only. Windows even has it on a per process base (At least theoretically. It is not very well documented what the difference between GetKeyState and GetAsyncKeyState is). >> 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). When i find time (yet another list to subscribe to). ------------------------------------------------------------------------- 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
