[RFC] xserver: Masked valuators, DIDs, and ABS_MT_SLOT

[Chase Douglas]

On Fri, 2010-07-02 at 10:27 +0200, Henrik Rydberg wrote:
> Chase Douglas wrote:
> > The following changes since commit a71dbc03e65cf7b0654a6eca93ce0bf6a1711ffa:
> > 
> >   Bump to version 1.8.99.904 (1.9 RC4) (2010-07-01 08:27:05 -0400)
> > 
> > are available in the git repository at:
> >   git://kernel.ubuntu.com/cndougla/xserver.git master
> > 
> > Chase Douglas (3):
> >       Add extra functions for masked valuator input API
> >       Add internal direct input device handling
> >       Add atom name for ABS_MT_SLOT properties
> > 
> >  Xi/exevents.c                  |    5 +-
> >  Xi/xiproperty.c                |    1 +
> >  dix/devices.c                  |   33 +++++-
> >  dix/eventconvert.c             |    4 +
> >  dix/events.c                   |   19 ++-
> >  dix/getevents.c                |  282 ++++++++++++++++++++++++++++------------
> 
> The rangeToMask allocates memory in the inner event loop...
> 
> The whole mapping construction seems a bit backwards. If unused valuators are
> never referenced, there is no need to do all those extra copies. As a side effect,
> 
> *EventsM(events, pDev, type, key_code, mask, num_valuators, all_valuators);
> 
> could be implemented like
> 
> *EventsM(events, pDev, type, key_code, mask, num_valuators + first_valuator,
> valuators - first_valuator);

My thought was to keep the API simple and in line with previous
functions. Thus, the bitmask and the valuators arrays start at the 0th
valuator index of the device.

To get around doing any copying when *Events functions are called, we
could either duplicate the code so that we don't send *Events calls
through *EventsM, or we could change the *EventsM valuators argument
meaning: instead of being an array starting at the 0th valuator, it
would start at the first valid valuator in the bitmask.

Though not as simple in theory, it's not that complicated, so I'll just
change the meaning of the valuators argument and get rid of the copying.

> The bit mask is memory efficient, why not allocate in on the stack? It would
> certainly be a lot faster.

Yeah, that makes more sense. I'll update the code.

-- Chase