The code that didn't list attached slave devices for XI1 clients doesn't
exist anymore, so there's no need for these presence events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Previously, an active grab on an attached slave device would send the device
floating for the duration of the grab. This breaks existing XI applications
(e.g. the GIMP) since they grab all devices automatically - resulting in the
loss of control over the VCP.
The behaviour of extended input devices during a grab in relation to the
core pointer is not specified in the XI protocol specification.
The removal of the temporary detachment restores the behaviour of extended
input devices as present in currently released servers - even if a device is
grabbed, an event from this device will result in an event from the core
pointer.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Master devices must have the standard button map applied for all buttons to
ensure buttons larger than 7 (the default for MDs) are mapped appropriately.
We can't copy the button map from SDs to MDs since that breaks the chained
button mapping. However, by ensuring all buttons (even non-existing ones)
are mapped, devices that send such buttons continue to work.
X.Org Bug 22594 <http://bugs.freedesktop.org/show_bug.cgi?id=22594>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Xtst devices get this property assigned automatically so they can be
detected easily by a client.
The property is read-only.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Rather than storing a simple boolean in the devPrivate for XTest devices,
store the actual master device's id (since it is constant for the life of
the device anyway).
Callers should use GetXtstDevice now instead of digging around in the
devPrivates themselves.
This patch allows for a cleanup in the creation of new master devices since
GetMaster and GetXtstDevice spare the need for loops, IsPointer checks and
similar.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Benjamin Close <Benjamin.Close@clearchain.com>
The callers should need to use the dev privates key to look up xtest
devices.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Benjamin Close <Benjamin.Close@clearchain.com>
This makes the ptr accel api actually sensible from a driver
perspective, since it avoids superfluous device lookups.
Also, makes independent accel contexts possible.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Allows security modules to enforce what property contents can be set by
clients. Uses the new DixPostAccess bit to distinguish between the
existing call made during the lookup (with the old property data) and
this new call. Note that this only applies to writes, prepends, or
appends to existing properties; for new properties the existing
DixCreateAccess hook call may be used since it includes the new data.
Refer to the XACE-Spec document in xorg-docs, section "Property Access."
Signed-off-by: Eamon Walsh <ewalsh@tycho.nsa.gov>
Presumably, some intelligent, XI2-aware management app will be calling
XISetClientPointer on behalf of other clients; this check makes sure
the target client has permission on the device.
Requires changing the prototype to return status code instead of Bool.
Signed-off-by: Eamon Walsh <ewalsh@tycho.nsa.gov>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
LookupClientResourceComplex is used by DRI1 code to find and free a DRI
drawable in a callback, however when the DRI code returns this->value
is now pointing at freed memory. It seemed easiest to store the value
to a temporary and return it afterwards.
Another option might be a new FreeClientResourceComplex or one that
also returns the id, so we can free it using an alternative means.
found using valgrind.
amended along ajax's suggestions
Maps are CARD8s, therefore checking for values above 255 is completely
unnecessary. Moreover, 0 is a valid value for maps, so the check wasn't
even correct to begin with. This fixes bug #22392, which was uncovered
by commit 280b7f92d7.
Signed-off-by: Ben Gamari <bgamari.foss@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Master devices provide the union of all attached slave devices' buttons,
i.e. the number of buttons on the master device is always the number of
buttons of the slave device with the highest number of buttons. When slaves
are attached or detached, the master device adjusts the button number to
reflect the new buttons.
On a slave switch, this slave's button labels are copied into the master (up
to slave->num_buttons). The remaining button labels (if any) stay as they
are. Thus, if any of the higher buttons is still pressed, it reflects the
label of the last pressed device that provided this button.
If two devices press the same button and it is differently labelled the last
pressed one will be reflected in the master device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
MD's will soon be the union of all devices anyway. XTest pointers are only
for the core protocol XTest stuff, so 7 buttons (lmr + 4 wheel buttons)
should do.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Note: ABI break, but ABI_XINPUT_VERSION has NOT been bumped. Recompile input
drivers.
Revert "Xi: return BadImplementation for deviceids 256 and above"
This reverts commit 2b459f44f3.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Some files (notably those merged with MPX before XI2 came along) didn't use
a 'xi' prefix. This patch changes all of them to meaningful names.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
inputstr includes XI2proto.h for the sole purpose of XI_LASTEVENT.
However, using XI_LASTEVENT in the server is prone to errors, if the server
is recompiled against a newer version of the protocol it would bump this
variable and associates bits, including potential ABI.
This patch defines an XI2LASTEVENT for use in the server and removes the
XI2proto.h require. XI2LASTEVENT is the current value of XI_LASTEVENT.
This patch is required by components that require access to inputInfo
(currently xf86-video-geode and xf86-video-cirrus) but should not have a
require for the XI2 protocol.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This stops inputstr.h being needed to be included by output drivers.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
event->type is always GenericEvent for XI2 events. Instead, XI_ButtonPress
(the generic event's evtype must be stored.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
it's unclear whether there actually is a problem, but in a very similar
case there is (bug#21456). Also, integer addition is generally faster.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Valuator events need to include the device's state, while other device
events need to include the state of the core devices.
Reported-by: Thomas Jaeger
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
GetMaster is more reliable than GetPairedDevice, it always returns the
keyboard/pointer if desired, even if the wrong device was passed in.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Let EventToXI, EventToCore and EventToXI2 return BadMatch if there's no
matching event for this protocol spec.
Adjust the delivery paths to cope with BadMatch errors (and clean them up on
the way).
As a side-effect, this fixes server crashes on proximity events for a
grabbed device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For proximity events, the XI2 type is 0 and inputMasks never got set in the
preceding condition. As a result, proximity events got never delivered.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
These grabs are suported through two fake devices inputInfo.all_devices and
inputInfo.all_master_devices. These devices are not part of the device list
and are only initialised for their device id, nothing else.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A passive XI2 grab always uses the paired master device as a modifier
device. After issuing a passive grab, the slave may be reattached to a
different master and hence the modifier device may change.
Rework addresses two issues:
- storing the master device's pointer is a bad idea, we need to store the ID
of the device in case it disappears during the grab.
- restoring the old master did not actually reattach the device. Fixed now.
grab->type is the device type and XI2 types overlap with core events (being
less than GenericEvent). Thus, for passive grabs the grab device would be
overwritten with whatever device was activating it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
