A single provider can be both a offload and source slave at the same time,
the use of seperate lists breaks in this case e.g. :
xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x7b cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 3 outputs: 2 associated providers: 0 name:modesetting
Provider 1: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 2 outputs: 5 associated providers: 0 name:modesetting
xrandr --setprovideroutputsource 1 0x7b
xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x7b cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 3 outputs: 2 associated providers: 1 name:modesetting
Provider 1: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 2 outputs: 5 associated providers: 1 name:modesetting
xrandr --setprovideroffloadsink 1 0x7b
xrandr --listproviders
Providers: number : 3
Provider 0: id: 0x7b cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 3 outputs: 2 associated providers: 2 name:modesetting
Provider 1: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 2 outputs: 5 associated providers: 2 name:modesetting
Provider 2: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 2 outputs: 5 associated providers: 2 name:modesetting
Not good. The problem is that the provider with id 0x46 now is on both
the output_slave_list and the offload_slave_list of the master screen.
This commit fixes this by unifying all 3 lists into a single slaves list.
Note that this does change the struct _Screen definition, so this is an ABI
break. I do not expect any of the drivers to actually use the removed / changed
fields so a recompile should suffice.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
The flip queue currently only holds events submitted to the driver for
flipping, awaiting the completion notifier. It is short. We therefore
can speed up interrupt processing by keeping the small number of events
ready to be flipped on the end of the flip queue. By appending the
events to the flip_queue in the order that they become ready, we also
resolve one issue causing Present to display frames out of order.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-and-tested-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
With large numbers of queued vblank, the list iteration on every
interupt dominates processing time. If we reorder the list to be in
ascending event order, then not only is also likely to be in order for
notification queries (i.e. the notification will be near the start of
the list), we can also stop iterating when past the target event_id.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-and-tested-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Fixes freedesktop.org bug https://bugs.freedesktop.org/show_bug.cgi?id=67484
If t->bottom is close to MIN_INT, removing top can wraparound, so do the check properly.
A similar fix should also be applied to pixman.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Nice of FreePicture to take a void * instead of a PicturPtr so that
this error wasn't caught by the compiler.
Noticed when resetting the X server left a dangling pixmap around.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
On cursor unrealize, the associated pixmap is destroyed, make sure we
clear the pointer from the private resource and check for the value
being non-null when setting or destroying the cursor.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96246
RRScreenSizeNotify() will update the connection information block, but
if this occurs during initialization before ConnectionInfo is even
initialized, this will lead to a crash.
Simply check for ConnectionInfo prior to update it to avoid the crash.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95337
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
This partially revert commit 984be78
The rountrip in Xwayland's InitInput() is unlikely the culprit for the
crash reported in bug 95337, even though it's triggered from
InitInput().
Startup goes like this:
xwl_screen_init()
xwl_output_create()
wl_display_roundtrip()
InitInput()
wl_display_roundtrip()
ConnectionInfo initialized
What happens in bug 95337 is that some output data is already available
when we reach InitInput()'s wl_display_roundtrip() and therefore we end
up trying to update the ConnectionInfo's data from RR routines before
ConnectionInfo is actually initialized.
Removing the wl_display_roundtrip() from InitInput() will not fix the
issue (although it would make it less lileky to happen), because
xwl_screen_init() also does a wl_display_roundtrip() after creating the
output, so the race that led to bug 95337 remains.
However, re-setting the xwl_screen->expecting_event to 0 again in
InitInput() still doesn't seem right. so this part is not restored
(thus a partial revert).
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95337
There are no in-tree consumers of the audit hooks, and they are in any
case redundant with the dtrace dispatch hooks. Neither is there any
in-tree user of the core request dispatch hook. The extension hook is
only used for non-default security cases, but in the absence of LTO we
always have to take the function call into XaceHookDispatch to find out
that there's no callback registered.
Cc: Eamon Walsh <ewalsh@tycho.nsa.gov>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
As documented in xorg.conf(5), a value of ConstantDeceleration between 0
and 1 will speed up the pointer. However, values less than 1 actually
had no effect. Fix this.
Note that this bug only affected "ConstantDeceleration" as configured
through xorg.conf, not "Device Accel Constant Deceleration" as configured
through xinput. The property handler AccelSetDecelProperty() also did
not need to be changed, as it did not limit the values of the property.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=92766
Signed-off-by: Eric Biggers <ebiggers3@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We want to notice that it's set, but still pass it through to dix.
Return 0 to indicate this.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Can't find any reference of pointer_limbo_window in the code, let's
remove it.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
A new --with-fallback-input-driver=foo option allows selecting a
fallback driver for the server if the driver configured for the device
is not found. Note that this only applies when the device has a driver
assigned and that module fails to load, devices without a driver are
ignored as usual.
This avoids the situation where a configuration assigns e.g. the
synaptics driver but that driver is not available on the system,
resulting in a dead device. A fallback driver can at least provides some
functionality.
This becomes more important as we move towards making other driver true
leaf nodes that can be installed/uninstalled as requested. Specifically,
wacom and synaptics, a config that assigns either driver should be
viable even when the driver itself is not (yet) installed on the system.
It is up to the distributions to make sure that the fallback driver is
always installed. The fallback driver can be disabled with
--without-fallback-input-driver and is disabled by default on non-Linux
systems because we don't have generic drivers on those platforms.
Default driver on Linux is libinput, evdev is the only other serious
candidate here.
Sample log output:
[ 3274.421] (II) config/udev: Adding input device SynPS/2 Synaptics TouchPad (/dev/input/event4)
[ 3274.421] (**) SynPS/2 Synaptics TouchPad: Applying InputClass "touchpad weird driver"
[ 3274.421] (II) LoadModule: "banana"
[ 3274.422] (WW) Warning, couldn't open module banana
[ 3274.422] (II) UnloadModule: "banana"
[ 3274.422] (II) Unloading banana
[ 3274.422] (EE) Failed to load module "banana" (module does not exist, 0)
[ 3274.422] (EE) No input driver matching `banana'
[ 3274.422] (II) Falling back to input driver `libinput'
.. server proceeds to assign libinput, init the device, world peace and rainbows
everywhere, truly what a sight. Shame about the banana though.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is an ABI break, in that we now pass NULL to a function that hasn't
accepted it before.
Alex Goins had a different patch for this but it wasn't symmetrical, it
freed something in a very different place than it allocated it, this
attempts to retain symmetry in the releasing of the backing bo.
v2: use a new toplevel API, though it still passes NULL to something
that wasn't expecting it.
v3: pass -1 instead of 0.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Alex Goins <agoins at nvidia.com>
Not visible in the patch, but the same stanza is repeated below inside
the #ifdef GLXEXT. There's no reason to bother with checking it if we
built without GLXEXT so remove the unconditional one.
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Current Mesa Git master checks that the EGL display actually supports
the API passed to eglBindAPI, which can only succeed after
eglInitialize.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Current Mesa Git master checks that the EGL display actually supports
the API passed to eglBindAPI, which can only succeed after
eglInitialize.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96344
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
The doc text is wrong at this point, input processing isn't going to
vary based on this, so we shouldn't say it does. The only thing this
_does_ get used for is DRI1 SwapBuffers (on everything but savage), and
if you disable it you're not going to get DRI1 at all, so we really
shouldn't even mention it.
Still, leave the option wired up to the parser so we don't break any
DRI1-driver-using setup relying on it being disabled, and so we don't
complain about unused options elsewhere.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Acked-by: Keith Packard <keithp@keithp.com>
This code was broken anyway. Note that DEVICE_OFF would make dmx think
_no_ devices were using SIGIO anymore, which means 'xinput disable' on
your mouse would probably do weird things to your keyboard too. Rather
than try to repair that and keep SIGIO working on this one niche DDX,
just rip it out and use the thread model like everyone else.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Acked-by: Keith Packard <keithp@keithp.com>
As the man page for the latter states:
The effects of signal() in a multithreaded process are unspecified.
We already have an interface to call sigaction() instead, use it.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Timer processing can happen on either the main thread or the input
thread. As a result, it must be done under the input lock.
Signals are unrelated to timers now that SIGIO isn't used for input
processing, so stop blocking signals while processing timers.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Read and dispatch pending Wayland events to make sure we do not miss a
possible reply from the compositor prior to discard a key repeat.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Key repeat is handled by the X server, but input events need to be
processed and forwarded by the Wayland compositor first.
Make sure the Wayland compositor is actually processing events, to
avoid repeating keys in Xwayland while the Wayland compositor cannot
deal with input events for whatever reason, thus not dispatching key
release events, leading to repeated keys while the user has already
released the key.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=762618
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The xserver generates the key repeat by itself.
But when used with another server processing inputs first (e.g. a
Wayland compositor), the other server may be busy dealing with some
other things and not queue up key release events in time.
Add a vfunc in XkbSrvInfo to possibly add a check before re-emitting a
keypress event in the AccessX timer handler, so that the key repeat has
a chance to be denied if the server processing the input is not ready.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
In patch 137ac094e7, Adam moved an
expensive call to UpdateCurrentTime out of the main dispatch
loop. That's a good change as the original fix from Chase was a bit
expensive. However, it breaks grab processing and so a couple of the
calls to UpdateCurrenTime need to be removed.
Input event processing can generate a stream of events; a button press
that activates a grab will send a press followed by a sequence of
enter/leave events. All of these should have the same time stamp on
the wire as they occur at the 'same' time.
More importantly, the grab time recorded in the device is pulled from
currentTime after all of the events are delivered, so if currentTime
doesn't match the time in the device event, then future grab
modifications will fail as the time marked in the device will be
'later' than the grab time known to the client (which is defined as
the timestamp from the activating input event).
A bit of history here -- it used to be that currentTime was driven
*entirely* by input events; those timestamps didn't even have to be
related to the system time in any way. Then we started doing ICCCM
stuff and people got confused when PropertyNotify events would have
the same timestamp even when delivered minutes apart because no input
events were delivered.
We added code in the server to go update the time, but only if no
input events were pending (so that the clock "wouldn't" go
backwards). The only places where this is necessary is in request
processing which may generate an event with a timestamp, and there
only at the very top of the request processing code so that the whole
request would be processed at the 'same time', just like events.
cc: Chase Douglas <chase.douglas@canonical.com>
cc: Peter Hutterer <peter.hutterer@who-t.net>
cc: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
If the server calls AbortServer during the first-time initialization
(which can happen if you start the server on an already using
DISPLAY), then the dbus code will shut down and call the notify fd
interface. If the notify fd list hasn't been initialized, the server
will crash.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The list of input devices may be changed by hotplugging while the
server is active, and those changes may come from either the main
thread or the input thread. That means the list of input devices needs
to be protected by a mutex.
This prevents input drivers from receiving I/O ready callbacks after
removing a device.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
By default the X server will try CLOCK_MONOTONIC_COARSE before
CLOCK_MONOTONIC, while A Wayland compositor may only support getting
their timestamps from the CLOCK_MONOTONIC clock. This causes various
issues since it may happen that a timestamp from CLOCK_MONOTONIC
retrieved before a sending an X request will still be "later" than the
timestamp the X server than gets after receiving the request, due to the
fact that CLOCK_MONOTONIC_COARSE has a lower resolution.
To avoid these issues, make Xwayland always use CLOCK_MONOTONIC, so
that it becomes possible for Wayland compositor only supporting
CLOCK_MONOTONIC and X server to use the same clock.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No longer needed now that xf86CursorResetCursor is getting called for
each CRTC configuration change.
v2: Keep xf86_reload_cursors as a deprecated empty inline function
until all drivers stop calling it. (Adam Jackson)
Reviewed-by: Adam Jackson <ajax@redhat.com>
Commit b64108fa ("glamor: Check for composite operations which are
equivalent to copies") failed to copy conditions from exaComposite which
ensure that the composite operation doesn't access outside of the source
picture.
This fixes rendercheck regressions from the commit above.
Reviewed-by: Keith Packard <keithp@keithp.com>
Fixes a crash on startup in the radeon driver's drmmode_show_cursor()
due to xf86_config->cursor == NULL, because no CRTC was enabled yet, so
xf86_crtc_load_cursor_image was never called.
(Also use scrn->pScreen instead of xf86ScrnToScreen(scrn))
v2: Set xf86_config->cursor at the beginning of xf86_load_cursor_image
instead of at the end.
Reviewed-by: Keith Packard <keithp@keithp.com>
Threaded input doesn't use SIGIO anymore, but existing drivers using
xf86BlockSIGIO and xf86ReleaseSIGIO probably want to lock the input
mutex during those operations. Provide inline functions to do this
which are marked as 'deprecated' so that drivers will get warnings
until they are changed.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
These are local to inputthread.c; the ones in globals.c aren't
declared in any header file.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
input_force_unlock was mis-using input_mutex_lock and leaving it set
to -1. As this is executed from OsInit at each server generation, on
the second time through, the mutex would be left locked (!) due to the
trylock call. This caused input to fail after the first server reset.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Oops. This didn't get removed when xfree86 was converted over to use
the input thread.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Threaded input requires AX_PTHREAD, which is provided by this file.
Signed-off-by: Keith Packard <keithp@keithp.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
threaded input can affect drivers that use OsBlockSIGIO when dealing
with cursors.
Signed-off-by: Keith Packard <keithp@keithp.com>
Requested-by: Peter Hutterer <peter.hutterer@who-t.net>
Threaded input allows the input code to call malloc while processing
events. In this case, that's in the middle of processing touch events
and needing to resize the touch buffer.
This test was expecting the old behaviour where touch points would get
dropped if the buffer was full. The fix is to check for the new
behaviour instead.
[v2]
* make sure two finding two equivalent touches return the same touch
object
* check to make sure the queue resizes by the expected amount
Changes provided by Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Patch b64108fa30 added a short cut that
identifies composite operations that can be performed with a simple
copy instead.
glamor_copy works in absolute coordinates, so the dx and dy values
passed in need to be converted from drawable-relative to absolute by
adding the drawable x/y values.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This matches a change made in xcb and improves performance for a small
increase in memory usage.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Use this instead of the (now deprecated) cursor pointer in the
xf86CrtcConfigRec.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Switch the XFree86 DDX over to threaded input
v2: Rewrite comment in xf86Helper about silken mouse
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Now that input is threaded, malloc can be used at event time to resize
the touchpoint buffer as needed.x
v2: Remove "Need to grow the queue means dropping events."
from comment as it no longer applies. (Peter Hutterer)
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
