Same when using DisplayLink adapter via both EVDI or UDL. Crashes most
of the times when GPU file (/dev/dri/cardX) is created. Gnome logs:
dladmin-XPS-13-9360 gnome-shell[3367]:
St:ERROR:../src/st/st-bin.c:206:st_bin_destroy: assertion failed: (priv->child
== NULL)
dladmin-XPS-13-9360
Fix in Xorg:
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/447#note_515426
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to mutter in Ubuntu.
https://bugs.launchpad.net/bugs/1870512
Title:
forced software cursor with
Adding movie depicting the problem. And it happens without actually
moving the mouse, after dragging the window.
** Attachment added: "IMG_1245.MOV"
https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1870512/+attachment/5375562/+files/IMG_1245.MOV
--
You received this bug
Fair point, but question is if it's software cursor from Xserver's
perspective. NVidia driver might be blending the cursor in, while
"emulating HW cursor" on the Xorg's end, right?
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to
A recording would preferably be better, a screenshot might not give the
full picture. Anyway, sure, I shall post it. The case I'm describing is
more extreme, the squares are way bigger and flickering constantly, most
of the time effectively preventing usage of the machine, such messy it
gets.
I guess the bug on Xorg's end is pretty self-explanatory:
https://gitlab.freedesktop.org/xorg/xserver/-/issues/828
The fix for Xorg's has been smoked-tested recently, seems to be working fine.
** Bug watch added: gitlab.freedesktop.org/xorg/xserver/-/issues #828
Tested on Dell XPS13 (Intel GPU) and Precision M3800 (Intel/Nvidia-nouveau),
with evdi-backed displays mostly focusing on enabling/disabling screens, both
by system settings as well as ACPI events (lid closing/opening).
Looks fine so far.
--
You received this bug notification because you are a
Consulted the bug on #gnome-shell IRC.
Next step is to track down the event that actually triggers execution of
cogl_glib_source_dispatch. It's possible it simply does not arrive. BTW, this
does not rule out Xorg as potential culprit, it might be simply not delivering
the expected event. This
OK, I'm totally sure it's a freeze.
Moreover, gnome-shell stack trace looks normal, event loop runs just fine.
I can generate and provide core file if needed.
What I managed to debug so far, is that in case of multiple /dev/dri/cardX
being created
frame_cb in meta-stage-x11.c:296 is not called
Point is, there is no crash file. Graphical environment is not responsive, but
nothing seems to have crashed.
If there's a stacktrace or core file needed, no problem, I can rebuild in debug
mode, attach debugger and gather those.
--
You received this bug notification because you are a member
10 matches
Mail list logo