Whenever the master changes, push the locked modifier state to the attached
slave devices, then update the indicators. This way, when NumLock or CapsLock
are hit on any device, the LED will light up on all devices. Likewise, a new
keyboard attached to a master device will light up with the correct
indicators.
The indicators are handled per-keyboard, depending on the layout, i.e. if one
keyboard has grp_led:num set, the NumLock LED won't light up on that keyboard.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
If there is a selection left over from a previous execution of the
main loop, and that selection has privates allocated for it, the X
server will crash. This is because dixResetPrivates() resets the
privates refcounts to zero without accounting for the reference held
by the selection object. When the selection is then deleted in
InitSelections() after the call to dixResetPrivates(), the refcount
for its privates type goes negative and bad things happen.
To fix this, we should delete any existing selections before calling
dixResetPrivates(). This will properly release the selection's
privates and avoid the crash.
A more thorough description of the problem and a test case to
reproduce the crash is available at a previous mail:
"Negative Selection devPrivates refcount?"
By Andrew Eikum to xorg-devel on 10 Dec 2013
http://lists.freedesktop.org/archives/xorg-devel/2013-December/039492.html
Signed-off-by: Andrew Eikum <aeikum@codeweavers.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
dispatch.c: In function 'SetVendorString':
dispatch.c:481:29: warning: declaration of 'string' shadows a global declaration [-Wshadow]
SetVendorString(const char *string)
^
dispatch.c:135:21: warning: shadowed declaration is here [-Wshadow]
typedef const char *string;
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
dev->button->down is a bitmask, not a normal array. Use the helper function to
check, we technically allow the mapping to change after the physical button
has been pressed (but not yet processed yet), so only check BUTTON_PROCESSED.
From XSetPointerMapping(3):
"If any of the buttons to be altered are logically in the down state,
XSetPointerMapping returns MappingBusy, and the mapping is not changed."
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
The server internally relies on arrays with a MAX_BUTTONS maximum size (which
is the max the core protocol can transport). Make sure a driver adheres to
that.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Fallout from fecc7eb1cf, and reverts most of the
rest of that patch.
The device name is allocated and may even change during PreInit. The const
warnings came from the test codes, the correct fix here is to fix the test
code.
touch.c: In function ‘touch_init’:
touch.c:254:14: warning: assignment discards ‘const’ qualifier from pointer target type [enabled by default]
dev.name = "test device";
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Introduced in fecc7eb1cf and reverts most of
that but it's helpfully mixed with other stuff.
InputAttributes are not const, they're strdup'd everywhere but the test code
and freed properly. Revert the const char changes and fix the test up instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Checked against randrproto.txt & randr.h
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
Flagged by cppcheck 1.62:
[dix/dixfonts.c:1792]: (error) Common realloc mistake:
'font_path_string' nulled but not freed upon failure
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
A client which is ready, but hasn't run for a while, should receive
the same benefit as one which has simply been idle for a while. Use
the smart_stop_tick to see how long it has been since a client has
run instead of smart_check_tick, which got reset each time a client
was ready, even if it didn't get to run.
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
This just removes the comment markers from around the formals in
several function prototypes near where pointer -> void * changes were
made. There are plenty more of these to fix.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
This lets us stop using the 'pointer' typedef in Xdefs.h as 'pointer'
is used throughout the X server for other things, and having duplicate
names generates compiler warnings.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Lots more const char stuff.
Remove duplicate defs of CoreKeyboardProc and CorePointerProc from
test/xi2/protocol-common.c
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
As usual, mostly const char changes. However, filter_device_events had
a potentially uninitialized value, 'raw', which I added a bunch of
checks for. I suspect most of those are 'can't happen', but it's hard
to see that inside the function.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
CheckPassiveGrabsOnWindow() calls AllocGrab() which can fail and return NULL.
This return value is not checked, and can cause NULL pointer dereferences.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
GrabDevice() calls AllocGrab() which can fail and return NULL.
This return value is not checked, and can cause NULL pointer dereferences.
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
If either the initial calloc or the xi2mask_new fails, grab is NULL,
but if a src grab is passed in, it was always being written to by
CopyGrab (and if that failed, dereferenced again in teardown).
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Since we're using RedirectAutomatic to do this, we don't actually
preserve contents when unmapped.
v2: Don't say WhenMapped if Composite didn't initialize [vsyrjala]
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
A default timeslice of 20ms means a pathological client can ruin up to
two frames per scheduler tick. And a fifth of a second is just insane.
Pick two different numbers out of the hat. A 5ms slice means you can
probably keep up with two or three abusive clients, and letting it burst
to 15ms should give you about all the timeslice you need for a
fullscreen game (that's doing server-side rendering for some reason).
If you're running on a system with a 10ms granularity on SIGALRM, then
this effectively changes the intervals to 10ms and 30ms. Which is still
better, just not as better.
I suspect this is about as good as we can do without actually going
preemptive, which is an entire other nightmare.
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
This allocates a new region structure and copies a source region into
it in a single API rather than forcing the caller to do both steps themselves.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The time between the idle reset and the IdleTimeWakeupHandler to be called is
indeterminate. Clients with an PositiveTransition or NegativeTransition alarm
on a low threshold may miss an alarm.
Work around this by keeping a reset flag for each device. When the
WakeupHandler triggers and the reset flag is set, we force a re-calculation of
everything and pretend the current idle time is zero. Immediately after is the
next calculation with the real idle time.
Relatively reproducible test case: Set up a XSyncNegativeTransition alarm for
a threshold of 1 ms. May trigger, may not.
X.Org Bug 70476 <http://bugs.freedesktop.org/show_bug.cgi?id=70476>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
And now that we have the accessors, localize it. No functional changes, just
preparing for a future change.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Save a pointer to the passed in closure structure before copying it
and overwriting the *c pointer to point to our copy instead of the
original. If we hit an error, once we free(c), reset c to point to
the original structure before jumping to the cleanup code that
references *c.
Since one of the errors being checked for is whether the server was
able to malloc(c->nChars * itemSize), the client can potentially pass
a number of characters chosen to cause the malloc to fail and the
error path to be taken, resulting in the read from freed memory.
Since the memory is accessed almost immediately afterwards, and the
X server is mostly single threaded, the odds of the free memory having
invalid contents are low with most malloc implementations when not using
memory debugging features, but some allocators will definitely overwrite
the memory there, leading to a likely crash.
Reported-by: Pedro Ribeiro <pedrib@gmail.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Use the grabtype to determine which type of event to send - all other events
are pointless and may result in erroneous events being delivered.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For an active grab, grab->eventMask can be either the core or the XI1 mask.
With the overlap of event filters, calling DeliverOneGrabbedEvent(XI1) for a
ProximityOut event will trigger if the client has selected for enter events -
the filter is the same for both.
Thus, we end up delivering a proximity event to a client not expecting one.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a client calls XAllowEvents(SyncPointer) it expects events as normal until
the next button press or release event - that freezes the device. An e.g.
proximity event must thus not freeze the pointer.
As per the spec, only button and key events may do so, so narrow it to these
cases.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>