[PATCH] Export include/input.h:GetMaster() function

Peter Hutterer peter.hutterer at who-t.net
Mon Oct 24 17:20:49 PDT 2011

On Mon, Oct 17, 2011 at 01:17:15PM +0200, Adam Tkac wrote:
> On 10/13/2011 07:29 AM, Peter Hutterer wrote:
> > On Wed, Oct 12, 2011 at 12:44:00PM +0200, Adam Tkac wrote:
> >> On 10/12/2011 06:27 AM, Peter Hutterer wrote:
> >>> On Tue, Oct 11, 2011 at 03:12:56PM +0200, Adam Tkac wrote:
> >>>> attached patch exports the GetMaster() function, it is needed by
> >>>> TigerVNC's libvnc.so module. Please merge it also to 1.11 release, thank
> >>>> you!
> >>> where/how do you need this? afaict this function hasn't been exported since
> >>> it was added (pre-1.6) so I guess something must have changed that this is
> >>> needed now.
> >>>
> >>> I'm not a big fan of exporting random functions without knowing why,
> >>> especially given how much of a mess our ABI already is.
> >>>
> >>> Cheers,
> >>>   Peter
> >> Previously, we simply got master from slave->u.master. I though it
> >> is more appropriate to use GetMaster(), this is the reason why it
> >> wasn't needed before. If you don't like to export GetMaster() (well,
> >> I don't think this function will change it's parameters in the
> >> future), I will use the former slave->u.master approach. Please let
> >> me know your decision.
> > again, what do you need it for? git grep GetMaster() hw/ shows only two uses
> > in the Xorg DDX. One is to get the right state for the protocol (DGA) and
> > one is to prevent hardware-cursor rendering in an MPX setup. I wonder what
> > VNC needs to know the hierarchy for.
> >
> > Cheers,
> >   Peter
> VNC creates it's own keyboard and pointer devices and sends both "key"
> and "mouse" events received from the VNC client via this devices to the DIX.
> Currently we need to know the master device to obtain actual keymap and
> XKB state field. We also dynamically add new keycodes to the keymap so
> we simply modify master's keymap and then sync slave and master via
> CopyKeyClass() function.

each slave device may have a different keymap, so there's no "actual
keymap". the master's keymap is the one from whichever was the last keyboard

same with the adding keymaps, the master should sync itself. if not, that's
a bug that needs to be fixed anyways.

> When I created this code (Xorg 1.5.X or 1.6.X times) I remember that
> obtaining XKB state and modifying keymap didn't work on slave devices,
> we needed to work with the master. Not sure if this assumption is still
> valid with the latest releases of Xorg...

hmm, should work, quite a few things have changed since and the xkb code is
a bit better now.


More information about the xorg-devel mailing list