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>
Now that events are read at normal process time, we can use malloc to
grow the event queue instead of discarding events.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The current SIGIO signal handler method, used at generation of input events,
has a bunch of oddities. This patch introduces an alternative way using a
thread, which is used to select() all input device file descriptors.
A mutex was used to control the access to input structures by the main and input
threads. Two pipes to emit alert events (such hotplug ones) and guarantee the
proper communication between them was also used.
Co-authored-by: Fernando Carrijo <fcarrijo@freedesktop.org>
Signed-off-by: Tiago Vignatti <tiago.vignatti@nokia.com>
v2: Fix non-Xorg link. Enable where supported by default.
This also splits out the actual enabling of input threads to
DDX-specific patches which follow
v3: Make the input lock recursive
v4: Use regular RECURSIVE_MUTEXes instead of rolling our own
Respect the --disable-input-thread configuration option by
providing stubs that expose the same API/ABI.
Respond to style comments from Peter Hutterer.
v5: use __func__ in inputthread debug and error mesages.
Respond to style comments from Peter Hutterer.
v6: use AX_PTHREAD instead of inlining pthread tests.
Suggested by Emil Velikov <emil.l.velikov@gmail.com>
v7: Use pthread_sigmask instead of sigprocmask when using threads
Suggested by Adam Jackson <ajax@redhat.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This makes the code more consistent with other versions of
out-of-queue event processing
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
When this code was called from SIGIO, saving and restoring errno could
possibly have made sense in some strange environment. Now that this
will not be called from a signal handler, there is no reason to do that.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
We won't need these locks with the new threaded input code as it holds
the input lock across all of the input device I/O operations.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This removes all of the SIGIO handling support used for input
throughout the X server, preparing the way for using threads for input
handling instead.
Places calling OsBlockSIGIO and OsReleaseSIGIO are marked with calls
to stub functions input_lock/input_unlock so that we don't lose this
information.
xfree86 SIGIO support is reworked to use internal versions of
OsBlockSIGIO and OsReleaseSIGIO.
v2: Don't change locking order (Peter Hutterer)
v3: Comment weird && FALSE in xf86Helper.c
Leave errno save/restore in xf86ReadInput
Squash with stub adding patch (Peter Hutterer)
v4: Leave UseSIGIO config parameter so that
existing config files don't break (Peter Hutterer)
v5: Split a couple of independent patch bits out
of kinput.c (Peter Hutterer)
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
kdrive uses the NotifyFd interface, which handles all of the necessary
fd configuration in the OS layer. Having it also use the old
EnableDevice interfaces is incorrect.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Not all display managers make it easy (or possible) to modify the
command line flags passed to the server, so add a way to get to it from
xorg.conf.
v2: Fix the FlagOptions list to not have IGLX after the terminator (Alan
Coopersmith)
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
A1 and A8 pixmaps are usually stored in the Red channel to conform
with more recent GL versions. When using these pixmaps as mask values,
that works great. When using these pixmaps as source values, then the
value we want depends on what the destination looks like.
For RGBA or RGB destinations, then we want to use the Red channel
for A values and leave RGB all set to zero.
For A destinations, then we want to leave the R values in the Red
channel so that they end up in the Red channel of the output.
This patch adds a helper function, glamor_bind_texture, which performs
the glBindTexture call along with setting the swizzle parameter
correctly for the Red channel. The swizzle parameter for the Alpha
channel doesn't depend on the destination as it's safe to leave it
always swizzled from the Red channel.
This fixes incorrect rendering in firefox for this page:
https://gfycat.com/HoarseCheapAmericankestrel
while not breaking rendering for this page:
https://feedly.com
v2: Add change accidentally left in patch for missing
glDisable(GL_COLOR_LOGIC_OP).
Found by Emil Velikov <emil.l.velikov@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63397
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
glamor_make_current is supposed to be called before any GL APIs.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
If the logic op gets left enabled, it overrides the blending
operation, causing incorrect contents on the display.
v2: Disable only on non-ES2, but disable even for PictOpSrc
v3: Found another place this is needed in
glamor_composite_set_shader_blend
v4: Remove change dependent on new glamor_set_composite_texture
API. This belongs in a different patch.
Found by Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
This makes the cursor pointer held by xf86Cursors.c get reset to NULL
whenever the cursor isn't displayed, and means that the reference
count held in xf86Cursor.c is sufficient to cover the reference in
xf86Cursors.c.
As HideCursor may be called in the cursor loading path after
UseHWCursor or UseHWCursorARGB when HARDWARE_CURSOR_UPDATE_UNHIDDEN
isn't set in the Flags field, the setting of the cursor pointer had to
be moved to the LoadCursor paths.
LoadCursorARGBCheck gets the cursor pointer, but LoadCursorImageCheck
does not. For LoadCursorImageCheck, I added a new function,
xf86CurrentCursor, which returns the current cursor. With this new
function, we can eliminate the cursor pointer from the
xf86CrtcConfigRec, once drivers are converted over to use it.
Signed-off-by: Keith Packard <keithp@keithp.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Increases x11perf -compwinwin500 numbers by a factor of 10 for me with
radeonsi.
Conditions copied from exaComposite().
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
RENDER requires that sampling outside of any source/mask picture results
in alpha == 0.0.
The OpenGL border colour cannot set alpha = 0.0 if the texture format
doesn't have an alpha channel, so we have to use the RepeatFix handling
in that case.
Also, only force alpha = 1.0 when sampling inside of RGBx source/mask
pictures.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94514
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This moves the definition of miPointerRec from mipointrst.h to
mipointer.c so that it is no longer visible in the API, allowing it to
be changed while the API/ABI is frozen.
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
This creates a function that invalidates the current sprite and forces
a sprite image reload the next time the sprite is checked, moving that
logic out of the xwayland sources and allowing the miPointerRec
structure to be removed from the server API.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
In the case where there's no damage monitor on the drawable, we look
that fact up twice: once before rendering to decide whether to compute
damage, and again after to decide whether to append it. This is wasted
effort, as the layer below us is effectively not allowed to change
whether there's a damage monitor for the drawable, but there's no way
the compiler can know that.
Instead, look it up once up front, and change the check macros and
damageRegionProcessPending to take a damage not a drawable.
v2: Explicitly pass pDamage to the macros as well (Michel Dänzer)
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
This changes XInput 2's propagation of NotifyPointer focus out events to
include the pointer window as well, similar to core events. This fixes
a potential permanent focus in GDK when the focus moves to PointerRoot.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=93539
Signed-off-by: Andrew Comminos <andrew@comminos.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If data is received during XWayland startup, it will be read early in
InitInput() before the connection data is initialized, causing a crash.
Remove the wayland rountrips from InitInput() as this is done again in
xwl_screen_init() where it seems more appropriate.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95337
Reviewed-by: Adam Jackson <ajax@redhat.com>
This is only meaningful for indirect contexts, and all it does is
(maybe) prevent a flush when switching away from an indirect context.
Indirect contexts aren't worth optimizing for, and Mesa tracks whether
a flush is needed anyway.
Careful readers will note that ReadPixels would reset the flag even
though it doesn't imply a flush!
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
No functional change, just rearranging some code to make later commits
more obvious.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Fix build without --enable-glamor.
Caught by the arm tinderbox.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
Tested-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The destination variable is never freed, thus we even plug some memory
leaks.
v2: Rebase against updated xf86CheckPrivs() helper.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Current message was quite off "file specified must be a relative path"
and alike. Just factor it out and use "path/file" as needed.
v2: Rework error message, drop "Using default", print actual arg value.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
This moves the capabilites setting to after glamor is initialised, and
enables the offload caps in cases where they work. This enables DRI2
PRIME support with modesetting.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Slave GPUs don't have a root window to set this on, so don't.
This fixes some crashes I saw just playing around.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Otherwise ms_ent_priv will return NULL and things will fall apart.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
For some reason a couple of the dirty functions in driver.c used 8
spaces per tab instead of 4 like the rest of the file. Fix this to make
it more consistent and give me more room to work in ms_dirty_update in
subsequent commits.
v1: N/A
v2: N/A
v3: N/A
v4: Initial commit
Signed-off-by: Alex Goins <agoins@nvidia.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This was added in:
commit 312910b4e3
Author: Chase Douglas <chase.douglas@canonical.com>
Date: Wed Apr 18 11:15:40 2012 -0700
Update currentTime in dispatch loop
Unfortunately this is equivalent to calling GetTimeInMillis() once per
request. In the absolute best case (as on Linux) you're only hitting the
vDSO; on other platforms that's a syscall. Either way it puts a pretty
hard ceiling on request throughput.
Instead, push the call down to the requests that need it; basically,
grab processing and event generation.
Cc: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
When NumLock is on and a new keymap is applied, the next modifier state
change will turn off that LED (but leave the state enabled). The cause
for this is a bit convoluted:
* the SLI explicitState is copied from the current state in
ProcXkbGetKbdByName. Thus, if NumLock is on, that state is 0x2.
* on the next modifier key press (e.g. Shift), XkbApplyState() calls into
XkbUpdateIndicators() -> XkbUpdateLedAutoState() to update SLIs (if any)
for the currently changed modifier. But it does so with a mask only for
the changed modifier (i.e. for Shift).
* XkbUpdateLedAutoState() calculates the state based on this mask and
ends up with 0 because we don't have a Shift LED and we masked out the
others.
* XkbUpdateLedAutoState() compares that state with the previous state
(which is still 0x2) and then proceeds to turn the LED off
This doesn't happen in the normal case because either the mask
encompasses all modifiers or the state matches of the masked-out
modifiers matches the old state.
Avoid this issue by forcing an SLI update after changing the keymap.
This updates the sli->effectiveState and thus restores everything to
happy working order.
https://bugzilla.redhat.com/show_bug.cgi?id=1047151
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
