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>
The touchpoints are generated, enqueued but not processed since we don't
handle them in the event processing yet.
Co-authored-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
No callers yet. This API is not to be used by drivers, it's an API for the
DIX which will create ownership events mainly on touch acceptance/rejection.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
The DIX touchpoints are the ones used for event processing.
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>
The SIGIO handler forces us to drop the current touch and schedule the
actual resize for later. Should not happen if the device sets up the
TouchClassRec with the correct number of touchpoints.
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>
Adam reviewed the underlying changes in the Mesa generated scripts.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Generated code from Mesa contains dispatch for GLX_ARB_create_context
and GLX_ARB_create_context_profile. Provide stub implementations of
these functions so that the GLX extension will link.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This silences the GCC warning:
In file included from singlepixswap.c:36:0:
glxext.h:47:13: warning: redundant redeclaration of 'GlxExtensionInit' [-Wredundant-decls]
glxserver.h:80:6: note: previous declaration of 'GlxExtensionInit' was here
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
DDX touch points are the ones that keep records of the driver-submitted
touchpoints. They're unaffected by the grab state and terminate on a
TouchEnd submitted by the driver.
The client ID assigned is server-global.
Since drivers usually submit in the SIGIO handler, we cannot allocate in the
these functions.
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>
New additions to the API:
- InitTouchClassDeviceStruct
- xf86PostTouchEvent
Changes to the ABI:
- DeviceIntRec now contains a TouchClassPtr
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
These structs will be used to store touch-related data, events and
information.
Drivers must call InitTouchClassDeviceStruct to set up a multi-touch capable
device.
Touchpoints for the DDX and the DIX are handled separately - touchpoints
submitted by the driver/DDX will be stored in the DDXTouchPointInfoRec. Once
the touchpoints are processed by the DIX, new TouchPointInfoRecs are created
and stored. This process is already used for pointer events with the
last.valuators field.
Note that this patch does not actually add the generation of touch events,
only the required structs.
TouchListeners are (future) recipients of touch or emulated pointer events.
Each listener is in a state, depending which event they have already
received. The type of listener defines how the listener got to be one.
Co-authored-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
xf86PostTouchEvent is the driver API to submit touch events to the server.
This API doesn't do anything yet though but now we can at least bump the
API.
For valuators, drivers should use the existing xf86InitValuatorAxisStruct
function.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
This patch applies most of the protocol conversions and the internal event
type for ownership events.
Note that ownership events are generated by the DIX only, they do not pass
through the event queue.
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>
This allows us to run the server as a normal user whilst still
being able to use the -modulepath, -logfile and -config switches
We define a xf86PrivsElevated which will do the checks and cache
the result in case it is called more than once.
Also renamed the paths #defines to match their new meaning.
Original discussion which led to this patch can be found here:
http://lists.freedesktop.org/archives/xorg-devel/2011-September/025853.html
Signed-off-by: Antoine Martin <antoine@nagafix.co.uk>
Tested-by: Michal Suchanek <hramrach at centrum.cz>
Reviewed-by: Jamey Sharp <jamey at minilop.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
No-one can generated them yet, but if they could, we'd be processing them
like there was no tomorrow.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
The are the same as device events internally but require the touch ID
separately from the detail.button field (the protocol uses the detail field
for the touch id).
For simpler integration of pointer emulation we need to set the
detail.button field while keeping the touchid around.
Add the three new touch event types to the various places in the server
where they need to be handled. The actual handling of the events is somewhat
more complicated in most places.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
TOUCH_CLIENT_ID is set if the touch was generated from a client ID instead
of a DDX/driver touch ID. i.e. submitted by the dix.
TOUCH_END is a special flag that's required to force the touch to end.
Since the protocol with grab replaying and pointer emulation is rather
complex, it's quite hard to know otherwise when a touch sequence should
really die.
The others do what it says on the imaginary box.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Plus, use the actual definition from the protocol instead of the numeric
values. Turns out not everyone knows the protocol event IDs by heart.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
