dixLookupResource attempted to automatically detect whether the caller
wanted a lookup by-type or by-class, unfortunately, it guessed wrong for
RT_NONE. Instead of trying to make the guess better, this patch just reverts
the unification and creates separate functions for each operation.
(cherry picked from commit f8dd80d13b)
Signed-off-by: Keith Packard <keithp@keithp.com>
This wrong check may cause BadLength to be returned to the client even if the
length is correct.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 8b583ca2b2)
Signed-off-by: Keith Packard <keithp@keithp.com>
This property is used to denote type float for input properties. Such
properties can be accessed easily through the XIPropToFloat() function.
Code originally written by Simon Thum.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
(cherry picked from commit a48c81dcdf)
Converts an XIPropertyValuePtr to an integer, provided that type and format is
right.
Code originally written by Simon Thum.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
(cherry picked from commit 669f6810af)
This fixes the following bug. Assuming your window manager grabs
Alt+Button1 to move windows, map Button3 to 0 via XSetPointerMapping,
then press the physical button 3 (this shouldn't have any effect), press
Alt and then button 1. The press event is delivered to the application
instead of firing the grab.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit f7f85f6965)
The device's button down state array was changed to use DOWN_LENGTH and thus
bitflags for each button in cfcb3da7.
Update the DBSN events to copy this bit-wise state.
Update xkb and Xi to check for the bit flag instead of the array value.
Reported by ajax.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
(cherry picked from commit a85f0d6b98)
While we don't want to copy all other device classes into the VCK, we need to
copy the key class to transfer the layout from the SDs into the VCK.
This resembles the functionality of SwitchCoreKeyboard in server 1.5.
Thanks to Colin Guthrie for providing the follow-up patch (#19222)
X.Org Bug 19048 <http://bugs.freedesktop.org/show_bug.cgi?id=19048>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The VCP doesn't need to update the valuators anyway since it cannot send XI
events. Just skip that bit.
X.Org Bug 18882 <http://bugs.freedesktop.org/show_bug.cgi?id=18882>
Signed-off-by: Keith Packard <keithp@keithp.com>
CamelCase can be taken too far, and AFAICT there's no consumers of that
function yet anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Server 1.6 uses the X Input 1.x input model, where the core devices (VCP and
VCK) do not generate XI events. They don't have to swap device classes but
instead stay at the default number of classes at all times.
This means we can get rid of the DeviceClassesChangedEvents as well.
In XI2, we only list the VCP and the VCK as well as floating SDs to non-XI2
clients. This is not the case here, we just list all devices.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
XI2 abuses the GEV request to reply with the min/major version of the
supported extension if the length for the name is 0. Don't do that, yet.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
If the event is an XI event, we need to work on the correct device, not on
the VCK.
Adds XIGetDevice(event) function to extract the device from an event.
Really, this was a bad idea. It's not security, the UI features that would
have been cool (e.g. clicking through windows) aren't implemented anyway, and
there's nothing you can't achieve just by using plain XI anyway.
Requires inputproto 1.9.99.6.
The current code exposes to inconsistent updates, i.e. if handler N succeeds
but handler N+1 fails in setting the property, an error is returned to the
client although parts of the server now behave as if the property change
succeeded.
This patch adds a "checkonly" parameter to the SetProperty handler. The
handlers are then called twice, once with checkonly set to TRUE.
On the checkonly run, handlers _MUST_ return error codes if the property
cannot be applied. Handlers are not permitted to actually apply the changes.
On the second run, handlers are permitted to apply property changes.
Errors codes returned on the second run are ignored.
Most of its component get copied during CopyKeyClass anyway.
The ones that aren't:
postdown - never changed for virtual devices anyway.
down - shouldn't change that without sending events.
memcpy'ing the struct also copied mapWidth, which means we didn't realloc
during SetKeySymsMap lateron, overwriting the memory assigned to us.
X.Org Bug 16167 <http://bugs.freedesktop.org/show_bug.cgi?id=16167>
A property can only be deleted if any of the following is true:
- if a property is deletable and all handlers return Success.
- if a property is non-deleteable and the all handlers return Success AND the
delete request does not come from a client (i.e. driver or the server).
A client can never delete a non-deletable property.
