[SOLVED] xorg ui corrupted

ziongate · 2019-09-13 22:21:39

Hi all,

running openbox + compton + tint2 + xf86-video-amdgpu (RX590).
I am experiencing the following issue, sometimes after hours of perfect xorg working:

UI freezes, but i can still move the mouse and moving near a window border, border resize symbols still appear, but screen is not updated. All frozen also the tint2 clock. Also, even if i type into terminals that was open, nothing is displayed, but i believe is for the same issue, UI is not updated.

Moving to another virtual console, i see by top there are no processes at more than 1% of cpu.

killall xinit and restart xorg solves all,
also, if i kill compton and restart it, i can now move the windows, even if the content of the windows is completely full of garbage of old windows that was over it (no redrawn),

--------------------------------

this is my system:

Linux version 5.2.13-arch1-1-ARCH (builduser@heftig-49962)
xorg-server-1.20.5-2
xf86-video-amdgpu-19.0.1-1
openbox-3.6.1-4
compton-7.3-1 (note: same issue was happening with xcmpmgr)
tint2-16.7-1

all the above are up-to-date packages

Graphic card is RX590
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] (rev e1) (prog-if 00 [VGA controller])
Subsystem: XFX Pine Group Inc. Ellesmere [Radeon RX 470/480/570/570X/580/580X/590]

If any help on how to debug this weird issue, very appreciated.

Regards,
Angelo

Last edited by ziongate (2019-09-15 20:29:34)

seth · 2019-09-14 07:31:32

the content of the windows is completely full of garbage

Does this affect all clients (eg. xterm) or just some (w/ OpenGL contexts, nb. that browsers will typicall have that!)?
Does resizing the window "fix" this?

Please post the xorg log and try the modesetting driver as well as restricting amdgpu to dri 2, https://wiki.archlinux.org/index.php/AM … figuration

ziongate · 2019-09-14 10:03:59

Hi seth,

thanks for the kind reply.

Have some updates, it seems happening together with some keyboard input,:

1) DRI3 or DRI2 makes no changes, since
2) i found a way to reproduce the issue, pressing a random key sequence in the terminal at a very fast rate
3) no changes on xterm windows, i cannot move/resize it, and could also break the UI also typing into it

I attach xorg log with UI broken, stored just after issue happend, and another log after killal xinit

xorg log on ui freeze
xorg log after exiting xorg
video of the issue

These are the current keyboard settings

╰─○ setxkbmap -print -verbose 10
Setting verbose level to 10
locale is C
Trying to load rules file ./rules/evdev...
Trying to load rules file /usr/share/X11/xkb/rules/evdev...
Success.
Applied rules from evdev:
rules: evdev
model: pc105
layout: it
variant: ,dvorak
options: grp:alt_shift_toggle
Trying to build keymap using the following components:
keycodes: evdev+aliases(qwerty)
types: complete
compat: complete
symbols: pc+it+inet(evdev)+group(alt_shift_toggle)
geometry: pc(pc105)
xkb_keymap {
xkb_keycodes { include "evdev+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compat { include "complete" };
xkb_symbols { include "pc+it+inet(evdev)+group(alt_shift_toggle)" };
xkb_geometry { include "pc(pc105)" };
};

Thanks
Angelo

Last edited by ziongate (2019-09-14 10:05:17)

ziongate · 2019-09-14 11:16:37

Hi,

still an update.
Found now a key combination that produces the issue : it is left ALT|start + F8 on this logitech craft keyboard,
or also, F8 only, but htis after after pressing the FN lock key.

Last edited by ziongate (2019-09-14 12:49:06)

seth · 2019-09-14 14:03:44

As for xterm: I only meant whether it also shows "garbage" content after killing compton.
Can you cause similar/any issues w/ the problematic input if compton is NOT running?

Let's see whether there're any global shortcuts (this time w/ compton running):

xdotool key "XF86LogGrabInfo"

will dump present shortcuts (or maybe you remember binding something+F8 to anything)

If you get problems w/o compton running, try dropping the dvorak variant (and the toggle)

ziongate · 2019-09-14 21:24:48

Hi seth,

thanks for the help.

once i kill compton, xterm windows stays clean
screenshot

btw. issues happen at the same with compton disabled/killed.

Key sequence to produce this is very clear:

I do Fn + F8 or F9 or F10, all these 3 keys paralizes the UI.

It seems that there is some xorg / X11 keybinding that corresponds to this key pressed, and breaks the UI.

xdotool key "XF86LogGrabInfo"
gives nothing as output, even with the problem ongoing.

I removed dvorak, same issue, i am now with

╰─○ setxkbmap -print -verbose 10
Setting verbose level to 10
locale is C
Trying to load rules file ./rules/evdev...
Trying to load rules file /usr/share/X11/xkb/rules/evdev...
Success.
Applied rules from evdev:
rules: evdev
model: logicordless
layout: it
options: grp:alt_shift_toggle
Trying to build keymap using the following components:
keycodes: evdev+aliases(qwerty)
types: complete
compat: complete
symbols: pc+it+inet(evdev)+group(alt_shift_toggle)
geometry: pc(pc104)
xkb_keymap {
xkb_keycodes { include "evdev+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compat { include "complete" };
xkb_symbols { include "pc+it+inet(evdev)+group(alt_shift_toggle)" };
xkb_geometry { include "pc(pc104)" };
};

Last edited by ziongate (2019-09-14 21:25:55)

seth · 2019-09-15 06:14:56

a) please always use code tags for shell I/O and file contents
b) yes it does. I forgot to menton that it dumps that info into the xorg log - my bad, sorry :-\

ziongate · 2019-09-15 07:55:56

Hi seth,

still many thanks.

Yes, such magic x tools as xdotool seems to do his job well.

This is the log:
log

until [136.925] all was fine (there is the first xdotool key "XF86LogGrabInfo" output) , then i pressed ALT+F9, and issue happened, so i issued some seconds after the second xdotool key "XF86LogGrabInfo" .

As you can see, critical point is:

[   136.925]   Printing all registered grabs of client pid 1069 /usr/lib/gnome-terminal-server 
[   136.925] End list of registered passive grabs
[   176.464] (**) Option "fd" "18"
[   176.464] (II) event2  - Power Button: device removed
[   176.465] (**) Option "fd" "21"
[   176.465] (II) event1  - Power Button: device removed
[   176.465] (**) Option "fd" "22"
[   176.465] (II) event0  - Sleep Button: device removed
[   176.465] (**) Option "fd" "23"
[   176.465] (II) event3  - Logitech M705: device removed
[   176.465] (**) Option "fd" "24"
[   176.466] (**) Option "fd" "24"
[   176.466] (II) event19 - Logitech Craft: device removed
[   176.466] (II) AIGLX: Suspending AIGLX clients for VT switch
[   176.553] (II) systemd-logind: got pause for 13:83
[   176.553] (II) systemd-logind: got pause for 13:65
[   176.553] (II) systemd-logind: got pause for 13:66
[   176.553] (II) systemd-logind: got pause for 13:67
[   176.553] (II) systemd-logind: got pause for 226:0
[   176.553] (II) systemd-logind: got pause for 13:64

seth · 2019-09-15 13:59:17

I don't see them captured in the log, but those are incidentally also the mediaplayer keys …

ziongate · 2019-09-15 20:28:18

Hi seth,

had a better analysis,

facts:
I am launching openbox from .xinitrc by "dubs-launch --exit-with-session openbox-session", UI freeze by ALT+F8

1 - launching xorg without any wm, xterm works fine, no issue with ALT+F8
2 - launching i3, by "exec i3" in .xinitrc, no issue with ALT+F8
3 - launching fluxbox by "fluxbox" in .xinitrc, no issue with ALT+F8
4 - launching openbox without dubs-launch but just by "exec openbox-session", ALT + F8 issue disappears.
5 - same "dubs-launch --exit-with-session openbox-session" works fine in a debian distro, tested same keyboard there, no issues with ALT+F8
6 - dbus-launch version is 1.12.16 in both arch and debian

So seems the dubs-launch is causing troubles to openbox on pressing such keys.

For now i solved this way,

exec openbox-session

in .xinitrc

but will investigate further a bit.

Many thanks
angelo

ziongate · 2019-09-15 20:55:28

And even a better solution (since gnome-terminal was not working)

.xinitrc

# openbox on Arch
dbus-update-activation-environment --all
exec openbox-session

Thanks seth

Arch Linux

#1 2019-09-13 22:21:39

[SOLVED] xorg ui corrupted

#2 2019-09-14 07:31:32

Re: [SOLVED] xorg ui corrupted

#3 2019-09-14 10:03:59

Re: [SOLVED] xorg ui corrupted

#4 2019-09-14 11:16:37

Re: [SOLVED] xorg ui corrupted

#5 2019-09-14 14:03:44

Re: [SOLVED] xorg ui corrupted

#6 2019-09-14 21:24:48

Re: [SOLVED] xorg ui corrupted

#7 2019-09-15 06:14:56

Re: [SOLVED] xorg ui corrupted

#8 2019-09-15 07:55:56

Re: [SOLVED] xorg ui corrupted

#9 2019-09-15 13:59:17

Re: [SOLVED] xorg ui corrupted

#10 2019-09-15 20:28:18

Re: [SOLVED] xorg ui corrupted

#11 2019-09-15 20:55:28

Re: [SOLVED] xorg ui corrupted

Board footer