Alan Coopersmith wrote: >> The hotkey keyboard device registers itself in devPrivate field of Core >> keyboard device >> (which is always pointed to by inputInfo.keyboard) using a new index >> HotkeyMapDevicePrivateKey with dixSetPrivate(). In keymap switch function >> SwitchCoreKeyboard(), no switch takes place if the new device is found >> to be >> hotkey keyboard device - the latter can be retrieved with >> dixLookupPrivate() >> using the same index. >> > *sigh* That sounds like a level of change to the core input routines that > are going to be painful to port to each new Xorg community release, such as > the upcoming Xorg 1.6 that greatly changes input device internals again, and > the followon release which is planned to introduce Xinput Extension 2.0 with > another round of changes to input device internals - have you made any attempt > to get these upstream?
Since the logic for this is simply "do not call keymap switch function if the new device is hotkey input device", it shouldn't be too difficult to port to new releases. Xorg 1.6 still has one virtual core keyboard device - VCK. But switch is based on master keymap. SwitchCoreKeyboard() is gone, replaced by CopyKeyClass(). I can apply the same code to it. Note devPrivate field of VCK has already been used to remember the device generating previous keystroke with index CoreDevicePrivateKey. I talked upstream briefly, basically he was against patching keymap of VCK dynamically as there are substantial changes coming handling keymaps, and insisted keymap still should be device based. This is why I reversed design to Model II. I don't think upstream will like our changes, because they use everything in evdev: evdev driver, evdev set of keycodes, evdev stanza of symbols/inet. Yet I still don't understand how this static method can work in all keybaord model/layout. -Henry
