Hi, On 24 February 2014 22:56, James Cloos <[email protected]> wrote: > 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.
Depends. Every key press generates two events - one for the slave and another for the master, and both are processed totally differently. So if you had Num Lock being set in this manner (actually locked on the master, but only updating the LED for the slave), then pressing 4 would result in a KP_4 keypress on the master, and a KP_Left press on the slave. Still not present, but as Peter says, don't listen to slaves which are attached to masters and expect sensible results ... > 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? Ugh, that sounds like the worst of all possible worlds, if I'm honest: this is one place we really, really, don't need more complexity and unexpected behaviour. I'd prefer us to just make a decision one way or another - go all-out and forcibly harmonise keymaps, or one of the compromises along the way - and stick with that to the bitter end. Cheers, Daniel _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
