GNOME Bugzilla – Bug 777428
vlc in fullscreen mode should not block or crash gnome
Last modified: 2017-02-06 07:49:50 UTC
when running VLC, an X application, in full screen mode, gnome can be halted or crashed by wildly clicking the progress bar to position a mp4 movie differently. i am not sure what it depends on, but on a slow machine playing a dvd iso one click to fast forward the movie is sufficient. dvd iso copied from dvd onto disk with: blocks=$(isosize -d 2048 /dev/sr0) dd if=/dev/sr0 of=isoimage.iso bs=2048 count=$blocks status=progress as described here: https://wiki.archlinux.org/index.php/Optical_disc_drive#Reading_an_ISO_image_from_a_CD.2C_DVD.2C_or_BD
with weston, it immediately fails to display the progress bar properly, or it blinks. but weston stays alive so to say.
it looks like right mouse button menu crashes, and clicking on the progress bar freezes it.
btw, i opened a bug for weston/xwayland here: https://bugs.freedesktop.org/show_bug.cgi?id=99445
related vlc bug is here: https://trac.videolan.org/vlc/ticket/17829
In https://bugs.freedesktop.org/show_bug.cgi?id=99445#c9 you mention "gnome crashes", however mutter still relies on Xwayland for many things and is not able to work without, so if Xwayland crashes, GNOME session will die as well. What I mean by that is it could be different things, gnome-shell, mutter or Xwayland, and the end result is the same, the user session dies. Can you provide either a backtrace of gnome-shell or the logs related to gnome-shell and Xwayland at the time of the crash? (I don't know much about Arch linux but in Fedora this can be found with journalctl)
olivier, thanks for your comment! there is a patch now at the vlc trac ticket: https://trac.videolan.org/vlc/attachment/ticket/17829/0001-remove-X11BypassWindowManagerHint-from-time-tooltip.patch i cannot understand this, you?
(In reply to soloturn from comment #6) > olivier, thanks for your comment! there is a patch now at the vlc trac > ticket: > https://trac.videolan.org/vlc/attachment/ticket/17829/0001-remove- > X11BypassWindowManagerHint-from-time-tooltip.patch > > i cannot understand this, you? I will ashamedly admit that I am not very familiar with Qt, but it seems this flag Qt::X11BypassWindowManagerHint being removed there was to bypass the window manager completely, which using an educated guess most likely translates as an override-redirect window in X11. Have you tried that patch, does it help?
(In reply to Olivier Fourdan from comment #7) > (In reply to soloturn from comment #6) > > olivier, thanks for your comment! there is a patch now at the vlc trac > > ticket: > > https://trac.videolan.org/vlc/attachment/ticket/17829/0001-remove- > > X11BypassWindowManagerHint-from-time-tooltip.patch > > > > i cannot understand this, you? > > I will ashamedly admit that I am not very familiar with Qt, but it seems > this flag Qt::X11BypassWindowManagerHint being removed there was to bypass > the window manager completely, which using an educated guess most likely > translates as an override-redirect window in X11. > > Have you tried that patch, does it help? i love to try patches where i technically understand how the problem should go away. so no, i did not try. when i have more time i'd love to try the weston patch though. and yes, you are right. https://trac.videolan.org/vlc/ticket/17829 "This results in a borderless window that is not managed at all (i.e., no keyboard input). It's a borderless window that does not grab keyboard or mouse focus." what i fail to understand technically is: vlc-2 is an X program. why it is able to crash gnome via xwayland, if it is not able to crash X? i thought xwayland is "just" a normal X using wayland instead some lower level driver. x beeing responsible to draw the whole region (i.e. window), and then tell wayland to display it. is it when displaying one above the other? i am looking on: https://wayland.freedesktop.org/architecture.html e.g. but i am technically not good enough to get it.
(In reply to soloturn from comment #8) > [...] > > what i fail to understand technically is: vlc-2 is an X program. why it is > able to crash gnome via xwayland, if it is not able to crash X? i thought > xwayland is "just" a normal X using wayland instead some lower level driver. Xwayland is an Xserver who talks to the Wayland compositor, so that's a whole world of new possibilities of problems. BTW, unless I missed it, we are still missing a backtrace (with symbols), or even logs, that would help to determine whether it's Xwayland or mutter who crashes (comment 5), without this we are still left with conjectures and hypothesis...
(In reply to soloturn from comment #8) > [...] > i love to try patches where i technically understand how the problem should > go away. so no, i did not try. So I built vlc with the patch from https://trac.videolan.org/vlc/ticket/17829 and I can confirm it avoids the deadlock between Xwayland and mutter.
(In reply to Olivier Fourdan from comment #5) > Can you provide either a backtrace of gnome-shell or the logs related to > gnome-shell and Xwayland at the time of the crash? (I don't know much about > Arch linux but in Fedora this can be found with journalctl) will keep this in mind. unlike the freeze and behaviour in weston i am not able to reliably reproduce a crash - therefor i pestering you so much to explain more about the nature of the problems to make this easier :)
olivier, you r right. lets forget about vlc-2.2.4 and focus on the upcoming vlc-3.0.0. and - if something similar can be reproduced, reopen. thanks again for the valuable hints, and confirming the behaviour!
(In reply to soloturn from comment #12) > olivier, you r right. lets forget about vlc-2.2.4 and focus on the upcoming > vlc-3.0.0. and - if something similar can be reproduced, reopen. thanks > again for the valuable hints, and confirming the behaviour! As I understand it, actually, it is gnome, but not something that can be easily fixed without some major surgery in the way mutter works as a Wayland compositor and X11 window manager (thus X11 client as well). Basically, mutter is the Wayland compositor and an X11 client, Xwayland is a Wayland client and X11 server whereas vlc, using an override redirect shaped window and updating it constantly triggers a case where mutter waits for Xwayland and Xwayland waits for mutter (i.e. a deadlock). But this is a bit of a corner case, because as mentioned previously, some code was added in Xwayland to try to recover from this situation, but as the client window (the tooltop from vlc) is updated constantly, the issue reoccurs again and again and everything appears to be stuck. This is why I think the fix in vlc is probably the best way forward.