The client could have said anything here, and if what they said doesn't
actually name an atom NameForAtom() will return NULL, and strcmp() will
be unhappy about that.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit d4995a3936)
In the typical pattern in games of "hide cursor, grab with a confineTo,
warp constantly the pointer to the middle of the window" the last warping
step is actually rather optional. Some games may choose to just set up a
grab with confineTo argument, and trust that they'll get correct relative
X/Y axis values despite the hidden cursor hitting the confinement window
edge.
To cater for these cases, lock the pointer whenever there is a pointer
confinement and the cursor is hidden. This ensures the pointer position
is in sync with the compositor's when it's next shown again, and more
importantly resorts to the relative pointer for event delivery.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit ca17f3e9fd)
This fixes grabs on InputOnly windows whose parent is the root window
failing with GrabNotViewable. This is due to window->borderSize/windowSize
being computed as clipped by its parent, resulting in a null region.
Setting up the right size on the root window makes the InputOnly size
correct too, so the GrabNotViewable paths aren't hit anymore.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 513e3bd387)
Of sorts, actually make it confine to the pointer focus, as the
InputOnly window is entirely invisible to xwayland accounting,
we don't have a xwl_window for it.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit fafdb0cc96)
Of sorts, as we can't honor pointer warping across the whole root window
coordinates, peek the pointer focus in these cases.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit c217fcb4c4)
When running an Xwayland server from the command line, we end up
resetting the server every time all of the clients connected to the
server leave. This would be fine, except that xwayland makes the mistake
of unconditionally calling LoadExtensionList(). This causes us to setup
the glxExtension twice in a row which means that when we lose our last
client on the second server generation, we end up trying to call the glx
destructors twice in a row resulting in a segfault:
(EE)
(EE) Backtrace:
(EE) 0: Xwayland (OsSigHandler+0x3b) [0x4982f9]
(EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0) [0x70845bf]
(EE) 2: /usr/lib64/dri/swrast_dri.so (__driDriverGetExtensions_virtio_gpu+0x32897d) [0x1196e5bd]
(EE) 3: /usr/lib64/dri/swrast_dri.so (__driDriverGetExtensions_virtio_gpu+0x328a45) [0x1196e745]
(EE) 4: /usr/lib64/dri/swrast_dri.so (__driDriverGetExtensions_virtio_gpu+0x32665f) [0x11969f7f]
(EE) 5: Xwayland (__glXDRIscreenDestroy+0x30) [0x54686e]
(EE) 6: Xwayland (glxCloseScreen+0x3f) [0x5473db]
(EE) 7: Xwayland (glxCloseScreen+0x53) [0x5473ef]
(EE) 8: Xwayland (dix_main+0x7b6) [0x44c8c9]
(EE) 9: Xwayland (main+0x28) [0x61c503]
(EE) 10: /lib64/libc.so.6 (__libc_start_main+0xf1) [0x72b1401]
(EE) 11: Xwayland (_start+0x2a) [0x4208fa]
(EE) 12: ? (?+0x2a) [0x2a]
(EE)
(EE) Segmentation fault at address 0x18
(EE)
Fatal server error:
(EE) Caught signal 11 (Segmentation fault). Server aborting
(EE)
Easy reproduction recipe:
- Start an Xwayland session with the default settings
- Open a window
- Close that window
- Open another window
- Close that window
- Total annihilation occurs
Signed-off-by: Lyude <lyude@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 4f29366f1e)
Commit aa6717ce2 switched xf86WaitForInput from using select(2) to using
poll(2). Before this change, the timeout was interpreted as being in
microseconds; afterwards it is fed directly to xorg_poll which interprets
it as being in milliseconds. This results in the function potentially
blocking 1000x longer than intended. This commit scales down the timeout
argument before passing it to xorg_poll, being careful to ensure the result
is not rounded down due to integer division.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 2fbf62b2fb)
Without this, assertion failures can make life hard for users and those
trying to help them.
v2:
* Change commit log wording slightly to "can make life hard", since
apparently e.g. logind can alleviate that somewhat.
* Set default handler for SIGABRT in
hw/xfree86/common/xf86Init.c:InstallSignalHandlers() and
hw/xquartz/quartz.c:QuartzInitOutput() (Eric Anholt)
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
(cherry picked from commit 27a6b9f7c8)
E.g. because Xinerama is enabled.
Fixes crash on startup and wrong colours in that case.
Bugzilla: https://bugs.freedesktop.org/100293
Bugzilla: https://bugs.freedesktop.org/100294
Fixes: 62f4405257 ("xfree86/modes: Move gamma initialization to
xf86RandR12Init12 v2")
Tested-by: Mariusz Bialonczyk <manio@skyboo.net>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 41dafcc2a2)
Otherwise xcb will treat our attempt to send xv requests as a connection
error (quite reasonably: we're asking it to emit a request for which
there is no defined major opcode), and we'll die quietly the first time
we hit KdBlockhandler.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit 14d2fe74f4)
DRM_EVENT_CONTEXT_VERSION is the latest context version supported by
whatever version of libdrm is present. modesetting was blindly asserting
it supported whatever version that may be, even if it actually didn't.
With libdrm 2.4.78, setting a higher context version than 2 will attempt
to call the page_flip_handler2 vfunc if it was non-NULL, which being a
random chunk of stack memory, it might well have been.
Set the version as 2, which should be bumped only with the appropriate
version checks.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Daniel Stone <daniels@collabora.com>
(cherry picked from commit 0c8e6ed858)
A null pointer dereference can occur in dmxSync, because TimerForce
does not handle a null pointer.
dmxSyncTimer is set to NULL a few lines above on a certain condition,
which happened on my machine. The explicit NULL check allowed me to
start Xdmx again without a segmentation fault.
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 21eda7464d)
Copied from Mesa with no modifications. Gives us Geminilake PCI IDs.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit 368f60d461)
This ends up passing 0 as the bpp argument to fb screen setup, which is
not really the best plan.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 83c4297d2c)
If the screen pixmap or the corresponding texture creation with glamor
fails, exit cleanly with an error message instead of segfaulting.
Fixes: https://bugzilla.redhat.com/1431633
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit b0ce1d088a)
In XWayland, dri3_send_open_reply() is called from a sync callback, so
there is a possibility that the client might be gone when we get to the
callback eventually, which leads to a crash in _XSERVTransSendFd() from
WriteFdToClient() .
Client resources can survive the client itself, in which case we
may end up in our sync callback trying to access client's data after
it's been freed/reclaimed.
Add a ClientStateCallback handler to monitor the client state changes
and clear the sync callback set up by the glamor drm code if any.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1416553
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=100040
Tested-by: Mark B <mark.blakeney@bullet-systems.net>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
(cherry picked from commit 937527f979)
After an X cursor is unrealized, the seat's corresponding x_cursor is
cleared, but if a frame callback was pending at the time, it will
remain and thus prevent any further cursor update, leaving the window
with no cursor.
Make sure to destroy the frame callback, if any, when that occurs, so
that next time a cursor needs to be set, it won't be ignored for a frame
callback that will never be triggered.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1389327
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Rui Matos <tiagomatos@gmail.com>
(cherry picked from commit d4b7e0eaa4)
keyboard_check_repeat() fetches the XWayland seat from the
dev->public.devicePrivate do do its thing.
If a key event is sent programmatically through Xtest, our device is the
virtual core keyboard and that has a dev->public.devicePrivate of NULL,
leading to a segfault in keyboard_check_repeat().
This is the case with "antimicro" which sends key events based on the
joystick buttons.
Don't set the checkRepeat handler on the VCK since it cannot possibly work
anyway and it has no effect on the actual checkRepeat intended functionality.
Bugzilla: https://bugzilla.redhat.com/1416244
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>
(cherry picked from commit fe5c340046)
During the InitInput() phase, the wayland events get dequeued so we
can possibly end up calling dispatch_pointer_motion_event().
If this occurs before xwl_seat->focus_window is set, it leads to a NULL
pointer derefence and a segfault.
Check for xwl_seat->focus_window in both pointer_handle_frame() and
relative_pointer_handle_relative_motion() prior to calling
dispatch_pointer_motion_event() like it's done in
pointer_handle_motion().
Bugzilla: https://bugzilla.redhat.com/1410804
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>
(cherry picked from commit 8c9909a992)
For some applications (like fullscreen games) it matters for XRandr
resolution to be correctly set and equal to root window resolution.
In XServer there is already hack for this, adapted it for XWayland.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=99574
Signed-off-by: Svitozar Cherepii <razotivs@gmail.com>
Tested-by: Svitozar Cherepii <razotivs@gmail.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 1c78bec9ca)
If the Wayland compositor sets a rotation on the output, Xwayland
translates the transformation as an xrandr rotation for the given
output.
However, if the rotation is not supported by the CRTC, this is not
a valid setup and xrandr queries will fail.
Pretend we support all rotations and reflections so that the
configuration remains a valid xrandr setup.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99663
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit afeace27d3)
Previously, we would swap the width/height of the Xwayland output based
on the output rotation, so that the overall screen size would match the
actual rotation of each output.
Problem is the RandR's ConstrainCursorHarder() handler will also apply
the output rotation, meaning that when the output is rotated, the
pointer will be constrained within the wrong dimension.
Moreover, XRandR assumes the original output width/height are unchanged
when the output is rotated, so by changing the Xwayland output width and
height based on rotation, Xwayland causes XRandr to report the wrong
output sizes (an output of size 1024x768 rotated left or right should
remain 1024x768, not 768x1024).
So to avoid this issue and keep things consistent between Wayland and
Xwayland outputs, leave the actual width/height unchanged but apply the
rotation when computing the screen size. This fixes both the output size
being wrong in "xrandr -q" and the pointer being constrained in the
wrong dimension with rotated with weston.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99663
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 058809c43e)
xf86RecolorCursor() may be called directly from XRecolorCursor as well
as from xf86ScreenSetCursor(). In the latter case, the input lock is
already held, but not for the former and so we need to add a wrapper
function that acquires the input lock before performing
xf86RecolorCursor()
References: https://bugs.freedesktop.org/show_bug.cgi?id=99358
(cherry picked from commit 7198a6d4e7)
Signed-off-by: Qiang Yu <Qiang.Yu@amd.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 1012510620)
Detailed mode reports 108 mm x 68 mm which is for smaller display.
Maximum image size reports 15 cm x 10 cm which aligns with its physical
size, use this size instead.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 9874f73e88)
In InitOutput, if xf86HandleConfigFile returns CONFIG_NOFILE
(which it does if no config file or directory is present), the
autoconfig flag is set, causing xf86AutoConfig to be called
later on.
xf86AutoConfig calls xf86OutputClassDriverList via the
call tree:
xf86AutoConfig =>
listPossibleVideoDrivers =>
xf86PlatformMatchDriver =>
xf86OutputClassDriverList
and xf86OutputClassDriverList attempts to traverse a linked list
that is a member of the XF86ConfigRec struct pointed to by the
global xf86configptr, which is NULL at this point because the
XF86ConfigRec struct is only allocated (by xf86readConfigFile)
AFTER the config file and directory have been successfully
opened; the CONFIG_NOFILE return from xf86HandleConfigFile
occurs BEFORE the call to xf86readConfigFile which allocates
the XF86ConfigRec struct.
Rx: In read.c (for symmetry with xf86freeConfig, which already
appears in this file), add a new function xf86allocateConfig
which tests the value of xf86configptr and, if it's NULL,
allocates the XF86ConfigRec struct and deposits the pointer
in xf86configptr. In xf86Parser.h, add a prototype for the
new xf86allocateConfig function.
Back in read.c, #include "xf86Config.h". In xf86readConfigFile,
change the open-code call to calloc to a call to the new
xf86allocateConfig function.
In xf86AutoConfig.c, add a call to the new xf86allocateConfig function
to the beginning of xf86AutoConfig to make sure the XF86ConfigRec struct
is allocated.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Ben Crocker <bcrocker@redhat.com>
(cherry picked from commit 8b335d9068)
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>
(cherry picked from commit 59ad0e6a41)
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>
(cherry picked from commit 5611585b87)
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>
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 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>
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>
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>
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>
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>
