[PATCH 6/6] xserver: input device id counter fix

Magnus Vigerlöf Magnus.Vigerlof at home.se
Fri Mar 30 14:18:22 PDT 2007

On Friday 30 March 2007 02:55, Peter Hutterer wrote:
> > inputInfo.devices: All devices which has a successfully called
> > DEVICE_ON are
> > here. New devices are added to the end of the list.
> >
> > inputInfo.off_devices: All new devices that not yet has been called
> > for or those that this function failed. Or all those that has been
> > called
> > DEVICE_OFF. New/old devices are added to the end of the list.
> there's an important difference (at least in mpx): off_devices don't
> have sprites and thus aren't rendered. in fact, parts of the structs
> are uninitialised and if you would try to send events from an off
> device the server would give you a mass discount for segfaults. ATM,
> anything in off_devices can be ignored from the event delivery and
> cursor rendering side of things. checking each device for a on/off
> state would make code harder to read.

Ok, good reason for keeping them in two different lists.

> cpu time is cheap, especially if we only need to do it when devices
> are added/removed, which - presumably - doesn't happen too often.
> unless somebody cascades 100 devices up and then decides to plug/
> unplug the main USB hub* we shouldn't have a problem with it.

You're right, I'll update this patch so it sorts the two lists instead of 
using an additional array. The lookup time should still be linear anyway so I 
don't see a problem unless the lists are messed with outside this file.

If I remember correctly the MAX_DEVICES are set to 20 logical devices so the 
lists won't get that long anyway. 20 seems to be an awful lot of devices, but 
the wacom driver is one of those that can have several tools (stylus, mouse, 
eraser, ...) on one physical device. So maybe it's not that much anymore.

20 might be a little close to the number of devices for the extreme user so 
maybe it's time to increase this to a higher number, could there be a reason 
for keeping it this 'low'? Latency in event-handling? A new value of 64? 
(Yes, a value taken from thin air, but it should last a while) Normal users 
shouldn't be affected of this in any way at all if they don't have any 
problem today.

  Magnus V

More information about the xorg mailing list