There's no reason to do this as (nmasks + 2) callocs, and it's a
surprisingly hot path. Turns out you hit this ~once per passive grab,
and you do a few bajillion passive grab changes every time you enter or
leave the overview in gnome-shell. According to a callgrind of Xorg
with gnome-shell-perf-tool run against it:
Ir before: 721437275
Ir after: 454227086
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There's no reason not to, and it simplifies quite a few callers.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
It's already not optional at configure time, this just makes it so at
build time too.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
CreateCursor (Xlib call XCreatePixmapCursor) with a non-bitmap
source pixmap and a None mask is supposed to error out with BadMatch,
but didn't.
From der Mouse <mouse@Rodents-Montreal.ORG>, changed following
comments by Alan Coopersmith <alan.coopersmith@oracle.com>.
Signed-off-by: Thomas Klausner <wiz@NetBSD.org>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
if the grab type isn't XI2, grab->xi2mask is random. That random data may
have the enter/leave mask set, leading to events sent to the client that the
client can't handler.
Source of these errors:
_xgeWireToEvent: Unknown extension 131, this should never happen.
Simplest reproducer:
Start Xephyr, press button inside window, move out. As the pointer leaves
the Xephyr window, the errors appear.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
If we have a client which has registered for a DeviceButton grab
be sure to pass this to CheckDeviceGrabAndHintWindow(). Since the
order of clients is arbitrary there is no guarantee that the last
client in the list is the one that belongs to this class.
Signed-off-by: Egbert Eich <eich@freedesktop.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
XI 1.x only allows for first + num valuators, so if a device sends data for
valuators 0 and 2+ only (i.e. valuator 1 is missing) we still need to get
the data for that from somewhere.
XI 1.x uses the hack of an unset valuator mask to get the right coordinates,
i.e. we set the value but don't set the mask for it so XI2 events have the
right mask.
For an absolute device in relative mode, this broke in b28a1af55c, the
value was now always 0. This wasn't visible on the cursor, only in an XI 1.x
client. The GIMP e.g. sees jumps to x/0 every few events.
Drop the condition introduced in b28a1af55c, data in valuators is always
absolute, regardless of the mode.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
grab->type is only non-zero for passive grabs. We're checking an active grab
here, so we need to check if the touch mask is set on the grab.
Test case: grab the device, then start two simultaneous touches. The
grabbing client won't see the second touchpoints because grab->type is 0
and the second touch is not an emulating pointer.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
XQuartz already conditionally renames main() as dix_main() so it can provide
it's own main(). This isn't the ideal way of doing this, as it prevents libdix
built this way from being useful with any other DDX.
So instead, always name that function dix_main(), and also provide a stub main()
which just calls dix_main(), which can be overriden in the DDX.
Add a main() to XWin (XQuartz already has one, of course).
It's no longer neccessary to link XWin and XQuartz with libmain.
v2: Remove unneeded stub main hw/xwin/InitOutput.c
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
The peculiar way we handle coordinates results in relative coordinates on
absolute devices being added to the last value, then that value is mapped to
the screen (taking the device dimensions into account). From that mapped
value we get the final coordinates, both screen and device coordinates.
To avoid uneven scaling on relative coordinates, they are pre-scaled by
screen ratio:resolution:device ratio factor before being mapped. This
ensures that a circle drawn on the device is a circle on the screen.
Previously, we used the ratio to scale x up. Synaptics already does its own
scaling based on the resolution and that is done by scaling y down by the
ratio. So we can remove the code from the driver and get approximately the
same behaviour here.
Minor ABI bump, so we can remove this from synaptics.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Emmanuel Benisty <benisty.e@gmail.com>
A constant deceleration of x simply means (delta * 1/x). We limited that to
values >= 1.0f for obvious reasons, but can also allow values from 0-1.
That means that ConstantDeceleration is actually a ConstantAcceleration, but
hey, if someone needs it...
X.Org Bug 66134 <http://bugs.freedesktop.org/show_bug.cgi?id=66134>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Ungrabbing a device during an active touch grab rejects the grab. Ungrabbing
a device during an active pointer grab accepts the grab.
Rejection is not really an option for a pointer-emulated grab, if a client
has a button mask on the window it would get a ButtonPress emulated after
UngrabDevice. That is against the core grab behaviour.
X.Org Bug 66720 <http://bugs.freedesktop.org/show_bug.cgi?id=66720>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
This shouldn't have been in the patch
Reported-by: Colin Harrison <colin.harrison@virgin.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
defmin/defmax are screen coords and thus use a min-inclusive, max-exclusive
range. device axes ranges are inclusive, so bump the max up by one to get the
scaling right.
This fixes off-by-one coordinate errors if the coordinate matrix is used to
bind the device to a fraction of the screen. It introduces an off-by-one
scaling error in the device coordinate range, but since most devices have a
higher resolution than the screen (e.g. a Wacom I4 has 5080 dpi) the effect
of this should be limited.
This error manifests when we have numScreens > 1, as the scaling from
desktop size back to screen size drops one device unit.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
commit 61a99aff9d
dix: pre-scale relative events from abs devices to desktop ratio (#31636)
added pre-scaling of relative coordinates coming from absolute devices to
undo uneven scaling based on the screen dimensions.
Devices have their own device width/height ratio as well (in a specific
resolution) and this must be applied for relative devices as well to avoid
scaling of the relative events into the device's ratio.
e.g. a Wacom Intuos4 6x9 is in 16:10 format with equal horiz/vert
resolution (dpi). A movement by 1000/1000 coordinates is a perfect diagonal
on the tablet and must be reflected as such on the screen.
However, we map the relative device-coordinate events to absolute screen
coordinates based on the axis ranges. This results in an effective scaling
of 1000/(1000 * 1.6) and thus an uneven x/y axis movement - the y
axis is always faster.
So we need to pre-scale not only by the desktop dimenstions but also by the
device width/height ratio _and_ the resolution ratio.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Too many callers relied on the refcnt being handled correctly. Use a simple
wrapper to handle that case.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
ProcessTouchEvents() calls UDS for all touch events, but if the event type
was switched to TouchUpdate(pending end) UDS is a noop.
Daniel Drake found this can cause stuck buttons if a touch grab is
activated, rejected and the touch event is passed to a regular listener.
This sequence causes the TouchEnd to be changed to TouchUpdate(pending end).
The actual TouchEnd event is later generated by the server once it is passed
to the next listener. UDS is never called for this event, thus the button
remains logically down.
A previous patch suggested for UDS to handle TouchUpdate events [1], however
this would release the button when the first TouchEvent is processed, not
when the last grab has been released (as is the case for sync pointer
grabs). A client may thus have the grab on the device, receive a ButtonPress
but see the button logically up in an XQueryPointer request.
This patch adds a call to UDS to TouchEmitTouchEnd(). The device state must
be updated once a TouchEnd event was sent to the last grabbing listener and
the number of grabs on the touchpoint is 0.
[1] http://patchwork.freedesktop.org/patch/13464/
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The cursor is referenced during CopyGrab(), thus doesn't need to be handled
manually anymore. It does need to be refcounted for temp grabs though.
The oldGrab handling in ProcGrabPointer is a leftover from the cursor in the
grab being refcounted, but the grab itself being a static struct in the
DeviceIntRec. Now that all grabs are copied, this lead to a double-free of
the cursor (Reproduced in Thunderbird, dragging an email twice (or more
often) causes a crash).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A client may call XIGrabDevice twice, overwriting the existing grab. Thus,
make sure we free the old copy after we copied it. Free it last, to make
sure our refcounts don't run to 0 and inadvertantly free something on the
way.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
TouchListenerGone cleans up if a client disappears. Having this in
FreeGrab() triggers cyclic removal of grabs, emitting wrong events. In
particular, it would clean up a passive grab record while that grab is
active.
Move it to CloseDownClient() instead, cleaning up before we go.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Introduced in xorg-server-1.13.99.901-2-g9ad0fdb. Storing the grab pointer
in the listener turns out to be a bad idea. If the grab is not an active
grab or an implicit grab, the pointer stored is the one to the grab attached
on the window. This grab may be removed if the client calls UngrabButton or
similar while the touch is still active, leaving a dangling pointer.
To avoid this, copy the grab wherever we need to reference it later. This
is also what we do for pointer/keyboard grabs, where we copy the grab as
soon as it becomes active.
Reported-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Obsolete since 4bc2761ad5. This struct
existed so copying a passive grab could be simply done by
activeGrab = *grab
and thus have a copy of the GrabPtr we'd get from various sources but still
be able to check device->grab for NULL.
Since 4bc2761 activeGrab is a pointer itself and points to the same memory
as grabinfo->grab, leaving us with the potential of dangling pointers if
either calls FreeGrab() and doesn't reset the other one.
There is no reader of activeGrab anyway, so simply removing it is
sufficient.
Note: field is merely renamed to keep the ABI. Should be removed in the
future.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Change the single if condition in the loop body to a
if (!foo) continue;
and re-indent the rest.
No functional changes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A sync grab is the owner once it gets events. If it doesn't replay the
event it will get all events from this touch, equivalent to accepting it.
If the touch has ended before XAllowEvents() is called, we also now need to
send the TouchEnd event and clean-up since we won't see anything more from
this touch.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a device is frozen in results to a grab, we need to enqueue the events.
This makes things complicated, and hard to follow since touch events are now
replayed in the history, pushed into EnqueueEvent, then replayed later
during PlayReleasedEvents in response to an XAllowEvents.
While the device is frozen, no touch events are processed, so if there is a
touch client with ownership mask _below_ the grab this will delay the
delivery and potentially screw gesture recognition. However, this is the
behaviour we have already anyway if the top-most client is a sync pgrab or
there is a sync grab active on the device when the TouchBegin was generated.
(also note, such a client would only reliably work in case of ReplayPointer
anyway)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the device is currently grabbed as the result of a passive grab
activating, do not prepend that grab to the listeners (unlike active grabs).
Otherwise, a client with a passive pointer grab will prevent touch grabs
from activating higher up in the window stack.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If drivers supply incorrect values don't just quietly return False, spew to
the log so we can detect what's going on. All these cases are driver bugs
and should be fixed immediately.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
InitPointerClassDeviceStruct/InitKeyboardDeviceStruct allocate a
proximity/focus class, respectively. If a driver calls
InitFocusClassDeviceStruct or InitProximityClassDeviceStruct beforehand,
the previously allocated class is overwritten, leaking the memory.
Neither takes a parameter other than the device, so we can simply skip
initialising it if we already have one.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
==21860== 24 bytes in 1 blocks are still reachable in loss record 85 of 397
==21860== at 0x4C2B3F8: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==21860== by 0x61ED93: AllocateOutputBuffer (io.c:1037)
==21860== by 0x61E15A: WriteToClient (io.c:764)
==21860== by 0x457B30: ProcQueryExtension (extension.c:275)
==21860== by 0x43596B: Dispatch (dispatch.c:432)
==21860== by 0x425DAB: main (main.c:295)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
DeleteCallbackManager() introduced for better symmetry in the caller, they
do the same thing.
==20085== 24 bytes in 1 blocks are still reachable in loss record 11 of 103
==20085== at 0x4C2A4CD: malloc (vg_replace_malloc.c:236)
==20085== by 0x43A097: CreateCallbackList (dixutils.c:837)
==20085== by 0x43A1D3: AddCallback (dixutils.c:869)
==20085== by 0x4B1736: GEExtensionInit (geext.c:209)
==20085== by 0x41C8A8: InitExtensions (miinitext.c:389)
==20085== by 0x5AC918: main (main.c:208)
==2042== 8 bytes in 1 blocks are still reachable in loss record 2 of 97
==2042== at 0x4C2A4CD: malloc (vg_replace_malloc.c:236)
==2042== by 0x4C2A657: realloc (vg_replace_malloc.c:525)
==2042== by 0x4802F5: XNFrealloc (utils.c:1095)
==2042== by 0x43A17A: CreateCallbackList (dixutils.c:855)
==2042== by 0x43A1EF: AddCallback (dixutils.c:870)
==2042== by 0x4B1752: GEExtensionInit (geext.c:209)
==2042== by 0x41C8A8: InitExtensions (miinitext.c:389)
==2042== by 0x5AC9E4: main (main.c:208)
==2042==
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Heaps of these:
==2042== 15,360 bytes in 120 blocks are still reachable in loss record 94 of
97
==2042== at 0x4C2A4CD: malloc (vg_replace_malloc.c:236)
==2042== by 0x4C2A657: realloc (vg_replace_malloc.c:525)
==2042== by 0x45FB91: double_size (registry.c:65)
==2042== by 0x45FC97: RegisterRequestName (registry.c:85)
==2042== by 0x460095: RegisterExtensionNames (registry.c:179)
==2042== by 0x460729: dixResetRegistry (registry.c:334)
==2042== by 0x5AC992: main (main.c:201)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
==2547== 1 bytes in 1 blocks are still reachable in loss record 1 of 111
==2547== at 0x4C2A4CD: malloc (vg_replace_malloc.c:236)
==2547== by 0x64D1551: strdup (strdup.c:43)
==2547== by 0x4802FB: Xstrdup (utils.c:1113)
==2547== by 0x585B6C: XkbSetRulesUsed (xkbInit.c:219)
==2547== by 0x58700F: InitKeyboardDeviceStruct (xkbInit.c:595)
==2547== by 0x419FA3: vfbKeybdProc (InitInput.c:74)
==2547== by 0x425A3D: ActivateDevice (devices.c:540)
==2547== by 0x425F65: InitAndStartDevices (devices.c:713)
==2547== by 0x5ACA57: main (main.c:259)
and a few more of the above.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
I didn't think we needed this before, but after doing some more
work with reverse optimus it seems like it should be called.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
this allows the pixmap dirty helper to be used for reverse optimus,
where the GPU wants to copy from the shared pixmap to its VRAM copy.
[airlied: slave_dst is wrong name now but pointless ABI churn at this point]
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We should have no problem allowing output/offload from the same slave,
I asserted here, but in order to implement reverse optimus this makes
perfect sense. (reverse optimus is intel outputting to nvidia).
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
