Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
We need them for each window, every time a window is allocated. Storing them
in a devPrivate is the wrong thing to do.
This also removes the unused ENTER_LEAVE_SEMAPHORE_ISSET macro.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
grab == devgrab anyway, this is a leftover from the time when we had two
different grabs per device (core and XI grab).
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
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.
EnableDevice and DisableDevice both change the property too.
And enabled must be set to FALSE in AddInputDevice, the device is not enabled
yet.
X.Org Bug 18111 <https://bugs.freedesktop.org/show_bug.cgi?id=18111>
dev->enabled is a Bool. Bool is two bytes.
BOOL on the other hand is a protocol type and always 1 byte. So copy the value
into the one-byte type before passing it into XIChangeDeviceProperty.
Found by Michel Dänzer.
X.Org Bug 18111 <http://bugs.freedesktop.org/show_bug.cgi?id=18111>
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.
For two axes [a, b] and [x, y] (inclusive), the formula to scale point P(ab)
to (x,y) is:
(P - a)/(b - a) * (y - x) + x
And the whole end result rounded of course to get the integer we need.
It's not especially obvious, and unpleasantly overloaded for the Xnest
case. Typically this gives you a server that looks for its auth data in
the authority file you were using for the running X session, which
generally doesn't have an entry for the display you just started.
All the major dm's, and startx, pass -auth explicitly, so this shouldn't
cause too much upheaval.
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.
