Signed-off-by: Adam Jackson <ajax@redhat.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Tested-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Eric Anholt <eric@anholt.net>
Sometimes, Xwayland will try to use a cursor that has just been freed,
leading to a crash when trying to access that cursor data either in
miPointerUpdateSprite() or AnimCurTimerNotify().
CheckMotion() updates the pointer's cursor based on which xwindow
XYToWindow() returns, and Xwayland implements its own xwl_xy_to_window()
to fake a crossing to the root window when the pointer has left the
Wayland surface but is still within the xwindow.
But after an xwindow is unrealized, the last xwindow used to match the
xwindows is cleared so two consecutive calls to xwl_xy_to_window() may
not return the same xwindow.
To avoid this issue, update the last_xwindow based on enter and leave
notifications instead of xwl_xy_to_window(), and check if the xwindow
found by the regular miXYToWindow() is a child of the known last
xwindow, so that multiple consecutive calls to xwl_xy_to_window()
return the same xwindow, being either the one found by miXYToWindow()
or the root window.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1385258
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Vít Ondruch <vondruch@redhat.com>
Tested-by: Satish Balay <balay@fastmail.fm>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
In glamor_init(), if the minimum requirements are not met, glamor may
fail after setting up its own CloseScreen() and DestroyPixmap()
routines, leading to a crash when either of the two routines is called
if glamor failed to complete its initialization, e.g:
(EE) Backtrace:
(EE) 0: Xwayland (OsSigHandler+0x29)
(EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0)
(EE) 2: Xwayland (glamor_sync_close+0x2a)
(EE) 3: Xwayland (glamor_close_screen+0x52)
(EE) 4: Xwayland (CursorCloseScreen+0x88)
(EE) 5: Xwayland (AnimCurCloseScreen+0xa4)
(EE) 6: Xwayland (present_close_screen+0x42)
(EE) 7: Xwayland (dix_main+0x4f9)
(EE) 8: /lib64/libc.so.6 (__libc_start_main+0xf1)
(EE) 9: Xwayland (_start+0x2a)
Restore the previous CloseScreen() and DestroyPixmap() vfunc handlers in
case of failure when checking for the minimum requirements, so that if
any of the requirement is not met we don't leave the CloseScreen() and
DestroyPixmap() from glamor handlers in place.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1390018
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
The previous code only worked when the barrier was created by the same client
as the one calling XIChangeDeviceHierarchy.
http://bugzilla.redhat.com/show_bug.cgi?id=1384432
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Commits 816015648f and
fee0827a9a made it so that
wl_keyboard::enter doesn't result in X clients getting KeyPress events
while still updating our internal xkb state to be in sync with the
host compositor.
wl_keyboard::leave needs to be handled in the same way as its
semantics from an X client POV should be the same as an X grab getting
triggered, i.e. X clients shouldn't get KeyRelease events for keys
that are still down at that point.
This patch uses LeaveNotify for these events on wl_keyboard::leave and
changes the current use of KeymapNotify to EnterNotify instead just to
keep some symmetry between both cases.
On ProcessDeviceEvent() we still need to deactivate X grabs if needed
for KeyReleases.
Signed-off-by: Rui Matos <tiagomatos@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The definition by the manual is:
calloc(size_t nmemb, size_t size)
Swap the arguments of calloc() calls to be the right way around.
Presumably this makes no functional difference, but better follow the
spec.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Fixes the following warning:
test/Makefile.am:69: warning: variable 'os_LDADD' is defined but no program or
test/Makefile.am:69: library has 'os' as canonical name (possible typo)
Introduced upon the removal of test/os in:
commit 6a5a4e6037
Author: Keith Packard <keithp@keithp.com>
Date: Tue Dec 8 14:39:46 2015 -0800
Remove SIGIO support for input [v5]
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>
Signed-off-by: Rhys Kidd <rhyskidd@gmail.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Not needed anymore now that mipointer exposes an API for that,
miPointerInvalidateSprite()
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
I think it is possible that output could get queued to a client during
CloseDownClient. After it is removed from the pending queue, active
grabs are released, the client is awoken if sleeping and any work
queue entries related to the client are processed.
To fix this, move the call removing it from the output_pending chain
until after clientGone has been set and then check clientGone in
output_pending_mark.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1382444
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
posix_fallocate() does an explicit rollback if it gets EINTR, and
this is a problem on slow systems because when the allocation size
is sufficiently large posix_fallocate() will always be interrupted
by the smart scheduler's SIGALRM.
Changes since v1 - big comment in the code to explain what is going on
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Ian Ray <ian.ray@ge.com>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Daniel Stone <daniels@collabora.com>
[This was originally a workaround for a client-side resource leak:
http://lists.freedesktop.org/archives/xorg-devel/2012-November/034555.html
Obviously that's a broken app, but the performance problem it
illustrates - that walking the linked list ends up burning all your CPU
time - is real enough. - ajax]
v2: Replace with a shorter code sequence which computes the same
results for all but numBits == 7
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
If a work proc wakes up a sleeping client and it is ready to execute,
we need to re-compute the local 'are_ready' value before deciding
what timeout value to use in WaitForSomething.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98030
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If we're never painting anything in the window, we probably don't need
to map it.
v2: Drop ephyr_glamor_gles2 from hostx.c
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
xf86CheckHWCursor() would dereference sPriv without NULL checking it. If Option
"SWCursor" is specified, sPriv == NULL. In this case we should assume that HW
cursors are not supported.
Signed-off-by: Alex Goins <agoins@nvidia.com>
Reviewed-by: Andy Ritger <aritger@nvidia.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
On Linux, setting the main thread's name changes the program name
(/proc/self/comm). Setting it to MainThread breaks scripts that rely on
the command name, e.g. ps -C Xorg.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
On some random condition, a touch event may trigger a crash in Xwayland
in GetTouchEvents().
The (simplified) backtrace goes as follow:
(gdb) bt
#0 GetTouchEvents() at getevents.c:1892
#1 QueueTouchEvents() at getevents.c:1866
#2 xwl_touch_send_event() at xwayland-input.c:652
#5 wl_closure_invoke() from libwayland-client.so.0
#6 dispatch_event() from libwayland-client.so.0
#7 wl_display_dispatch_queue_pending() from libwayland-client.so.0
#8 xwl_read_events() at xwayland.c:483
#9 ospoll_wait() at ospoll.c:412
#10 WaitForSomething() at WaitFor.c:222
#11 Dispatch() at dispatch.c:412
#12 dix_main() at main.c:287
#13 __libc_start_main() at libc-start.c:289
#14 _start ()
The crash occurs when trying to access the sprite associated with the
touch device, which appears to be NULL. Reason being the device itself
is more a keyboard device than a touch device.
Moreover, it appears the device is neither enabled nor activated
(inited=0, enabled=0) which doesn't seem right, but matches the code in
init_touch() from xwayland-input.c which would enable the device if it
was previously existing and otherwise would create the device but not
activate it.
Make sure we do activate and enable touch devices just like we do for
other input devices such as keyboard and pointer.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Pointer enter event coordinates are surface relative and we need them to
be screen relative for pScreen->SetCursorPosition().
https://bugzilla.gnome.org/show_bug.cgi?id=758283
Signed-off-by: Rui Matos <tiagomatos@gmail.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Commit c7e8d4a6ee had already unifdef
MODESETTING_OUTPUT_SLAVE_SUPPORT but commit
9257b1252d didn't notice that.
Signed-off-by: Nikhil Mahale <nmahale@nvidia.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Prior to this commit the Xorg.wrap code to detect if root rights are
necessary checked for DRM_IOCTL_MODE_GETRESOURCES succeeding *and*
reporting more then 0 output connectors.
DRM_IOCTL_MODE_GETRESOURCES succeeding alone is enough to differentiate
between old drm only cards (which need ums and thus root) and kms capable
cards.
Some hybrid gfx laptops have 0 output connectors on one of their 2 GPUs,
resulting in Xorg needlessly running as root. This commits removes the
res.count_connectors > 0 check, fixing this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Fixes DRI2 client driver name mapping for newer AMD GPUs with the
modesetting driver, allowing the DRI2 extension to initialize.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add a missing ifdef needed for --disable-glamor.
Signed-off-by: Mihail Konev <k.mvc@ya.ru>
Reviewed-by: Jon Turney <jon.turney@dronecode.org.uk>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Commit 501d8e2b removed --enable-aiglx, but made xwin always be
--enable-glx.
Signed-off-by: Mihail Konev <k.mvc@ya.ru>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Jon Turney <jon.turney@dronecode.org.uk>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Special case for the systemd-logind case in xfree86: when we're vt-switched
away and a device is plugged in, we get a paused fd from logind. Since we
can't probe the device or do anything with it, we store that device in the
xfree86 and handle it later when we vt-switch back. The device is not added to
inputInfo.devices until that time.
When the device is removed while still vt-switched away, the the config system
never notifies the DDX. It only runs through inputInfo.devices and our device
was never added to that.
When a device is plugged in, removed, and plugged in again while vt-switched
away, we have two entries in the xfree86-specific list that refer to the same
device node, both pending for addition later. On VT switch back, the first one
(the already removed one) will be added successfully, the second one (the
still plugged-in one) fails. Since the fd is correct, the device works until
it is removed again. The removed devices' config_info (i.e. the syspath)
doesn't match the actual device we addded tough (the input number increases
with each plug), it doesn't get removed, the fd remains open and we lose track
of the fd count. Plugging the device in again leads to a dead device.
Fix this by adding a call to notify the DDX to purge any remainders of devices
with the given config_info, that's the only identifiable bit we have at this
point.
https://bugs.freedesktop.org/show_bug.cgi?id=97928
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
No functional changes but it makes it easier to remove elements from the
middle of the list (future patch).
We don't have an init call into this file, so the list is manually
initialized.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
They're identically laid-out structs but let's use the right type to search
for our desired value.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The extension does not exist in the registry, thus needs to know they're
using EGL 1.5 in order to determine the eglGetPlatformDisplay function
pointer is valid.
Thus brings us into some lovely circular dependency.
Since mesa won't be able (in the foreseeable future) to export the KHR
flavour of extension (another way one could assume that EGL 1.5 is
available) just drop all the heuristics and use the
EGL_EXT_platform_base extension.
In practise (checked with the Mali driver) any EGL 1.5 driver will
advertise support for EGL_EXT_platform_base.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
When putting a device node into a poll-request list, do not overwrite a
"please-remove" element with the same fd, so that a closed device file
is ospoll_remove'd prior to being ospoll_add'ed.
Before, the opposite order was possible, resulting in ospoll_add
considering the newly opened file being already polled, should it have a
fd for which the "please-remove" has not been procesed yet. In this
case, no further events would be seen from the device.
Signed-off-by: Mihail Konev <k.mvc@ya.ru>
Regressed-in: 52d6a1e832
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97880
Patchwork: https://patchwork.freedesktop.org/patch/113763/
Hit-and-Reduced-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-and-Reduced-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Prevents the HW cursor from intermittently jumping around when the
cursor image is changed while the cursor is being moved. This is hardly
noticeable in normal operation but can be quite confusing when stepping
through these codepaths in a debugger.
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
xf86CursorScreenRec::HotX/Y contain 0 for PRIME slave screens.
Fixes incorrect HW cursor position on PRIME slave screens.
Also hoist the hotspot translation out from xf86ScreenSet/MoveCursor to
xf86Set/MoveCursor, since the hotspot position is a property of the
cursor, not the screen.
v2:
* Squash patches 1 & 2 of the v1 series, since it's basically the same
problem
* Use the master screen's xf86CursorScreenRec::HotX/Y instead of
CursorRec::bits->x/yhot, since CursorRec::bits can be NULL (Hans de
Goede)
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
They're not needed, and they won't be present on win32.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Emil Velikov <emil.l.veikov@gmail.com>
eglGetDisplay forces the implementation to guess which kind of display
it's been handed. glvnd does something different from Mesa, and in
general it's impossible for the library to get this right. Add a new
inline that gets the logic right, and works around a quirk in epoxy.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Fixes make check with out-of-tree builds.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
As of last commit all the places in our configure.ac require version
2.3.1 (released back in 2007) or later. With the latter introducing the
1.3.0 version, as returned by drmGetLibVersion.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
It fixes a bug where the version reported by drmGetLibVersion() was
'wrong'. See libdrm commit 79038751ffe("libdrm: add support for server
side functionality in libdrm") for details.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The former contains the minimum required version which is required.
Strictly speaking Xephyr/Xwayland may require version greater than the
current 2.3.0, although I've personally haven't checked the specifics.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Afaict there's little-to-no reason/way one would want xserver without
DRI support on Solaris platforms.
This will allow us to simplify/fix all the libdrm detection in the next
commit.
Cc: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Presently the option guards both direct and accelerated indirect GLX. As
such when one toggles it off they end up without any acceleration.
Remove the option all together until we have the time to split/rework
things.
Cc: Jon Turney <jon.turney@dronecode.org.uk>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
The option is misleading and using it leads to disabling both direct and
accelerated indirect GLX. In such cases the xserver GLX attempts to
match DRISW (IGLX) configs with the DRI2/3 ones (direct GLX) leading to
all sorts of fun experience.
Remove the option until we get a clear split and control over direct vs
indirect GLX.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
The messages from glxdricommon.c (used by drisw) still have the A, but
at least we're don't have it locally.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Commit cba28d5 - "glamor: Handle bitplane in glamor_copy_fbo_cpu"
introduced a regression as the computed pixmap offset would not match
the actual coordinates and write data elsewhere in memory causing a
segfault in fbBltOne().
Translate the pixmap coordinates so that the data is read and written at
the correct location.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97974
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-and-Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Emulate pointer warps by locking the pointer and sending relative
motion events instead of absolute. X will keep track of the "fake"
pointer cursor position given the relative motion events, and the
client warping the cursor will warp the faked cursor position.
Various requirements need to be met for the pointer warp emulator to
enable:
The cursor must be invisible: since it would not be acceptable that a
fake cursor position would be different from the visual representation
of the cursor, emulation can only be done when there is no visual
representation done by the Wayland compositor. Thus, for the emulator
to enable, the cursor must be hidden, and would the cursor be displayed
while the emulator is active, the emulator would be destroyed.
The window that is warped within must be likely to have pointer focus.
For example, warping outside of the window region will be ignored.
The pointer warp emulator will disable itself once the fake cursor
position leaves the window region, or the cursor is made visible.
This makes various games depending on pointer warping (such as 3D
first-person shooters and stategy games using click-to-drag-map like
things) work.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Translate grabbing a pointer device with confineTo set to a window into
confining the Wayland pointer using the pointer constraints protocol.
This makes clients that depend on the pointer not going outside of the
window region, such as certain games and virtual machines viewers, to
function more properly.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>