xorg issueshttps://gitlab.freedesktop.org/groups/xorg/-/issues2021-05-14T17:34:49Zhttps://gitlab.freedesktop.org/xorg/xserver/-/issues/1175Screen tearing for video playback is observed after screen is rotated 180 deg...2021-05-14T17:34:49Zqwang65Screen tearing for video playback is observed after screen is rotated 180 degree in Ubuntu 20.04, Gnome Vanilla, X11Screen tearing for video playback is observed after screen is rotated 180 degree in Ubuntu 20.04, Gnome Vanilla, X11. We haven't seen the issue in Wayland.
Here are the steps to reproduce the issue.
1. Install Ubuntu 20.04.
2. Play video...Screen tearing for video playback is observed after screen is rotated 180 degree in Ubuntu 20.04, Gnome Vanilla, X11. We haven't seen the issue in Wayland.
Here are the steps to reproduce the issue.
1. Install Ubuntu 20.04.
2. Play video on ubuntu 20.04.
3. Turn on 'auto rotation" in setting to rotate the screen; Or use 'xrandr -o 2' to rotate the screen.
4. Screen tearing is observed for 100% reproducible after rotation.
5. It is happening on all of video contents with dynamic scene changing.https://gitlab.freedesktop.org/xorg/xserver/-/issues/1174Alternate for evdev based multi-seat in Xephyr2022-01-11T14:24:14ZFlora And CodeAlternate for evdev based multi-seat in XephyrXephyr 1.20 doesn't supports multi-seat, as evdev was removed in commit [2781995](https://gitlab.freedesktop.org/xorg/xserver/-/commit/27819950e4158326e0f83a30f2e8968b932625ef) .
Pls make way for evdev or provide some alternate way to a...Xephyr 1.20 doesn't supports multi-seat, as evdev was removed in commit [2781995](https://gitlab.freedesktop.org/xorg/xserver/-/commit/27819950e4158326e0f83a30f2e8968b932625ef) .
Pls make way for evdev or provide some alternate way to add it.
The code was removed for the reason "no usecase for evdev", but this is one, hence please revert the change.https://gitlab.freedesktop.org/xorg/xserver/-/issues/1172Xserver/modesetting/glamor/intel: double/triple buffering issue results in fl...2022-01-31T22:09:59ZYuriXserver/modesetting/glamor/intel: double/triple buffering issue results in flicker and outdated screen contentOn Xorg 1.20.11 (debian unstable) with an intel i7-10610U CML GT2, modesetting driver + glamor, the screen frequently swaps between what looks like the front and a backbuffer.
This is made apparent when using X11 _without_ a compositor....On Xorg 1.20.11 (debian unstable) with an intel i7-10610U CML GT2, modesetting driver + glamor, the screen frequently swaps between what looks like the front and a backbuffer.
This is made apparent when using X11 _without_ a compositor. Typing or scrolling into a window shows cyclically the image of ~0.25 seconds ago and the actual image.
Also worsens further (becoming basically unusable) when the laptop in on battery, probably due to some power-saving feature reducing frame updates.
This is on a Dell 7410 with an intel i7-10610U, CML GT2, modesetting driver, glamor enabled: this is the default config from debian unstable. Kernel tested between 5.10.24-5.10.28, Xorg 1.20.10-1.20.11.https://gitlab.freedesktop.org/xorg/xserver/-/issues/1171Xwayland/EGLstream remaining visual glitches2021-06-21T09:17:30ZOlivier FourdanXwayland/EGLstream remaining visual glitchesEven with https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/646, there are remaining visual glitches.
Initially, I reckoned that was a bug in Xwayland or in glamor, but I am not so sure now.
It all seems to behave as if ther...Even with https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/646, there are remaining visual glitches.
Initially, I reckoned that was a bug in Xwayland or in glamor, but I am not so sure now.
It all seems to behave as if there was multiple buffers involved and not all of them where successfully and consistently kept up-to-date.
Actually, it looks like ~~double~~ triple? buffering gone wrong to me (this is entirely empirical of course).
To reproduce:
1. In xterm, open the menu (<kbd>Ctrl</kbd>+LMB)
2. Navigate the menu
3. *Sometimes* some past content show a few entries before the currently selected one
Alternate method:
1. Resize xterm (or any other X11 window).
2. Sometimes the whole window becomes black
3. Typing in the window shows the different buffers.
I tried to capture a video of the issue:
![eglstream](/uploads/2ed25ac5ef9244ccf212f4f6aec83f9a/eglstream.webm)
(quality is low because I tried to keep the file small)
We can see what looks like different buffers being updated as the cursor moved over the window - One of those buffers is fully updated, the other one has the character "a" typed and the rest is just black.
This is with GNOME Shell.https://gitlab.freedesktop.org/xorg/app/xrandr/-/issues/55[xrandr] Error display with 'DoubleScan'2022-04-06T01:55:13Zrm beer[xrandr] Error display with 'DoubleScan'Adding the option stops rendering the graphic desktop to see only a
gray screen. (you can also see a small black square in the upper left
corner)
the error happens with any existing mode, either the defects or those created with --addmod...Adding the option stops rendering the graphic desktop to see only a
gray screen. (you can also see a small black square in the upper left
corner)
the error happens with any existing mode, either the defects or those created with --addmode
I would like to find out more about the problem and know what really happens.
SO: Linux 5.11.16-arch1-1.0 #1 SMP PREEMPT Fri, 23 Apr 2021 09:28:54
+0000 i686 GNU/Linux
packages:
mesa 21.0.2-1.1
libdrm 2.4.105-1.0
xorg-server 1.20.11-1.1
This problem has existed for 5 years, and you have the same problem
regardless of the monitor, machine, or system you use.https://gitlab.freedesktop.org/xorg/xserver/-/issues/1170Mouse cursor release event sometimes doesn't get registered by clients.2021-06-30T18:19:56ZIlya MzpMouse cursor release event sometimes doesn't get registered by clients.Steps to reproduce:
1. Open any app (e.g. browser)
2. Click while moving the mouse slightly. With browsers I noticed that having a lot of pictures helps reproduce the bug more consistently.
I have been noticing this bug on multiple devi...Steps to reproduce:
1. Open any app (e.g. browser)
2. Click while moving the mouse slightly. With browsers I noticed that having a lot of pictures helps reproduce the bug more consistently.
I have been noticing this bug on multiple devices (PC and laptop) with different input methods (mouse, trackpoint, touchpad). It is hard to reproduce and happens quite rarely during normal use.
![2021-05-05_00-22-14](/uploads/58a9ac4107900242e7b04d37d5193c8c/2021-05-05_00-22-14.mp4)https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/132the case conversions for Greek symbols are incomplete2022-01-27T22:10:41ZRay Vinethe case conversions for Greek symbols are incompleteRe: KeyBind.c#293 /* Case conversion for UCS, as in Unicode Data version 4.0.0 */
There is currently no entry for the Greek dotted lunate sigma symbols, ͼ & Ͼ, U037C & U03FE.
03FE first appeared in UnicodeData-4.1.0.txt and 037C in Un...Re: KeyBind.c#293 /* Case conversion for UCS, as in Unicode Data version 4.0.0 */
There is currently no entry for the Greek dotted lunate sigma symbols, ͼ & Ͼ, U037C & U03FE.
03FE first appeared in UnicodeData-4.1.0.txt and 037C in UnicodeData-5.0.0.txt
This results in the printout for these characters on key <AC07> of the Greek basic keyboard for the key sequence
```
AltGr Caps+AltGr AltGr+Shift Caps+AltGr+Shift
```
being
```
ͼ ͼ Ͼ Ͼ
```
I.e. no case toggle for Caps Lock
I don't know how the mapping tables are generated, so haven't tested with a newer version of Unicode, but patching Greek_upper_mapping[‍ ‍] and Greek_lower_mapping[‍ ‍], the print output then toggles with Caps Lock
```
ͼ Ͼ Ͼ ͼ
```
```diff
--- src/KeyBind.c
+++ src/KeyBind.c
@@ -340 +340 @@
- 0x0000, 0x0000, 0x037A, 0x0000, 0x0000, 0x0000, 0x037E, 0x0000,
+ 0x0000, 0x0000, 0x037A, 0x0000, 0x03FE, 0x0000, 0x037E, 0x0000,
@@ -356 +356 @@
- 0x03F7, 0x03F9, 0x03FA, 0x03FA, 0x0000, 0x0000, 0x0000, 0x0000
+ 0x03F7, 0x03F9, 0x03FA, 0x03FA, 0x0000, 0x0000, 0x03FE, 0x0000
@@ -361 +361 @@
- 0x0000, 0x0000, 0x037A, 0x0000, 0x0000, 0x0000, 0x037E, 0x0000,
+ 0x0000, 0x0000, 0x037A, 0x0000, 0x037C, 0x0000, 0x037E, 0x0000,
@@ -377 +377 @@
- 0x03F8, 0x03F2, 0x03FB, 0x03FB, 0x0000, 0x0000, 0x0000, 0x0000
+ 0x03F8, 0x03F2, 0x03FB, 0x03FB, 0x0000, 0x0000, 0x037C, 0x0000
```
For Caps Lock to toggle case for all level 3 & 4 characters on the basic keyboard as defined in xkb/symbols/gr, there are a number of other characters in the group `/* Greek and Coptic, U+0370 to U+03FF */` which also need adding.
I've included them in the attached patch which I use in my own build of libX11. Hopefully, it'll be of some use.
[KeyBind.c.patch](/uploads/30e6eb44b2fa4a7f93e8e106e9635633/KeyBind.c.patch)https://gitlab.freedesktop.org/xorg/xserver/-/issues/1169crash in xwl_pointer_warp_emulator_maybe_lock2021-06-03T07:42:03ZChristian Rauchrauch.christian@gmx.decrash in xwl_pointer_warp_emulator_maybe_lockI just got a crash of Xwayland (version 1.20.9):
```
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007f88c73c4859 in __GI_abort () at abort.c:79
#2 0x000055dfca054e40 in OsAbort () at ../../../../os/u...I just got a crash of Xwayland (version 1.20.9):
```
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007f88c73c4859 in __GI_abort () at abort.c:79
#2 0x000055dfca054e40 in OsAbort () at ../../../../os/utils.c:1351
#3 0x000055dfca05a279 in AbortServer () at ../../../../os/log.c:879
#4 0x000055dfca05b0da in FatalError (f=f@entry=0x55dfca080d90 "Caught signal %d (%s). Server aborting\n") at ../../../../os/log.c:1017
#5 0x000055dfca052189 in OsSigHandler (unused=<optimized out>, sip=0x7ffc013b4070, signo=11) at ../../../../os/osinit.c:156
#6 OsSigHandler (signo=11, sip=0x7ffc013b4070, unused=<optimized out>) at ../../../../os/osinit.c:110
#7 <signal handler called>
#8 0x000055dfc9ef041e in xwl_pointer_warp_emulator_maybe_lock (warp_emulator=warp_emulator@entry=0x55dfccbf5ce0, xwl_window=<optimized out>, sprite=<optimized out>, x=x@entry=683,
y=y@entry=384) at ../../../../../hw/xwayland/xwayland-input.c:2694
#9 0x000055dfc9ef3fa1 in xwl_pointer_warp_emulator_warp (y=384, x=683, sprite=<optimized out>, xwl_window=<optimized out>, warp_emulator=0x55dfccbf5ce0)
at ../../../../../hw/xwayland/xwayland-input.c:2823
#10 xwl_seat_emulate_pointer_warp (xwl_seat=<optimized out>, xwl_window=<optimized out>, sprite=<optimized out>, x=683, y=384) at ../../../../../hw/xwayland/xwayland-input.c:2823
#11 0x000055dfca028da2 in ProcWarpPointer (client=0x55dfcc3e2fc0) at ../../../../dix/events.c:3624
#12 0x000055dfca01b564 in Dispatch () at ../../../../dix/dispatch.c:478
#13 0x000055dfca01f614 in dix_main (argc=16, argv=0x7ffc013b4788, envp=<optimized out>) at ../../../../dix/main.c:276
#14 0x00007f88c73c60b3 in __libc_start_main (main=0x55dfc9eed580 <main>, argc=16, argv=0x7ffc013b4788, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>,
stack_end=0x7ffc013b4778) at ../csu/libc-start.c:308
#15 0x000055dfc9eed5be in _start ()
```
I believe that this was caused by an xclient.
`csgo_linux64[113620]: segfault at 938 ip 00007fc16f2adccb sp 00007ffdca54b550 error 6 in client_client.so[7fc16e440000+1d9f000]`https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/131the Greek phi symbol does not print when CapsLock is on2022-02-08T10:04:53ZRay Vinethe Greek phi symbol does not print when CapsLock is onOn the Greek keyboard, the 3rd level character on the &lt;AC04> key, unicode point U03D5, doesn't print when Caps Lock is on.
This is the Greek phi *symbol* which is mapped in KeyBind.c, Greek_upper_mapping[&zwj;&ThinSpace;&zwj;], to 0...On the Greek keyboard, the 3rd level character on the <AC04> key, unicode point U03D5, doesn't print when Caps Lock is on.
This is the Greek phi *symbol* which is mapped in KeyBind.c, Greek_upper_mapping[‍ ‍], to 0x03A6, the Greek capital letter PHI.
For the key sequences AltGr+‍<AC04> Caps+AltGr+‍<AC04>, the print out is ϕ , which should be ϕ Φ.
The problem seems to be related to the 1st & 2nd level characters on that key also being phi - Greek_phi & Greek_PHI, φ & Φ, unicode points U+03C6 & U+03A6.
Assign code point U03D5 to another key, say <AC06> which is the Greek_eta & Greek_ETA key, and the print out for AltGr+‍<AC06> Caps+AltGr+‍<AC06> is correct, ie ϕ Φ - ***and*** then it also starts working from the <AC04> key!https://gitlab.freedesktop.org/xorg/xserver/-/issues/1167Calling check_timers() on every iteration causes a massive perfomance regression2022-06-22T03:37:50ZJeremy Huddleston Sequoia521-jeremyhu@users.noreply.gitlab.freedesktop.orgCalling check_timers() on every iteration causes a massive perfomance regressionThis was reported to XQuartz in https://github.com/XQuartz/XQuartz/issues/156, and I bisected the perfomance regression to:
```
commit ac7a4bf44c68c5f323375974b208d4530fb5b60f (HEAD, refs/bisect/bad)
Author: Chris Wilson <chris@chris-wi...This was reported to XQuartz in https://github.com/XQuartz/XQuartz/issues/156, and I bisected the perfomance regression to:
```
commit ac7a4bf44c68c5f323375974b208d4530fb5b60f (HEAD, refs/bisect/bad)
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Sun Apr 15 15:40:03 2018 +0100
os/WaitFor: Check timers on every iteration
Currently we only check timer expiry if there are no client fd (or
other input) waiting to be serviced. This makes it very easy to starve
the timers with long request queues, and so miss critical timestamps.
The timer subsystem is just another input waiting to be serviced, so
evaluate it on every loop like all the others, at the cost of calling
GetTimeInMillis() slightly more frequently. (A more invasive and likely
OS specific alternative would be to move the timer wheel to the local
equivalent of timerfd, and treat it as an input fd to the event loop
exactly equivalent to all the others, and so also serviced on every
pass. The trade-off being that the kernel timer wheel is likely more
efficiently integrated with epoll, but individual updates to each timer
would then require syscalls.)
Reviewed-by: Peter Harris <pharris@opentext.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
```
I have not yet profiled this to determine what about check_timers() is so expensive.Jeremy Huddleston Sequoia521-jeremyhu@users.noreply.gitlab.freedesktop.orgJeremy Huddleston Sequoia521-jeremyhu@users.noreply.gitlab.freedesktop.orghttps://gitlab.freedesktop.org/xorg/xserver/-/issues/1166Xwayland doesn't filter out modifiers not supported by GBM2021-11-27T18:32:37ZSimon Sercontact@emersion.frXwayland doesn't filter out modifiers not supported by GBM1. Start gamescope, a Vulkan-based Wayland compositor, on an AMD GPU
2. Set `R600_DEBUG=nodcc` to disable some AMD modifiers for EGL/GBM users
3. Start vkcube, a Vulkan client
Both the compositor and the client will support AMD DCC modi...1. Start gamescope, a Vulkan-based Wayland compositor, on an AMD GPU
2. Set `R600_DEBUG=nodcc` to disable some AMD modifiers for EGL/GBM users
3. Start vkcube, a Vulkan client
Both the compositor and the client will support AMD DCC modifiers. However Xwayland won't (because GBM support for DCC modifiers is disabled by the env). This will result in a `BadAlloc` error sent to the client as a reply to `DRI3PixmapFromBuffers`.
Xwayland should filter out any modifier advertised by the parent compositor that it doesn't support.
Here this happens because of an env var, this could also happen because support for a new modifier has been plumbed in Vulkan but not in EGL yet.
Original issue: https://github.com/Plagman/gamescope/issues/185https://gitlab.freedesktop.org/xorg/font/daewoo-misc/-/issues/1License terms for daewoo-misc?2023-09-05T07:20:40ZPeter HuttererLicense terms for daewoo-misc?It looks like the daewoo-misc fonts are proprietary, the only information in COPYING is:
> "Copyright (c) 1987, 1988 Daewoo Electronics Co.,Ltd."
These fonts were first present in [X11R5](https://www.x.org/archive/X11R5/), see the `fo...It looks like the daewoo-misc fonts are proprietary, the only information in COPYING is:
> "Copyright (c) 1987, 1988 Daewoo Electronics Co.,Ltd."
These fonts were first present in [X11R5](https://www.x.org/archive/X11R5/), see the `fonts/bdf/misc/hanglg16.bdf` file and similar. The `COPYING` file we use now is from the `COPYRIGHT` line in the `.bdf` file, other fonts (e.g. the schumacher ones) seem to have `COMMENT:` lines to explain the terms. I can't find any other information about license terms for this font, this may be hidden in old mailing lists?
cc @keithp, @kem, @alanc as the old guard, maybe you have any ideas, memories or pointers on where to search.https://gitlab.freedesktop.org/xorg/driver/xf86-input-libinput/-/issues/37Force close in all event of keyboard2021-09-02T22:48:22Zrm beerForce close in all event of keyboardIf it's a wrong place, please move it!
SO:Archlinux
This problem present from 1.17.0 of libinput from february.
From a begin of 'startx' (or Xorg), and late of use the keyboard in less of 10 min, all events are forced to close and make...If it's a wrong place, please move it!
SO:Archlinux
This problem present from 1.17.0 of libinput from february.
From a begin of 'startx' (or Xorg), and late of use the keyboard in less of 10 min, all events are forced to close and make all fails to other programs that cause to stuck.
At first I solved by downgrade libinput to 1.16.4. But now i need downgrade all those files:
```
[2021-04-15T12:11:45-0300] [ALPM] downgraded libinput (1.17.1-1 -> 1.16.4-1)
[2021-04-19T03:33:19-0300] [ALPM] downgraded xorgproto (2021.3-1 -> 2020.1-1)
[2021-04-19T03:33:20-0300] [ALPM] downgraded libx11 (1.7.0-4 -> 1.7.0-3)
[2021-04-19T03:33:20-0300] [ALPM] downgraded pango (1:1.48.4-1 -> 1:1.48.2-1)
[2021-04-19T03:33:21-0300] [ALPM] downgraded openexr (2.5.5-1 -> 2.5.4-1)
[2021-04-19T03:33:21-0300] [ALPM] downgraded gnome-desktop (1:40.0-1 -> 1:3.38.3-1)
[2021-04-19T03:33:21-0300] [ALPM] downgraded gtkmm3 (3.24.4-1 -> 3.24.3-1)
[2021-04-19T03:33:21-0300] [ALPM] downgraded lxhotkey (0.1.1-1 -> 0.1.0-3)
[2021-04-19T03:33:21-0300] [ALPM] downgraded lxpanel (0.10.1-1 -> 0.10.0-2)
```
[bug-key.txt](/uploads/efc3c5034df8d91a5566fe45a248286b/bug-key.txt)
[bug-keyboard.txt](/uploads/01941d2bf5e1e2cacfc2c596fca00457/bug-keyboard.txt)
[bug-run.log](/uploads/b76b2ee6c28ece5711fac573c40db0e9/bug-run.log)
[bug-xxxx.log](/uploads/017873696028d06012fd47328ca0d64a/bug-xxxx.log)https://gitlab.freedesktop.org/xorg/xserver/-/issues/1165[Question] XTestFakeRelativeMotionEvent in Xwayland2021-04-19T16:51:37ZLiam Hupfer[Question] XTestFakeRelativeMotionEvent in XwaylandHi,
The Steam client, which uses X, uses the extension XTestFakeRelativeMotionEvent in its internal Steam Controller driver to handle pointer input. Users can map the Steam Controller trackpads in the Steam client to produce mouse outpu...Hi,
The Steam client, which uses X, uses the extension XTestFakeRelativeMotionEvent in its internal Steam Controller driver to handle pointer input. Users can map the Steam Controller trackpads in the Steam client to produce mouse output, which does not work on Wayland due to this incompatibility.
Is it possible for Xwayland to support this feature, and if so, what would it take to implement it? Thanks! Apologies if this is the wrong place to ask this sort of thing; please let me know if there's somewhere more appropriate.
Related: https://github.com/Plagman/gamescope/issues/33https://gitlab.freedesktop.org/xorg/xserver/-/issues/1164Excessive logging when async page flip fails2023-11-17T15:13:38ZPovilas KanapickasExcessive logging when async page flip failsThis bug has been extracted out of https://gitlab.freedesktop.org/xorg/xserver/-/issues/871.
As of recent Linux kernel with i915 and recent X master with modesetting driver, applications that request async flips will result in the follo...This bug has been extracted out of https://gitlab.freedesktop.org/xorg/xserver/-/issues/871.
As of recent Linux kernel with i915 and recent X master with modesetting driver, applications that request async flips will result in the following error in the logs for each async flip:
```
[ 4952.118] (WW) modeset(0): flip queue failed: Invalid argument
[ 4952.118] (WW) modeset(0): Present-flip: Queue flip on CRTC 0 failed: Invalid argument
[ 4952.123] (WW) modeset(0): flip queue failed: Invalid argument
[ 4952.123] (WW) modeset(0): Present-flip: Queue flip on CRTC 0 failed: Invalid argument
```
The root cause for failing flips seems to be that the hardware itself can't do async page flips with the modifiers that are being used on the particular CRTC. See https://github.com/torvalds/linux/blob/0f4498cef9f5cd18d7c6639a2a902ec1edc5be4e/drivers/gpu/drm/i915/display/intel_display.c#L12374.
Kernel prints the following error if drm debugging is enabled:
`[ 827.411096] i915 0000:00:02.0: [drm:intel_atomic_check [i915]] Linear memory/CCS does not support async flips`
It seems that there's not much we can do because there's no way to get the information on whether async flip will succeed on a particular CRTC, nor we can pass it to the applications via PresentQueryCapabilities request of the present extension (the capability may change dynamically if the modifiers change).
So at least we should not output logs for every failed async flip as that's will grow logs very fast.
Tested Linux 5.11.0 and 5.12.0-rc4, xserver d231ce2d9ce9644e77e8dbe8c5a23eeb11e85b55.xserver-21.1https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/-/issues/34[Vega 10 + RX5500M] Failures while using the system2021-04-16T14:04:13ZIntinteDAO[Vega 10 + RX5500M] Failures while using the systemI don't know how to define it. Since some update of "something" the AMDGPU Driver (Wayland) has been having problems running in random places. Sometimes you might not encounter the error, sometimes it would pop up every 5 minutes, but so...I don't know how to define it. Since some update of "something" the AMDGPU Driver (Wayland) has been having problems running in random places. Sometimes you might not encounter the error, sometimes it would pop up every 5 minutes, but something changed and it rarely happens now (I thought it was fixed). Changing the Kernel doesn't do anything, so it's probably not a Kernel error (something with Mesa?)
The computer is an MSI Alpha 15 laptop, so card switching is handled by PRIME.
Xorg does not work properly on this hardware (in configuration with an additional monitor).
It looks like because of some animation, the driver hangs and then runs artifacts after a few seconds. Switching to the console is possible, but after some time the whole system freezes.
Dmesg log: https://0bin.net/paste/g2vKuMLa#NdjcGYTUF1gvRFcedrE4BguxdqGQ1-Sax13r5W85rMlhttps://gitlab.freedesktop.org/xorg/driver/xf86-input-libinput/-/issues/36Invoking `xinput --disable [ || --enable] <device_xID>` kills X session2021-04-20T21:08:49ZCedric BhiheInvoking `xinput --disable [ || --enable] <device_xID>` kills X session_[Host info: Laptop Dell XPS15 running OS Arch x86_64 GNU/Linux 5.11.13-arch1-1 with gdm 40.0-1 on xorg-server 1.20.10-3]_
Whenever I invoke `$ xinput --disable <device_name>` xorg-server crashes and in so doing kills everything in the..._[Host info: Laptop Dell XPS15 running OS Arch x86_64 GNU/Linux 5.11.13-arch1-1 with gdm 40.0-1 on xorg-server 1.20.10-3]_
Whenever I invoke `$ xinput --disable <device_name>` xorg-server crashes and in so doing kills everything in the opened gdm session. The host recovers and presents USER with a new gdm session login dialog. Everything else seems completely normal on host.
The xorg-xinput version is 1.6.3-2, upgraded from 1.6.3-1 on 2020.05.19 (way before the issue appeared) <br>
On the other hand, gdm + the linux kernel and headers were upgraded recently (from /var/log/pacman.log):
- [2021-04-09T08:29:29] [ALPM] upgraded linux (5.11.11.arch1-1 -> >> 5.11.12.arch1-1)
- [2021-04-09T08:29:30] [ALPM] upgraded gdm (3.38.2.1-1 -> 40.0-1)
2021.04.09 is when the issue started to manifest itself. In the past 5 days I have seen at least 2 similar reports appear on that or very similar looking issues, essentially from archers, who as I, run X.
- http://paste.c-net.org/BunksTyped
- https://bbs.archlinux.org/viewtopic.php?id=264928
This issue is perfectly reproducible and is triggered by execution of the `xinput --disable <xID>` or `xinput --enable <xID>` commands, no matter what the `<xID>` is ...
The full systemd journal trace of the coredump is available in the attached file below where two X-crash events are recorded.
[journald_2021.04.14.log](/uploads/0cf4753bd8288a33a67285b831259e91/journald_2021.04.14.log)Peter HuttererPeter Huttererhttps://gitlab.freedesktop.org/xorg/xserver/-/issues/1163Segmentation fault when activating Displaylink screens2021-04-17T15:47:15ZJoren VranckenSegmentation fault when activating Displaylink screens### Description
Sometimes (not always), whenever I try to enable my Displaylink screens I get the following segmentation fault:
```
[ 26.149] (EE)
[ 26.149] (EE) Backtrace:
[ 26.150] (EE) 0: /usr/lib/Xorg (xorg_backtrace+0x53) ...### Description
Sometimes (not always), whenever I try to enable my Displaylink screens I get the following segmentation fault:
```
[ 26.149] (EE)
[ 26.149] (EE) Backtrace:
[ 26.150] (EE) 0: /usr/lib/Xorg (xorg_backtrace+0x53) [0x55646cb5ffd3]
[ 26.150] (EE) 1: /usr/lib/Xorg (0x55646ca19000+0x151df5) [0x55646cb6adf5]
[ 26.150] (EE) 2: /usr/lib/libc.so.6 (0x7f6b4b02b000+0x3cf80) [0x7f6b4b067f80]
[ 26.150] (EE) 3: /usr/lib/xorg/modules/drivers/modesetting_drv.so (0x7f6b4a381000+0x13853) [0x7f6b4a394853]
[ 26.150] (EE) 4: /usr/lib/Xorg (RRCrtcSet+0x7e2) [0x55646cacd5a2]
[ 26.150] (EE) 5: /usr/lib/Xorg (ProcRRSetCrtcConfig+0x547) [0x55646cace507]
[ 26.150] (EE) 6: /usr/lib/Xorg (0x55646ca19000+0x3a195) [0x55646ca53195]
[ 26.150] (EE) 7: /usr/lib/libc.so.6 (__libc_start_main+0xd5) [0x7f6b4b052b25]
[ 26.151] (EE) 8: /usr/lib/Xorg (_start+0x2e) [0x55646ca535de]
[ 26.151] (EE)
[ 26.151] (EE) Segmentation fault at address 0x29
[ 26.151] (EE)
Fatal server error:
[ 26.151] (EE) Caught signal 11 (Segmentation fault). Server aborting
```
### System Information
* Distribution: Arch Linux
* Kernel version: `5.11.13-arch1-1`
* Xorg version: 1.20.11
* Window manager: i3 4.19.2-1
* Displaylink: 5.4
* EVDI: 1.9.x (based on `devel` branch).https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/-/issues/194Display output laggy from iGPU when operating on desktop with attaching AMD R...2021-04-15T10:09:01ZJeremy SzuDisplay output laggy from iGPU when operating on desktop with attaching AMD R7 430 graphic (dGPU)[Steps to reproduce this issue]
1. Install a focal base image
2. Attach an AMD R7 430 graphic as dGPU without connecting any monitor on it.
3. Attach DP monitor on iGPU (no matter the iGPU is Intel(i915), or AMD(amdgpu)).
4. After loggi...[Steps to reproduce this issue]
1. Install a focal base image
2. Attach an AMD R7 430 graphic as dGPU without connecting any monitor on it.
3. Attach DP monitor on iGPU (no matter the iGPU is Intel(i915), or AMD(amdgpu)).
4. After logging it, the display shows laggy.
[Additional information]
1. doesn't see this issue if selecting 'Wayland'
2. add a config
```
Section "OutputClass"
Identifier "MyRadeon"
MatchDriver "radeon"
Driver "modesetting"
EndSection
```
to fallback to use modesetting could workaround this issue.
```
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: xserver-xorg 1:7.7+19ubuntu14
ProcVersionSignature: Ubuntu 5.10.0-1019.20-oem 5.10.18
Uname: Linux 5.10.0-1019-oem x86_64
ApportVersion: 2.20.11-0ubuntu27.16
Architecture: amd64
CasperMD5CheckResult: skip
Date: Fri Apr 9 16:23:42 2021
DistUpgraded: Fresh install
DistroCodename: focal
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes, including running git bisection searches
GraphicsCard:
Advanced Micro Devices, Inc. [AMD/ATI] Oland [Radeon HD 8570 / R7 240/340 / Radeon 520 OEM] [1002:6611] (rev 87) (prog-if 00 [VGA controller])
Subsystem: Hewlett-Packard Company Oland [Radeon HD 8570 / R7 240/340 / Radeon 520 OEM] [103c:3375]
Advanced Micro Devices, Inc. [AMD/ATI] Renoir [1002:1636] (rev da) (prog-if 00 [VGA controller])
Subsystem: Hewlett-Packard Company Renoir [103c:872b]
InstallationDate: Installed on 2021-04-09 (0 days ago)
InstallationMedia: Ubuntu 20.04 "Focal" - Build amd64 LIVE Binary 20210324-23:53
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.10.0-1019-oem root=UUID=027c2398-aef7-43d2-a339-6a2163287914 ro quiet splash vt.handoff=7
SourcePackage: xorg
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 12/30/2020
dmi.bios.release: 2.0
dmi.bios.vendor: HP
dmi.bios.version: S09 Ver. 02.02.00
dmi.board.name: 872B
dmi.board.vendor: HP
dmi.board.version: KBC Version 09.94.00
dmi.chassis.type: 3
dmi.chassis.vendor: HP
dmi.ec.firmware.release: 9.148
dmi.modalias: dmi:bvnHP:bvrS09Ver.02.02.00:bd12/30/2020:br2.0:efr9.148:svnHP:pn:pvr:rvnHP:rn872B:rvrKBCVersion09.94.00:cvnHP:ct3:cvr:
dmi.product.family: 103C_53307F HP EliteDesk
dmi.sys.vendor: HP
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.102-1ubuntu1~20.04.1
version.libgl1-mesa-dri: libgl1-mesa-dri 20.2.6-0ubuntu0.20.04.1
version.libgl1-mesa-glx: libgl1-mesa-glx N/A
version.xserver-xorg-core: xserver-xorg-core 2:1.20.9-2ubuntu1.2~20.04.1
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20200226-1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1
```
[XorgLog.txt](/uploads/772d055ed0bde6de5690d95936dd0e0f/XorgLog.txt)https://gitlab.freedesktop.org/xorg/xserver/-/issues/1162Invoking `xinput --disable [ || --enable] <device_xID>` kills X session2021-04-16T00:49:24ZCedric BhiheInvoking `xinput --disable [ || --enable] <device_xID>` kills X session_[Host info: Laptop Dell XPS15 running OS Arch x86_64 GNU/Linux 5.11.13-arch1-1 with gdm 40.0-1 on xorg-server 1.20.10-3]_
Whenever I invoke `$ xinput --disable <device_name>` xorg-server crashes and in so doing kills everything in the..._[Host info: Laptop Dell XPS15 running OS Arch x86_64 GNU/Linux 5.11.13-arch1-1 with gdm 40.0-1 on xorg-server 1.20.10-3]_
Whenever I invoke `$ xinput --disable <device_name>` xorg-server crashes and in so doing kills everything in the opened gdm session. The host recovers and presents USER with a new gdm session login dialog. Everything else seems completely normal on host.
The xorg-xinput version is 1.6.3-2, upgraded from 1.6.3-1 on 2020.05.19 (way before the issue appeared) <br>
On the other hand, gdm + the linux kernel and headers were upgraded recently (from /var/log/pacman.log):
- [2021-04-09T08:29:29] [ALPM] upgraded linux (5.11.11.arch1-1 -> >> 5.11.12.arch1-1)
- [2021-04-09T08:29:30] [ALPM] upgraded gdm (3.38.2.1-1 -> 40.0-1)
2021.04.09 is when the issue started to manifest itself. In the past 5 days I have seen at least 2 similar reports appear on that or very similar looking issues, essentially from archers, who as I, run X.
- http://paste.c-net.org/BunksTyped
- https://bbs.archlinux.org/viewtopic.php?id=264928
This issue is perfectly reproducible and is triggered by execution of the `xinput --disable <xID>` or `xinput --enable <xID>` commands, no matter what the `<xID>` is ...
The full systemd journal trace of the coredump is available in the attached file below where two X-crash events are recorded.
[journald_2021.04.14.log](/uploads/2fbbdbeb308ab356d8a273bb274c4578/journald_2021.04.14.log)