dispatch.h was leftover from an earlier implementation and is no longer
needed, so remove it since including it causes a build failure due to
conflicts between GL/gl.h and OpenGL/gl.h
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Uses /proc/pid/psinfo to read command & partial arguments.
Moves cmdsize & argsize variables into non-Solaris #else clause
to avoid unused variable warnings.
Fixes format mismatch errors when building with DEBUG defined on
a 64-bit platform (where Mask is defined as CARD32).
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Rami Ylimäki <rami.ylimaki@vincit.fi>
Signed-off-by: Keith Packard <keithp@keithp.com>
long i;
for (i = 1; ; i <<= 1)
if (i == (1 << 31))
break;
(1 << 31) is compiled as an int, and thus is equal to -2147483648. We
are trying to compare it against a long, which on 64-bit machines is
2147483648. This results in an infinite loop.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The touchid test was using a loop like:
for(i = 1; i < 0xffffffff; i <<= 1)
When 'i' is a 32-bit variable, this infinite loops as it goes from
0x80000000 to 0. 'i' is declared as 'long', which is 32-bit in 32-bit mode.
Signed-off-by: Keith Packard <keithp@keithp.com>
Debian's QA tool “lintian” reported a bad whatis entry for the
xorg.conf(.d) manpages.
It comes with the following pointers:
For manual pages that document multiple programs, functions, files, or
other things, the part before "\-" should list each separated by a
comma and a space. […]
Refer to the lexgrog(1) manual page, the groff_man(7) manual page, and
the groff_mdoc(7) manual page for details.
Indeed, the current situation is:
$ whatis xorg.conf; whatis xorg.conf.d
xorg.conf (5) - (unknown subject)
xorg.conf.d (5) - (unknown subject)
With this patch:
xorg.conf (5) - configuration files for Xorg X server
xorg.conf.d (5) - configuration files for Xorg X server
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Cyril Brulebois <kibi@debian.org>
This test checks that last-valid-mode + 1 returns a BadValue. With the
addition of XIGrabModeTouch, that value has changed - sync it up again.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
If the device is already grabbed, don't activate the passive grab, it screws
with our event masks. Just deliver to the grabbing client instead.
Reported-by: Carlos Garnacho <carlosg@gnome.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Leftover code from an earlier version of GetTouchEvents.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
An empty list points to itself but syncEvents has the list head only and is
of a different format than the elements. Thus, casting it to a QdEventPtr
gives us garbage.
Segfaults with XTS test case Xlib13/XGrabKeyboard
Introduced in 7af23259d8.
Reported-by: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
If the device is mapped 3 2 1, a click on physical button 1 sends a button 3
press, but the state was set for button 1. Fix this, the state must be set
for that button's logical mapping.
https://bugzilla.gnome.org/show_bug.cgi?id=655928
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
CreateGrab() expects the keyboard mode to be stored in grab_mode, and the
pointer mode in other_device_mode, so respect this in passive XI2 grabs,
and switch modes if needed.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Co-authored-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Consists mostly of generating an ownership event and processing it.
Co-authored-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Ownership changes don't get processed directly when they happen, instead the
DIX submits an ownership event which goes through ProcessTouchEvents and
ProcessTouchOwnershipEvents.
Then on the required events are generated and sent to clients.
Co-authored-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Includes a hack for implicit grab activation, because integrating this
requires a larger rewrite and I'm not sleeping enough as it is.
Right now, we deliver the event and check before/after if there is an
implicit grab on. If one activated, then store the event in the grab and
switch the listener type to a grab listener.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
For touch events with pointer emulation, the event that triggers the grab
(the pointer event) is not the same as the actual event (the touch event).
For replaying, we need to store the real event then.
No effective changes at this point, for the current caller event and
real_event are identical.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Does not include pointer emulation handling.
Does include partial ownership handling but not the actual processing of
ownership events.
Note: this commit is a retroactive commit extracted from a series of ~50
commits and may thus appear a bit more complicated than what you'd write out
from scratch.
Pointer processing tree is roughly:
- ProcessOtherEvents
- ProcessTouchEvents
- DeliverTouchEvents
- DeliverTouchBeginEvent|DeliverTouchEndEvent|...
- DeliverOneTouchEvent
Also hooks up the event history playing to the right function now.
Co-authored-by: Daniel Stone <daniel@fooishbar.org>
Co-authored-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
If a pointer-emulating touch caused a button to be logically down, set that
state in the input events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Update the logical button state for pointer-emulating events. Button state
must be kept separate from the ButtonClassRec to avoid clearing the button
state on a touch end if there is a physical button still down.
And obviously don't change the button state if we're currently replaying the
event history for some client.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
The first listener in the sequence is the owner of the touch sequence.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
The DIX will call TouchSetupListeners once for a new touch. After that
the listener list remains static, with listeners only dropping out when they
either reject the grab or disappear.
Exception: if grabs activate they are prefixed to the listeners.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Returns the respective pointer event type for a given touch event type.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Touch events' sprite trace stays the same for the duration of the touch
sequence.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
If touch client has not registered for ownership events and a grab above
that client is rejected, the client needs to receive the complete event
history.
The history currently doesn't really do fancy overflow handling. We assume
that the first TOUCH_HISTORY_SIZE events are the important ones and anything
after that is dropped. If that is a problem, fix the client that takes > 100
event to decide whether to accept or reject.
Events marked with TOUCH_CLIENT_ID or TOUCH_REPLAYING must not be stored in
the history, they are events created by the DIX to comply with the protocol.
Any such event should already be in the history anyway.
A fixme in this patch: we don't have a function to actually deliver the
event yet.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Selecting for any of XI_TouchBegin/Update/End/Ownership requires the three
bits for begin/update/end to be set.
Only one client at a time may select for XI_TouchBegin event
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
The DIX needs to submit touch events for e.g. TouchEnd after an
acceptance/rejection. These have the TOUCH_CLIENT_ID flag set.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
If the device is mapped 3 2 1, a click on physical button 1 sends a button 3
press, but the state was set for button 1. Fix this, the state must be set
for that button's logical mapping.
https://bugzilla.gnome.org/show_bug.cgi?id=655928
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
An empty list points to itself but syncEvents has the list head only and is
of a different format than the elements. Thus, casting it to a QdEventPtr
gives us garbage.
Segfaults with XTS test case Xlib13/XGrabKeyboard
Introduced in 7af23259d8.
Reported-by: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
While a redirected window is flipped, its pixmap may still be used as
and EGL image and should also get invalidated. When sending invalidate
events for a window, also send the events for its pixmap.
Signed-off-by: Ville Syrjälä <syrjala@sci.fi>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Without this, when a compositing manager unredirects a fullscreen window which
uses DRI2 and page flipping, the DRI2 buffer information for the compositing
manager's output window (typically the Composite Overlay Window or root window)
may become stale, resulting in all kinds of hilarity.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=35452 .
[Original patch by Michel Dänzer <michel@daenzer.net>]
[Tree walk optimized version by Keith Packard <keithp@keithp.com>]
Signed-off-by: Ville Syrjälä <syrjala@sci.fi>
Signed-off-by: Keith Packard <keithp@keithp.com>
Otherwise we might keep stale cached information, e.g. after the driver
performed page flipping.
This is part of the fix for
https://bugs.freedesktop.org/show_bug.cgi?id=35452 .
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@nokia.com>
Reviewed-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: Keith Packard <keithp@keithp.com>
If the client is not behaving correctly and swaps buffers before
getting them, Valgrind will complain about uninitialized memory being
used in DRI2InvalidateDrawable.
Signed-off-by: Rami Ylimäki <rami.ylimaki@vincit.fi>
Reviewed-by: Ville Syrjälä <syrjala@sci.fi>
Signed-off-by: Keith Packard <keithp@keithp.com>
Compiler warning:
xinput.c:272: warning: dereferencing pointer 'e' does break strict-aliasing
rules
The code itself is the usual XInput client-side code:
XEvent event;
XDeviceMotionEvent *e = (XDeviceMotionEvent *)&event;
XNextEvent(display, &event);
printf("%d\n", e->type);
Since XDeviceMotionEvent is not guaranteed the same size as XEvent, clients
must use pointer aliasing as above when using the XNextEvent API. Disable
strict aliasing for this example.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Gaetan Nadon <memsize@videotron.ca>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Signed-off-by: Keith Packard <keithp@keithp.com>