Hi,
I'm a french sysadmin in a school with ~250 computers (labs) running
Debian 9 + Wayland.
I am testing Debian 10 and I hit an annoying problem that persists
(present in D9+ Wayland, and D10 default config), I can't find an
already open bug for it, I have doubts about the right package to submit
against (gnome-shell, pulseaudio, wayland, udev, kernel) and
https://www.debian.org/Bugs/Reporting indicate to ask here.
What : in a wayland gnome session, the keyboard and mouse event loop
could be frozen during a little more than 1 second in all situations
that fire a sound (if there isn't sound already in progress or very
recently played). The mouse can't move, the keyboard can't do anything,
not even VT-switch to console with Ctrl+Alt+F3.
Bonus : If a key press event is processed, then the freeze occur, then a
key release is queued but delayed, and the focus what in a text field,
then the letter corresponding to the key is repeated many times.
I didn't add fancy gnome-shell extensions. I've enabled Alternate-tab,
nothing else different from fresh install defaults.
Reproducer 1 :
In a default Debian buster installation (testing 2019-04-21, gnome-shell
3.30.2-7, pulseaudio 12.2-4, libwayland-client0 1.16.0-1, udev 241-3,
linux-image-4.19.0-4-amd64 4.19.28-2) with a first system user named
testuser with a working sound configuration :
- log in as testuser
- start gnome-terminal
- type some letters that are not a valid shell command prefix (lets says
type "qwert"), see no lags for now
- press tab and right after try to move mouse or typing anything else,
everything is frozen for more than 1 second
Reproducer 2 :
In a default Debian buster installation (testing 2019-04-21, gnome-shell
3.30.2-7, pulseaudio 12.2-4, libwayland-client0 1.16.0-1, udev 241-3,
linux-image-4.19.0-4-amd64 4.19.28-2) with a first system user named
testuser with a working sound configuration :
- log in as testuser
- start firefox
- browse https://www.debian.org
- hit Ctrl+F to have focus in a search field, to to seek a word that in
NOT in the page (but have some first letters that match some words in
the page), lets say "windows" (wi matches "wiki", and I've got a nasty
mood :)
- you will observe the lag when firefox trigger "no match" sound after
typing n, and the search box will contain around 71 or 72 "n" :
"winnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnndows"
Poor work-around :
- enable accessibility feature "visual-bell". The problem vanishes, but
the epileptic guys will go very disapointed.
Severity :
- technically : the right is usually done after a delay (~ low)
- perception from users : make the system very annoying to use
(important !) : my users reboot to get Windows to not have this problem :-/
On debian 9, I manage to see with strace the whole gnome-session and
I've seen a open() on sound card device that blocks more than 400ms. On
debian 10, I didn't manage to strace gnome-shell without entire lock-up.
(suggestions are very welcome).
I think that system sound triggering should not freeze all input event
processing, in any case. It seems true with gnome session over Xorg, it
seems false to me with gnome session over Wayland.
Debian is very very great, hoping I can help a little bit to
troubleshoot things here.
Regards,
Ludovic