setxkbmap options bleed across devices
Submitted by Glen Whitney
Assigned to Xorg Project Team
Link to original bug (#107944)
Description
I am running the X.org server version 1.20.1 with setxkbmap 1.3.1 in a standard xfce4 environment (the distribution is OpenSUSE Tumbleweed).
Immediately after startup, if I execute (say)
setxkbmap -device 14 -option ctrl:swap_lalt_lctl
setxkbmap -device 19 -option ctrl:menu_rctrl
then not only does the menu key on the keyboard which is device 19 act as a control key, but the left alt and left control keys are swapped on that device as well. The expected behavior is that on device 19, the menu key would act as a control key, but that the left alt and left control keys would be left alone.
I do understand that the reason this is occurring is that regardless of the -device option, setxkbmap is writing the options to a single property on the root window, and so has no way of telling in the second invocation that ctrl:swap_lalt_lctl was only set on device 14. Nevertheless, the resulting behavior as described above is clearly a bug resulting from the recordkeeping by setxkbmap being inadequate to reflect the actual state.
Please don't respond that the "solution" is to include an empty -option argument on (at least) the second command to ignore existing options:
setxkbmap -device 19 -option -option ctrl:menu_rctrl
That is at best a workaround, not a solution; and moreover, I am reporting just a simplified example of the problem, to focus attention on the central issue. In my actual use case, I have some options that are set globally (i.e. on the X core keyboard), and then need to set options on individual keyboards. So I want setxkbmap to incorporate those global options and add the keyboard-specific ones. And I can't reconstruct the global ones at the point where I am invoking setxkbmap for the individual keyboards, as they were set elsewhere and may not be the same each time I get to the setxkbmap for the individual keyboard -- I expected setxkbmap to have that information, and it should.
In my opinion, either the Rules/Model/Layout/Variant/Option information should be made a first-class part of the XKB protocol, so the individual keyboards "know" that information, or the properties stored on the root window need to be extended/refined so that they can capture and record the actual state of affairs more accurately. I am certainly willing to contribute to the resulting coding effort (i.e. submit a candidate implementation) if there's guidance from the administrators as to what route should be pursued and a sense that's there's interest/willingness to go down that route.
Thanks for your consideration.
Version: 7.7 (2012.06)