lack of GetModifierMapping/SetModifierMapping symmetry

[Peter Hutterer]

On Thu, Apr 30, 2009 at 09:14:43AM +0200, Pierre Ossman wrote:
> On Thu, 30 Apr 2009 12:25:50 +1000
> Peter Hutterer <peter.hutterer at who-t.net> wrote:
> 
> > On Tue, Apr 28, 2009 at 04:07:37PM +0200, Pierre Ossman wrote:
> > > 
> > > The reason this happens is how Xorg handles the mapping between the
> > > multiple keyboards internally and the single keyboard exposed via X11.
> > > A call to GetModifierMapping gives you the mappings for the currently
> > > active keyboard, but SetModifierMapping modifies the mappings for all
> > > keyboards (strictly speaking, all core keyboards).
> > 
> > Assuming that SetModifierMapping works on all keyboards, GetModifierMapping
> > from any keyboard is identical to any other one. This theory applies to a
> > couple of calls that allow to query or apply magic on an input device.
> > 
> 
> In which case I'd consider the mechanism for adding new keyboards
> broken. If the idea is that the modifier mapping should be global, then
> adding a new keyboard with a different mapping should either a) change
> the global mapping, or b) overwrite the mapping on the new keyboard
> with the global one.

The modifier mapping isn't global. it applies to the core keyboard which is
defined by the core protocol. All core calls only apply to this keyboard.
In the past this was't a problem since we only had one keyboard anyway.

Now we have multiple keyboards and they all "send core events", i.e. they
cause the core keyboard to send events when they move. AFAIK, the mapping
between core and extension devices isn't defined in the XI protocol spec.
The keyboard's map is now copied automatically into the core keyboard,
allowing setups with two physical keyboards that have two different layouts. 
(This is essentially what SwitchCoreKeyboard() does)

Because of this, the current behaviour is that when a client changes the core
keyboard's mapping, it also changes each extension keyboard's mapping. This
way we end up with a consistend key table on all keyboards. Otherwise,
changing the keyboard layout means you only change it on the core keyboard and
once you hit a key on another keyboard, this change is gone and you have to
reapply.

> > > I'm not entirely sure how to fix this. I'd like to understand why
> > > GetModifierMapping/SetModifierMapping are implemented the way they are
> > > first though. Does anyone have any insight into that?
> > 
> > For years the server looked the same so clients relied on a certain behaviour.
> > Now, with multiple keyboards that may all be independent we have to balance
> > between doing the right thing and not breaking clients.
> > 
> 
> This is not a behaviour that has been with us for years. It was added
> for xserver 1.3. So apparently modifying just the active keyboard was
> not a major problem until then.

The active keyboard never changed in the past. that's essentially the big
difference.

> Daniel did not describe why the change was needed in his commit message
> unfortunately.


> > MPX gets rid of this in parts because the requests only work on a single
> > master device at a time. If you only have a single MD however, the behaviour
> > shouldn't be any different.
> > 
> > The fix for you in libvnc/Xvnc would simply be to initialise a default mapping
> > for the magic keyboard, wouldn't it?
> >  
> 
> I do, but it gets overwritten by the mapping of another keyboard.
> 
> I've done a quick hack that does a SwitchCoreKeyboard() to the VNC
> keyboard once it gets the "on" call to its keyboard proc. That seems to
> work well enough for the Xvnc case.

Is the VNC keyboard an extension device or does it replace inputInfo.keyboard?

Cheers,
  Peter