GetTouchEvents is usually called in a signal context.
Calling ErrorF for the error messages leads to X complaining about log:
(EE) BUG: triggered 'if (inSignalContext)'
(EE) BUG: log.c:484 in LogVMessageVerb()
(EE) Warning: attempting to log data in a signal unsafe manner while in signal context.
Please update to check inSignalContext and/or use LogMessageVerbSigSafe() or ErrorFSigSafe().
The offending log format message is:
%s: Attempted to start touch without x/y (driver bug)
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The changes to miPointerSetPosition interface from int->double breaks
the SIS driver build, so time to bump this.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
DGA only handles master devices but it does intercept slave device events as
well (since the event handlers are per event type, not per device).
The DGA code must thus call into UpdateDeviceState to reset the button/key
state on the slave device before it discards the remainder of the event.
Test case:
- Passive GrabModeSync on VCP
- Press button
- Enable DGA after ButtonPress
- AllowEvents(SyncPointer)
- Release button
The button release is handled by DGAProcessPointerEvent but the device state
is never updated, so the slave ends up with the button permanently down.
And since the master's button state is the union of the slave states, the
master has the button permanently down.
X.Org Bug 59100 <http://bugs.freedesktop.org/show_bug.cgi?id=59100>
Reported-by: Steven Elliott <selliott4@austin.rr.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reported-by: Steven Elliott <selliott4@austin.rr.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
If a XI2.1+ client has a grab on a non-root window, it must still receive
raw events on the root window.
Test case: register for XI_ButtonPress on window and XI_RawMotion on root.
No raw events are received once the press activates an implicit grab on the
window.
X.Org Bug 53897 <http://bugs.freedesktop.org/show_bug.cgi?id=53897>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
The base group is not brought into range and, therefore, using it as an array
index crashed the X server. Also, at this place, we should ignore locked
groups, but not latched groups. Therefore, use sum of base and latched groups,
brought into range.
Reproducible with:
key <FK07> {
type= "ONE_LEVEL",
symbols[Group1]= [ NoSymbol ],
actions[Group1]= [ LatchGroup(group=-1, clearLocks) ]
};
And hitting F7 will exceed the group level and access arbitrary memory.
Signed-off-by: Andreas Wettstein <wettstein509@solnet.ch>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The loop above the previous call may end up triggering other
handlers attaching to the same function slot, so unwrapping
the handler after that could leave the just attached handler
in a dangling but not unset state.
This issue was most visible on the XO, where destroying a
window with an animated cursor set and running would trigger
this inconsistent state, never calling the miSpriteBlockHandler
again after the animated cursor is unset.
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>
Different miPointerSpriteFuncRec implementations do a varying
business at ultimately calling miPointerUpdateSprite(), this
particularly fails when using the plain mi sprite on touch events,
where the sprite is just moved/updated on cursor changes.
So, ensure miPointerUpdateSprite() is called generically for
pointer emulating touch events as with regular motion events.
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>
protocol-xiwarppointer.c: In function ‘ScreenSetCursorPosition’:
protocol-xiwarppointer.c:71:53: warning: declaration of ‘screen’ shadows a
global declaration [-Wshadow]
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Conflicts:
Xi/xichangehierarchy.c
Small conflict with the patch from
Xi: don't use devices after removing them
Was easily resolved by hand.
Signed-off-by: Keith Packard <keithp@keithp.com>
d785368e0e converted the other miinitext functions to use ARRAY_SIZE,
and removed the sentinel, but missed EnableDisableExtensionError so
passing an invalid extension name could cause the server to walk off
the end off the list looking for a sentinel that wasn't there.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Mountain Lion only supports 32bit backing stores, so don't use 15bit visuals until libXplugin adapts
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Fixes this compile break that showed up on arm recently:
dmxinit.c:746:26: error: 'glxSupported' undeclared (first use in this function)
dmxinit.c:746:26: note: each undeclared identifier is reported only once for each function it appears in
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
The AC_C_TYPEOF adds a #undef typeof to its autogenerated config.h.in
template, but b8ab93dfbc didn't copy that to dix-config.h.in
when HAVE_TYPEOF was, so the macro could claim typeof support but not
make it work, when used with compilers like Solaris Studio 12.1 which
only recognize it as __typeof__.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
GrabMask is a union of core, XI1 and XI2 masks. If a XI2 grab is activated,
the value is a random pointer value, using it as mask has unpredictable
effects.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
If a client has a core grab, don't allow re-grabbing with type XI2, etc.
This was the intent of the original commit
xorg-server-1.5.99.1-782-g09f9a86, but ineffective.
X.Org Bug 58255 <http://bugs.freedesktop.org/show_bug.cgi?id=58255>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
When a client shuts down and resources are being freed, the window may have
been freed already, so accessing it to get the window ID is bad. Plus, we
never care about the window anyway other than for stuffing it into the
event.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
RemoveDevice() frees the DeviceIntPtr, we shouldn't use the pointer after
that
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Running glxinfo under indirect rendering would randomly fail against the
intel driver, as it would create a context with no attribs, and then the
api value would be passed to the driver uninitialised.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Protocol events don't contain pointers, so it's easier to copy everything
over, then swap in-place.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
Avoid name shadowing warnings, change the event list to a more specific
name.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
If the grab_window is the barrier window and the client owns the grab,
deliver as normal grabbed event (respecting owner_events). Otherwise,
deliver as usual.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
Only deliver to the client that created the barrier, not to other clients.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
x/y for barrier events should contain the actual pointer position.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
Instead of having the pointer barrier code enqueue events separately from
GetPointerEvents, pass the event list through and let it add to it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
This allows clients to add barriers that extend to the edge of the
screen. Clients are encouraged to use these instead of precise coordinates
in these cases to help prevent pointer leaks.
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Since barriers are axis-aligned, we can do the intersection test with
simple interpolation rather than line-segment intersection. This also
helps us out in the future when we want the barriers to extend to be
rays and lines rather than just segments.
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This ensures that we always complete an event sequence.
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Rename a variable. This is to make the diff in the next commit cleaner.
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Additionally, add flags when the pointer is released.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
We eventually want to send a new notify event on hitbox leave,
which signifies the dawn of a new barrier event ID, so it's
convenient if we can put the code here.
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
Pointers (and the hands that drive them) aren't very precise, and the
slightest amount of nudging to either side might be enough to reset
the event ID, making clients think they have an entirely new hit. Allow
for a slightly bigger "hit box" before these barriers get reset.
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
