Lines Matching refs:lastSlave
9022 xkb: XkbSetMap on the lastSlave needs to change the master
11228 be set (i.e. “lastSlave” is still NULL).
19940 our way to the device's lastSlave here so as not to break assumption #1
89331 This fixes a server crash where the lastSlave is a pointer device without
97270 Move master/lastSlave out of the union into separate fields.
97274 if lastSlave was set (instead of master).
97387 dev->u.master is the same field as dev->u.lastSlave. Thus, if dev is a master
97433 These two were sideeffects of lastSlave being in the same field as the
97434 master. For devices generated by the master device directly, lastSlave was 0
107110 Silence GCC warning about uninitialized lastSlave variable
108914 lastSlave changes however increases the counter for the held key. On (4),
113435 In theory, an event coming in during GPE could reset our lastSlave, leading
113449 lastSlave == master, caused by double scaling. To avoid this, post the fake
122526 xkb: xkbGetKbdByName on the lastSlave needs to change the master (#21859)
122528 If the layout is changed on a master's lastSlave, the master needs to change
122530 lastSlave changes - which may not happen if only a single keyboard is
125506 Always update u.lastSlave
128765 Split the signal-handler's lastSlave out into a separate variable.
128767 dev->u.lastSlave was not signal safe since it was accessed by the DIX and
128770 'dev->last.slave' for the signal handler's lastSlave (used to generate
128772 'dev->u.lastSlave' for the DIX lastSlave (currently only used in
131509 out-of-range events when the lastSlave was an SD with an explicit axis range.
132714 include: fix indentation for lastSlave/master.
135750 If the MD's lastSlave was a devices with custom axes ranges, then a
135756 1) in the WarpPointer handling, get the lastSlave and post the event through
147209 If the lastSlave did not have a valuator that is to be updated now, it is
158098 dix: fix detritus from adding lastSlave field.
158113 include: add "lastSlave" field to DeviceIntRec.