libXfont has stubs for these symbols, so, when compiling with hidden
symbols by default, these symbols must be visible in the X Server, or
the stubs in libXfont will be used.
I merged the wrong patch. See correct patch at:
http://lists.freedesktop.org/archives/xorg/2008-November/040540.html
Not activating the device before attempting to enable it would leave the
sprite unset, crashing the server when enabling the real devices.
This reverts commit e078901a4e.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
This prevents a protocol visible side-effect (XVisibilityEvent) on
XCompositeRedirectWindow() followed by a XCompositeUnredirectWindow().
The problem shows up in gnome-screensaver with compiz and "unredirect
fullscreen windows" enable. A VisibilityNotify event is generated (first
with obscured and than with unobscured) when the window swithces from
redirected to unredirected.
https://bugs.freedesktop.org/show_bug.cgi?id=18133http://launchpad.net/bugs/278112
As proposed by Owen Taylor [1], the enter-leave event model needs to adjust
the events sent to each window depending on the presence of pointers in a
window, or in a subwindow.
The new model can be summarised as:
- if the pointer moves into or out of a window that has a pointer in a child
window, the events are modified to appear as if the pointer was moved out of
or into this child window.
- if the pointer moves into or out of a window that has a pointer in a parent
window, the events are modified to appear as if the pointer was moved out of
or into this parent window.
Note that this model requires CoreEnterLeaveEvent and DeviceEnterLeaveEvent to
be split and treated separately.
[1] http://lists.freedesktop.org/archives/xorg/2008-August/037606.html
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
FirstPointerChild: Return the first child that has a pointer within its
boundaries.
FirstPointerAncestor: return the first ancestor with a child within its
boundaries.
These are required for the updated enter/leave model.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
Device events always need to be delivered, core events only in some cases.
Let's keep them completely separate so we can adjust core event delivery.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
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.