>>>>> "PH" == Peter Hutterer <[email protected]> writes:
PH> the less-intrusive alternative would be to force only the indicator state PH> down to the slaves. won't change keyboard behaviour as seen by the client PH> and still has the effect that most people expect from their keyboards. PH> comments? So hitting compose on one keyboard would light the compose led on all associated keyboards but only intitiate a compose sequence on the one? Or caps-lock? Or level shifts? Or group toggles? If I read that right, that seems even worse. I'd want indicator state on a phisical kbd always to match what that kbd will do. I'm not certain about the other two options, though. Given that I use a keyboard which shows up as two usb endpoints, and each endpoint is a separate slave kbd to the shared master, I'd prefer that shift, et alia states for one slave apply to all. But that may not be right for everyone's setup. Perhaps xinput(1) should be able to configure whether given slaves share such state with their brethren? -JimC -- James Cloos <[email protected]> OpenPGP: 1024D/ED7DAEA6 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
