RandR doesn't initialize alongside Xinerama.
This fixes a segfault with tearing down the modesetting driver
while xinerama is in use.
Signed-off-by: stefan11111 <stefan11111github@gmail.com>
It is not guaranteed that randr is enabled, or that `crtc->randr_crtc`
is not NULL.
This fixes a segfault with xinerama.
Signed-off-by: stefan11111 <stefan11111github@gmail.com>
When using `xdotool mouseup 1` in Chromium 136, a slave device is passed
to `drmmode_sprite_set_cursor`.
In `dix/events.c`, `dev->spriteInfo->sprite` for slave devices points to
their master device when they are not floating, allowing these functions
to handle slave device cases correctly.
Similarly, in `mi/misprite.c`, `miSpritePointerFuncs` checks
`IsFloating` for the incoming device, and `GetSprite` converts slave
devices to master devices if a non-floating slave is passed.
By contrast, the `drmmode_sprite_funcs` series functions track
per-screen cursor reference counts. This cursor state should also be
recorded on the master device rather than the non-floating slave device.
This inconsistency between `drmmode_sprite_funcs` and other sprite
handlers leads to the following issues in the drmmode sprite driver:
1. The slave device stores state that it shouldn't record.
2. The master device's record becomes stale. (e.g., `ChangeToCursor` in
`dix/events.c` called for a slave device updates the master's sprite,
causing the subsequent comparison between old and new cursors on the
master device to fail.)
This patch resolves the inconsistency by using GetMaster when the device
is not floating, aligning the behavior with `mi/misprite.c`.
---
The reason physical devices work while XTEST devices fail is that
`ActivateGrab` and `DeactivateGrab` in XTEST devices' `deviceGrab` are
set to `ActivatePointerGrab` and `DeactivatePointerGrab`, respectively.
Physical devices use `ActivateKeyboardGrab` and
`DeactivateKeyboardGrab`. Thus, releasing a physical device will not
trigger `DeactivatePointerGrab`.
The physical device is initialized by `AddInputDevice` using
"KeyboardGrab", whereas the XTEST device is initialized by
`AllocDevicePair`, which overrides the default KeyboardGrab with
"PointerGrab".
(gdb) bt
#0 drmmode_sprite_set_cursor (pDev=0x5555569b88f0, pScreen=0x555555c26990, pCursor=0x55555702c580, x=681, y=181)
at ../xorg-server/hw/xfree86/drivers/modesetting/drmmode_display.c:4349
#1 0x00005555555980a6 in miPointerUpdateSprite (pDev=0x5555569b88f0) at ../xorg-server/mi/mipointer.c:490
#2 0x0000555555597877 in miPointerDisplayCursor (pDev=0x5555569b88f0, pScreen=0x555555c26990, pCursor=0x55555702c580) at ../xorg-server/mi/mipointer.c:208
#3 0x000055555568ef1f in CursorDisplayCursor (pDev=0x5555569b88f0, pScreen=0x555555c26990, pCursor=0x55555702c580) at ../xorg-server/xfixes/cursor.c:168
#4 0x0000555555644150 in AnimCurDisplayCursor (pDev=0x5555569b88f0, pScreen=0x555555c26990, pCursor=0x55555702c580) at ../xorg-server/render/animcur.c:197
#5 0x00005555555d5f12 in ChangeToCursor (pDev=0x5555569b88f0, cursor=0x55555702c580) at ../xorg-server/dix/events.c:952
#6 0x00005555555d60ad in PostNewCursor (pDev=0x5555569b88f0) at ../xorg-server/dix/events.c:1003
#7 0x00005555555d79ac in DeactivatePointerGrab (mouse=0x5555569b88f0) at ../xorg-server/dix/events.c:1716
#8 0x000055555569d217 in ProcessDeviceEvent (ev=0x7fffe4073c20, device=0x5555569b88f0) at ../xorg-server/Xi/exevents.c:1955
#9 0x000055555569d433 in ProcessOtherEvent (ev=0x7fffe4073c20, device=0x5555569b88f0) at ../xorg-server/Xi/exevents.c:2020
#10 0x00005555556eb297 in ProcessPointerEvent (ev=0x7fffe4073c20, mouse=0x5555569b88f0) at ../xorg-server/xkb/xkbAccessX.c:756
#11 0x000055555558c86c in mieqProcessDeviceEvent (dev=0x5555569b88f0, event=0x7fffe4073c20, screen=0x555555c26990) at ../xorg-server/mi/mieq.c:503
#12 0x00005555556692d9 in ProcXTestFakeInput (client=0x555556b5bf60) at ../xorg-server/Xext/xtest.c:434
#13 0x000055555566941a in ProcXTestDispatch (client=0x555556b5bf60) at ../xorg-server/Xext/xtest.c:468
#14 0x00005555555c002c in Dispatch () at ../xorg-server/dix/dispatch.c:552
#15 0x00005555555cf546 in dix_main (argc=8, argv=0x7fffffffe9b8, envp=0x7fffffffea00) at ../xorg-server/dix/main.c:274
#16 0x00005555557bbf07 in main (argc=8, argv=0x7fffffffe9b8, envp=0x7fffffffea00) at ../xorg-server/dix/stubmain.c:34
(gdb) p pDev->name
$1 = 0x5555569b9960 "Virtual core XTEST pointer"
(gdb) frame 12
#12 0x00005555556692d9 in ProcXTestFakeInput (client=0x555556b5bf60) at ../xorg-server/Xext/xtest.c:434
434 mieqProcessDeviceEvent(dev, &xtest_evlist[i], miPointerGetScreen(inputInfo.pointer));
(gdb) p client->clientIds[0]->cmdname
$2 = 0x5555570852f0 "xdotool"
(gdb) p client->clientIds[0]->cmdargs
$3 = 0x555557078b30 "mouseup 1"
Closes: #1685
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2282>
(cherry picked from commit e19e86c29f)
(cherry picked from commit 035caac7b2468fd3857e0c2bff74956272993974)
(cherry picked from commit f170a12cdf299f70162eeff458ad84e18f1c0c43)
Signed-off-by: Ben Song <bensongsyz@gmail.com>
Some amdgpu hardware (older ones, such as AMD Polaris 11 ) can only
render 64x64, 64x128 and 128x128 cursor. It doens't report any errors to
user space and only visual glitches on monitor visible.
This patch checks If drm driver reports any cursor side 64 or 128 - assume
hardware can only render 64x64 or 128x128 hw cursor planes
Fixes: https://gitlab.freedesktop.org/xorg/xserver/-/work_items/1922
Fixes: https://github.com/X11Libre/xserver/issues/1816
Signed-off-by: Tautvis <gtautvis@gmail.com>
drmmode_set_mode_major() calls drmmode_create_tearfree_shadow() on every
mode set, and that function unconditionally destroys both TearFree
shadow buffers before allocating replacements. Between the teardown and
the repaint the CRTC has nothing valid to scan out, so every RandR
change -- including ones that only move a CRTC or re-assert the mode it
already has -- blanks the display. With TearFree off the function
returns early and the same change happens with the screens lit, which is
also how xf86-video-amdgpu behaves.
Keep the buffers when the scanout dimensions are unchanged, which is
what drmmode_crtc_scanout_create() in xf86-video-amdgpu does. Their
contents are still re-seeded: drmmode_copy_damage() reads the screen
pixmap at the CRTC's position, so a CRTC that only moved would otherwise
keep displaying the pixels from its old position until something
happened to damage them.
A genuine resolution change still tears down before allocating and can
still blank; that case wants allocate-before-free, which is a larger
change.
Assisted-by: Claude Opus 5 <noreply@anthropic.com>
Signed-off-by: Kiyoshi Spreclerg <kiyoshi_pip@protonmail.com>
This commit refactors 61aa2ede91 to always force the software cursor (and disable power
consumption optimizations) when a known VM DRM driver is running. This is done because cursor behavior varies depending
on the VM frontend, leading to inconsistencies:
* if the display backend is gtk, the cursor is shown by default when the window is out of focus and hidden when in focus
(it must be rendered by the VM GPU in software).
* if the display backend is sdl, it always shows the cursor, regardless of drmModeSetCursor2 and related function calls.
* if the VM runs under a Spice backend using the QXL display, the rendering application (remote-viewer) behaves
correctly.
For more details, see the QEMU manpage (search for show-cursor):
https://www.qemu.org/docs/master/system/qemu-manpage.html
Until a better solution is found, force the software cursor.
fixes: https://github.com/X11Libre/xserver/issues/3477
Signed-off-by: Tautvis <gtautvis@gmail.com>
Replace public min/max macros by private MIN/MAX and deprecate them.
The few drivers still using them can trivially define them on their own.
Adding a new private header for all kind of math-ish definitions - future
commits will move more stuff there.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Present calls drmmode_set_mode_major() as part of ms_present_unflip(),
which leads to a crash due to the recursive attempt to force present to
unflip when it already is.
Fix it by simply skipping the forced present unflip when present itself is
unflipping. This also speeds up drmmmode_prepare_modeset() when present
isn't even flipping to begin with.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1791
Fixes: 899c87af1f ("modesetting: unflip before any setcrtc() calls")
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1793>
When doing reverse PRIME, the buffer being scaned out is still the front
BO.
Properly reuse its fb_id, to prevent adding a FB for the front_bo each
time the fb_id is requested.
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2064>
Now gbm required for the modesetting driver.
`GLAMOR_HAS_GBM` is defined even if glamor isn't built.
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
Since libgbm was split from mesa, and a backend that works
with only dumb buffers was written, there is no reason why we
should roll out own dumb buffer implementation.
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
When running in a virtual machine, the cursor pitch
may not behave the same as it does on bare metal.
This patch disables a power consumption optimization
when running in a vm, working around the cursor pitch issues.
This means that some vm users who previously had a working
cursor pitch may now see some increased power consumption.
Fixes: https://github.com/X11Libre/xserver/issues/1816
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
Moved the cursor glyph cropping into a separate function that handles reflections and rotations.
Also, x/y are indexes into the buffer, so they should be clamped to width/height len - 1 for correctness.
Signed-off-by: John Studnicka <contact@zentec.dev>
The space needed to store these extra values is at worst a few dozen bytes.
In exchange for these, larger cursors glyphs can use a more optimal cursor size.
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
