The window ID includes the client ID anyway, so we might as well just look up
the client directly instead of trying to get the window first and the client
from the window.
This also fixes a possible issue with XACE. If the client had permission to
write on the client but not on the window, the previous approach would have
failed.
All the rest of XI uses rc and returns rc in case of error, so make
mpx-related stuff comply. This stops the rest of XI sending the error
manually.
This is just a cosmetic change to be in line with the rest.
I need sleep! Why am I making these stupid mistakes... sorry for pointless commit spam. ugg.
(cherry picked from commit b16351fc6457aabead328472d16dc25789032940)
General code cleanup, whitespace, dead code removal, added missing prototypes.
Made Xquartz come to foreground later in startup, so it doesn't appear for Xquartz -version
(cherry picked from commit 36922e8ff4316c93843aa3fe959cf8df3c7d5892)
In some cases (triggered by a key repeat during a sync grab) XKB unwrapping
can overwrite the device's realInputProc with the enqueueInputProc. When the
grab is released and the events are replayed, we end up in an infinite loop.
Each event is replayed and in replaying pushed to the end of the queue again.
This fix is a hack only. It ensures that the realInputProc is never
overwritten with the enqueueInputProc.
This fixes Bug #13511 (https://bugs.freedesktop.org/show_bug.cgi?id=13511)
(cherry picked from commit eace88989c)
This doesn't change much, as the struct previously given has the same size as
the ones now anyway. Still, we should be pendantic.
Thanks to Simon Thum for reporting.
In some cases (triggered by a key repeat during a sync grab) XKB unwrapping
can overwrite the device's realInputProc with the enqueueInputProc. When the
grab is released and the events are replayed, we end up in an infinite loop.
Each event is replayed and in replaying pushed to the end of the queue again.
This fix is a hack only. It ensures that the realInputProc is never
overwritten with the enqueueInputProc.
This fixes Bug #13511 (https://bugs.freedesktop.org/show_bug.cgi?id=13511)
From the X11 protocol spec:
"If background None is specified, the window has no defined background."
This means that toolkits and apps cannot rely on the "transparent" nature
of the current implementation! At some point before the next release,
XACE will switch back to a solid background as the default.
(first_valuator + num_valuators) must never be larger than the number of axes,
otherwise DIX freaks out. And from looking at libXI, anything larger than 6 is
wrong too.
(in case we get reports about slow launch times, this will
help clarify what's happening)
(cherry picked from commit 2eea3483cf893f8f81bacd434b31408dfb38cb06)
Initialise num_events to 1, so we always send a proximity event, and then
optionally valuator events. Also make sure mieq can deal with valuator
events sent after proximity events.
Peter Hutterer
David S. Miller
Fatih Aşıcı
Adam Jackson
Jeremy Huddleston
Eamon Walsh
Dave Airlie
Sam Lau
Dave Airlie
Samuel Thibault
Otavio Salvador
Ben Byer
Arkadiusz Miskiewicz
Bartosz Fabianowski