mpv on wayland based gnome produces borderless video window

[abrouwers]

mpv version and platform

mpv compiled from git, 10/9/2016 (commit b5357e8)

Recently, I've upgraded to gnome 3.22, which has defaulted to using wayland as the backend. I actually hadn't realized this for a few days, until I tried to launch a video file with mpv. To my surprise, v0.20 produced a tiny, borderless window.

I've upgraded to mpv git, and the issue of having a borderless window remains (though, the window size has grown to exceed my screen - SS attached).

Log files

[ajb@thinkpad ajb]$ mpv -v /home/andrew/Videos/star_wars.mp4 [cplayer] Command line options: '-v' '/home/andrew/Videos/star_wars.mp4' [cplayer] mpv git-b5357e8 (C) 2000-2016 mpv/MPlayer/mplayer2 projects [cplayer] built on Sun Oct 9 20:23:09 EDT 2016 [cplayer] ffmpeg library versions: [cplayer] libavutil 55.28.100 [cplayer] libavcodec 57.48.101 [cplayer] libavformat 57.41.100 [cplayer] libswscale 4.1.100 [cplayer] libavfilter 6.47.100 [cplayer] libswresample 2.1.100 [cplayer] ffmpeg version: 3.1.4 [cplayer] [cplayer] Configuration: ./waf configure --prefix=/usr --confdir=/etc/mpv --disable-cdda [cplayer] List of enabled features: alsa any-gl asm atomics audio-input av-avpacket-int64-duration av-new-pixdesc av-pix-fmt-mmal av-subtitle-nopict av-version-info avcodec-chroma-pos-api avcodec-has-codecpar avcodec-new-codec-api avcodec-profile-name avframe-metadata avframe-skip-samples avutil-has-hwcontext avutil-hdr avutil-mastering-metadata build-date c11-tls cplayer debug-build dlopen drm dvbin dvdread egl-drm egl-helpers egl-x11 encoding fchmod gbm gbm.h gl gl-wayland gl-x11 glibc-thread-name glob gnuc iconv jack jpeg lcms2 libass libass-osd libav libavdevice libavfilter libbluray libdl libm librt libswresample libv4l2 linux-fstatfs lua nanosleep optimize oss-audio oss-audio-native posix posix-or-mingw posix-spawn pthreads pulse resampler shm sse4-intrinsics standard-gl stdatomic subprocess termios tv tv-v4l2 vaapi vaapi-drm vaapi-egl vaapi-glx vaapi-hwaccel vaapi-wayland vaapi-x-egl vaapi-x11 vdpau vdpau-gl-x11 vdpau-hwaccel videodev vt.h wayland x11 xext xinerama xrandr xss xv zlib [global] config path: '' -> '/home/ajb//.config/mpv' [global] config path: 'mpv.conf' -/-> '/home/ajb//.config/mpv/mpv.conf' [global] config path: 'config' -/-> '/home/ajb//.config/mpv/config' [global] config path: 'mpv.conf' -/-> '/home/ajb//.mpv/mpv.conf' [global] config path: 'config' -/-> '/home/ajb//.mpv/config' [global] config path: 'mpv.conf' -/-> '/etc/mpv/mpv.conf' [global] config path: 'config' -/-> '/etc/mpv/config' [cplayer] Setting option 'v' = '' (flags = 8) [global] config path: 'input.conf' -/-> '/home/ajb//.config/mpv/input.conf' [global] config path: 'input.conf' -/-> '/home/ajb//.mpv/input.conf' [global] config path: 'input.conf' -/-> '/etc/mpv/input.conf' [osc] Loading script @osc.lua... [global] config path: 'scripts' -/-> '/home/ajb//.config/mpv/scripts' [global] config path: 'scripts' -/-> '/home/ajb//.mpv/scripts' [global] config path: 'scripts' -/-> '/etc/mpv/scripts' [osc] loading mp.defaults [osc] loading @osc.lua [global] config path: 'lua-settings/osc.conf' -/-> '/home/ajb//.config/mpv/lua-settings/osc.conf' [global] config path: 'lua-settings/osc.conf' -/-> '/home/ajb//.mpv/lua-settings/osc.conf' [global] config path: 'lua-settings/osc.conf' -/-> '/etc/mpv/lua-settings/osc.conf' [osc] lua-settings/osc.conf not found. [cplayer] Run command: define-section, flags=0, args=[showhide, mouse_move script-binding osc/keybinding1 [cplayer] mouse_leave script-binding osc/__keybinding2 [cplayer] , force] [cplayer] Run command: enable-section, flags=0, args=[showhide, allow-hide-cursor+allow-vo-dragging] [cplayer] Run command: define-section, flags=0, args=[input, mouse_btn0 script-binding osc/keybinding3 [cplayer] shift+mouse_btn0 script-binding osc/keybinding4 [cplayer] mouse_btn2 script-binding osc/__keybinding5 [cplayer] mouse_btn0_dbl ignore [cplayer] shift+mouse_btn0_dbl ignore [cplayer] mouse_btn2_dbl ignore [cplayer] , force] [cplayer] Run command: enable-section, flags=0, args=[input, ] [cplayer] Run command: define-section, flags=0, args=[input_osc, del script-binding osc/keybinding6 [cplayer] , default] [cplayer] Run command: enable-section, flags=0, args=[input_osc, allow-hide-cursor+allow-vo-dragging] [cplayer] Run command: define-section, flags=0, args=[input_forced_osc, , force] [cplayer] Run command: enable-section, flags=0, args=[input_forced_osc, allow-hide-cursor+allow-vo-dragging] [cplayer] Done loading @osc.lua. [ytdl_hook] Loading script @ytdl_hook.lua... [global] config path: 'scripts' -/-> '/home/ajb//.config/mpv/scripts' [global] config path: 'scripts' -/-> '/home/ajb//.mpv/scripts' [global] config path: 'scripts' -/-> '/etc/mpv/scripts' [ytdl_hook] loading mp.defaults [cplayer] Run command: disable-section, flags=0, args=[input] [global] config path: 'fonts' -/-> '/home/ajb//.config/mpv/fonts' [global] config path: 'fonts' -/-> '/home/ajb//.mpv/fonts' [global] config path: 'fonts' -/-> '/etc/mpv/fonts' [osd/libass] Shaper: FriBidi 0.19.7 (SIMPLE) HarfBuzz-ng 1.3.1 (COMPLEX) [global] config path: 'subfont.ttf' -/-> '/home/ajb//.config/mpv/subfont.ttf' [global] config path: 'subfont.ttf' -/-> '/home/ajb//.mpv/subfont.ttf' [global] config path: 'subfont.ttf' -/-> '/etc/mpv/subfont.ttf' [global] config path: 'fonts.conf' -/-> '/home/ajb//.config/mpv/fonts.conf' [global] config path: 'fonts.conf' -/-> '/home/ajb//.mpv/fonts.conf' [global] config path: 'fonts.conf' -/-> '/etc/mpv/fonts.conf' [osd/libass] Setting up fonts... [ytdl_hook] loading @ytdl_hook.lua [cplayer] Run command: hook-add, flags=0, args=[on_load, 1, 10] [cplayer] Run command: hook-add, flags=0, args=[on_preloaded, 2, 10] [cplayer] Done loading @ytdl_hook.lua. [global] config path: 'scripts' -/-> '/home/ajb//.config/mpv/scripts' [global] config path: 'scripts' -/-> '/home/ajb//.mpv/scripts' [global] config path: 'scripts' -/-> '/etc/mpv/scripts' [global] config path: 'watch_later' -> '/home/ajb//.config/mpv/watch_later' [cplayer] Playing: /home/andrew/Videos/star_wars.mp4 [cplayer] Running hook: ytdl_hook/on_load [osd/libass] Using font provider fontconfig [osd/libass] Done. [cplayer] Run command: hook-ack, flags=0, args=[on_load] [ifo] Opening /home/andrew/Videos/star_wars.mp4 [bdmv/bluray] Opening /home/andrew/Videos/star_wars.mp4 [file] Opening /home/andrew/Videos/star_wars.mp4 [file] Stream opened successfully. [demux] Trying demuxers for level=normal. [lavf] Found 'mov,mp4,m4a,3gp,3g2,mj2' at score=100 size=2048. [lavf] avformat_find_stream_info() finished after 32816 bytes. [demux] Detected file format: mov,mp4,m4a,3gp,3g2,mj2 (libavformat) [find_files] Loading external files in /home/andrew/Videos/ [global] config path: 'sub/' -/-> '/home/ajb//.config/mpv/sub/' [global] config path: 'sub/' -/-> '/home/ajb//.mpv/sub/' [global] config path: 'sub/' -/-> '/etc/mpv/sub/' [global] config path: 'audio/' -/-> '/home/ajb//.config/mpv/audio/' [global] config path: 'audio/' -/-> '/home/ajb//.mpv/audio/' [global] config path: 'audio/' -/-> '/etc/mpv/audio/' [cplayer] Running hook: ytdl_hook/on_preloaded [cplayer] Run command: hook-ack, flags=0, args=[onpreloaded] cplayer Video --vid=1 () (h264) cplayer Audio --aid=1 --alang=eng (_) (aac) [cplayer] Subs --sid=1 --slang=eng (mov_text) [vo/opengl] Initializing OpenGL backend 'wayland' [vo/opengl/wayland] Seat "seat0" connected [vo/opengl/wayland] output received: [vo/opengl/wayland] vendor: AUO [vo/opengl/wayland] model: 0x106c [vo/opengl/wayland] w: 1366, h: 768 [vo/opengl/wayland] scale: 1 [vo/opengl/wayland] Hz: 60.103001 [vo/opengl/wayland] EGL_VERSION=1.4 (DRI2) [vo/opengl/wayland] EGL_VENDOR=Mesa Project [vo/opengl/wayland] EGL_CLIENT_APIS=OpenGL OpenGL_ES [vo/opengl/wayland] Trying to create Desktop OpenGL context. [vo/opengl/wayland] GL_VERSION='3.3 (Core Profile) Mesa 12.0.3' [vo/opengl/wayland] Detected desktop OpenGL 3.3. [vo/opengl/wayland] GL_VENDOR='Intel Open Source Technology Center' [vo/opengl/wayland] GL_RENDERER='Mesa DRI Intel(R) Sandybridge Mobile ' [vo/opengl/wayland] GL_SHADING_LANGUAGE_VERSION='3.30' [vo/opengl/wayland] Loaded extension GL_ARB_debug_output. [vo/opengl] swap_control extension missing. [vo/opengl] 16 bit texture depth: 16. [vo/opengl] retrieving framebuffer depth: OpenGL error INVALID_OPERATION. [vo/opengl] Reported display depth: R=-1, G=-1, B=-1 [vo/opengl] Testing FBO format 0x805b [vo/opengl] Create FBO: 16x16 (16x16) [vo/opengl] Using FBO format 0x805b. [vo/opengl] No advanced processing required. Enabling dumb mode. [vd] Container reported FPS: 23.976027 [vd] Codec list: [vd] lavc:h264 - H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 [vd] Opening video decoder lavc:h264 [vd] Using software decoding. [vd] Detected 4 logical cores. [vd] Requesting 5 threads for decoding. [vd] Selected video codec: H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 [lavc:h264] [ad] Codec list: [ad] lavc:aac - AAC (Advanced Audio Coding) [ad] lavc:aac_fixed (aac) - AAC (Advanced Audio Coding) [ad] Opening audio decoder lavc:aac [ad] Requesting 1 threads for decoding. [ad] Selected audio codec: AAC (Advanced Audio Coding) [lavc:aac] [cplayer] Starting playback... [af] Audio filter chain: [af] [in] 48000Hz stereo 2ch floatp [af] [out] 48000Hz stereo 2ch floatp [af] [ao] 48000Hz stereo 2ch floatp [ao] Trying audio driver 'pulse' [ao/pulse] requested format: 48000 Hz, stereo channels, floatp [ao/pulse] Library version: 9.0.0 [ao/pulse] Proto: 31 [ao/pulse] Server proto: 4294967295 [ao/pulse] Channel layouts: [ao/pulse] - #fl [ao/pulse] - #fr [ao/pulse] - #fc [ao/pulse] - #lfe [ao/pulse] - #bl [ao/pulse] - #br [ao/pulse] - #flc [ao/pulse] - #frc [ao/pulse] - #bc [ao/pulse] - #sl [ao/pulse] - #sr [ao/pulse] - #tc [ao/pulse] - #tfl [ao/pulse] - #tfc [ao/pulse] - #tfr [ao/pulse] - #tbl [ao/pulse] - #tbc [ao/pulse] - #tbr [ao/pulse] result: stereo [ao/pulse] device buffer: 6000 samples. [ao/pulse] using soft-buffer of 9600 samples. [cplayer] AO: [pulse] 48000Hz stereo 2ch float [cplayer] AO: Description: PulseAudio audio output [af] Adding filter lavrresample [af] Audio filter chain: [af] [in] 48000Hz stereo 2ch floatp [af] [lavrresample] 48000Hz stereo 2ch float [a] [af] [out] 48000Hz stereo 2ch float [af] [ao] 48000Hz stereo 2ch float [vd] Decoder format: 1920x800 yuv420p bt.709/limited CL=mpeg2/4/h264 [vf] Video filter chain: [vf] [in] 1920x800 yuv420p bt.709/limited CL=mpeg2/4/h264 [vf] [out] 1920x800 yuv420p bt.709/limited CL=mpeg2/4/h264 [cplayer] VO: [opengl] 1920x800 yuv420p [cplayer] VO: Description: Extended OpenGL Renderer [vo/opengl] Resize: 1920x800 [vo/opengl] Window size: 1920x800 [vo/opengl] Video source: 1920x800 (1:1) [vo/opengl] Video display: (0, 0) 1920x800 -> (0, 0) 1920x800 [vo/opengl] Video scale: 1.000000/1.000000 [vo/opengl] OSD borders: l=0 t=0 r=0 b=0 [vo/opengl] Video borders: l=0 t=0 r=0 b=0 [vo/opengl] Testing FBO format 0x805b [vo/opengl] Create FBO: 16x16 (16x16) [vo/opengl] Using FBO format 0x805b. [vo/opengl] No advanced processing required. Enabling dumb mode. [vo/opengl] Texture for plane 0: 1920x800 [vo/opengl] Texture for plane 1: 960x400 [vo/opengl] Texture for plane 2: 960x400 [vo/opengl/wayland] resizing 0x0 -> 1920x800 [vo/opengl] Resize: 1920x800 [vo/opengl] Window size: 1920x800 [vo/opengl] Video source: 1920x800 (1:1) [vo/opengl] Video display: (0, 0) 1920x800 -> (0, 0) 1920x800 [vo/opengl] Video scale: 1.000000/1.000000 [vo/opengl] OSD borders: l=0 t=0 r=0 b=0 [vo/opengl] Video borders: l=0 t=0 r=0 b=0 [cplayer] set video colors output-levels=0 [vo/opengl] recompiling a shader program: [vo/opengl] [ 1] color.r = 1.000000 * vec4(texture(texture0, texcoord0)).r; [vo/opengl] [ 2] color.g = 1.000000 * vec4(texture(texture1, texcoord1)).r; [vo/opengl] [ 3] color.b = 1.000000 * vec4(texture(texture2, texcoord2)).r; [vo/opengl] [ 4] // color conversion [vo/opengl] [ 5] color.rgb = mat3(colormatrix) * color.rgb + colormatrix_c; [vo/opengl] [ 6] color.a = 1.0; [vo/opengl] [ 7] // color mapping [osd/libass] fontselect: (sans-serif, 400, 0) -> /usr/share/fonts/TTF/DejaVuSans.ttf, 0, DejaVuSans [cplayer] first video frame after restart shown [cplayer] starting audio playback [cplayer] playback restart complete [statusline] AV: 00:00:00 / 02:18:06 (0%) A-V: 0.000 [vo/opengl/wayland] resizing 1920x800 -> 1920x800 [vo/opengl] Resize: 1920x800 [vo/opengl] Window size: 1920x800 [vo/opengl] Video source: 1920x800 (1:1) [vo/opengl] Video display: (0, 0) 1920x800 -> (0, 0) 1920x800 [vo/opengl] Video scale: 1.000000/1.000000 [vo/opengl] OSD borders: l=0 t=0 r=0 b=0 [vo/opengl] Video borders: l=0 t=0 r=0 b=0 [vo/opengl] Assuming 60.103001 FPS for display sync. [statusline] AV: 00:00:00 / 02:18:06 (0%) A-V: 0.000 [cplayer] Run command: quit, flags=9, args=[0] [cplayer] EOF code: 6
[ad] Uninit audio decoder. [af] Removing filter lavrresample [vd] Uninit video. [cplayer] finished playback, success (reason 3) [cplayer] [cplayer] [cplayer] Exiting... (Quit) [ytdl_hook] Exiting... [osc] Exiting... [ao/pulse] draining... [vo/opengl] flushing shader cache

[ogbaba]

I have the same issue on fedora 25 beta using wayland

[goggle]

I'm having the same issue, but I like it somehow. Maybe this could be implemented as feature? Could this even be done in mpv, or is this window manager stuff?

[MattiHameister]

See #139

As a workaround you could use the x11egl backend (i.e. --vo=opengl-hq:backend=x11egl). After that mpv runs through XWayland with title and borders.

[victornoel]

+1 also, now, we can't drag and drop subtitles on the mpv window anymore, it simply doesn't work with wayland.

[victornoel]

(and with vo=opengl-hq:backend=x11egl, the window is normal, but drag and dropping subtitles doesn't work either btw)

[simonbcn]

Same problem on Arch Linux with Gnome Shell 3.22

139 haslabel: wontfix! :cry:

[ghost]

Duplicate of the wontfix issue, it seems. You could try to convince the gnome devs to add server-side decorations for programs which won't do client-side decorations.

[abrouwers]

Thanks for the consideration. I'm a bit surprised, given that this will be broken behavior for all gnome 3.22 distribution releases during the coming 6 months.

[ghost]

Btw. if @atomnuker wants to, we could implement some sort of 1-pixel window border. But we definitely won't get into the rabbit hole of trying to look "native" on every single wayland compositor.

[haasn]

^ inconsistent applications are a Wayland design choice, so I don't see why we would have to

[MattiHameister]

@wm4 As far as I know even on KDE you have to ask KWin for a decoration. https://bugs.kde.org/show_bug.cgi?id=368389#c2

So "just wait for others to change their mind" could take a very long time... A time where mpv is pretty unusable. You are not alone with this. SDL has the same problem but I think most SDL2 applications run at fullscreen. -> https://bugzilla.libsdl.org/show_bug.cgi?id=2710

So my suggestion is to disable Wayland by default (make it "opt-in", use X11egl on Wayland) as long as there is no fix in every Wayland Compositor ... or implement a window border.

[ghost]

In my view, the opposite is more valid: if someone really wants a border they can use the x11 backends. I believe complaints will eventually get resolved by the compositor/interfaces and I don't mind mpv getting issues about missing window borders as those are easy to answer. What I do mind is mpv getting issues from the type of "performance with the Wayland VO is worse than X11" to which the answer could be "use the Wayland backend" or "it's a bug in mpv" after troubleshooting. So either way, direct your complaints to the Gnome people. KDE chose to use server-side decorations, so you don't have to ask the compositor anything (other than for it to work, last I checked mpv crashes when ran with KDE/kwin running in Wayland".

[MattiHameister]

@atomnuker

Well, the entry from the KDE bug tracker says that KDE does not use server-side decoration by default (SDL does not get decorations under kwin) and "SDL could implement" their interface to get the decorations. The entry is just a month old.

Or am I missing something here?

[minexew]

Ok, so it's a wayland/gnome/whoever issue. But you get this broken behavior by default e.g. on F25 when you build mpv from sources and don't specify any config or other arguments. Why is broken behavior the default?

[ghost]

Why is broken behavior the default?

Isn't that normal with wayland?

[minexew]

Mpv does a disservice to its users by defaulting to wayland without any window decorations.

[CounterPillow]

No, that's actually your wayland compositor doing that disservice.

[abrouwers]

I understand the reason, but MPV is the only application doing it in my installation. It's annoying, but technically understandable. It's going to be the experience everyone on gnome gets moving forward, since wayland is the default.

On Sat, Dec 10, 2016 at 12:11 PM, Nicolas F. notifications@github.com wrote:

No, that's actually your wayland compositor doing that disservice.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mpv-player/mpv/issues/3646#issuecomment-266223313, or mute the thread https://github.com/notifications/unsubscribe-auth/AAB1cYp_lAm8pZO9bR9h5c3osNpg3x9uks5rGt08gaJpZM4KSc8y .

[CounterPillow]

All the more reason to yell at the GNOME people then.

[haasn]

I suspect that with some time, wayland compositors will start drawing decorations again. Give it time I suppose.

[antonov-impulsm]

I suspect that with some time, wayland compositors will start drawing decorations again. Give it time I suppose.

i suspect that when Wayland will gained popularity: people will be replaced MPV (the only application that refused to implement window management) by another good video player application..

it is not badly! each program has its own life cycle. MPV will be remembered as an excellent player! and will remember people did a great job

[ghost]

@antonov-impulsm please go be a shitty asshole somewhere else.

[CounterPillow]

Since people still seem confused as tho whose issue this is, here's a summary for dummies:

mpv relies on the windowing server (e.g. X11) to provide it with window decorations, which is how basically every other operating system does it. In other words, macOS/OS X and Windows both provide this service to mpv, as does X11. These window decorations can be drawn either server-side (by the compositor/display server) or client-side (by the application), the important part is that something other than the application itself is able to provide them. This means mpv does not have to use an entire GUI toolkit for window borders or implement its own massive logic to have a native-looking border drawn.

Wayland developers, however, have decided that server-side decorations will not be part of the Wayland protocol. As far as I could tell from conversations, they did so because they believe every application (be it a video player, or a video game, or your OpenGL hello world rotating triangle) should be using a GUI toolkit, even if they only use it to draw borders. They've gone as far as banning all discussion of server-side decorations in their IRC channel. Wayland thus goes against not only what application developers (i.e., one part of the consumers of their protocol) want, but also what users need.

The burden to fix this situation thus lies with the developers of Wayland compositors, who need to specify a new cross-vendor extension protocol for applications to request server-side decorations, which will work alongside Wayland. However, the only people seemingly willing to work on this have been KDE so far, and their two proposals have, from what I've heard, been ridiculously over-engineered dbus-based solutions.

As more distributions switch to Wayland by default, the usability issues in the ecosystem will become apparent to more people, hence hopefully more cross-vendor interest will exist in fixing these issues in a future-proof and sane way. Props to KDE for trying, but ideally they'd have some input from other ecosystems.

Asking mpv to replicate all of GTK or Qt's logic in determining how the user has configured their compositor's styling is simply too much to ask, since it would add fragile and complex code just to support one platform with a marginal amount of users compared to X11 + macOS + Windows users.

[antonov-impulsm]

ohhh... nobody not wait that MPV -- will implement complex logic from GUI toolkits (GTK/Qt) :-) ..

fact -- MPV violates the wayland-protocol. by wayland-protocol -- application must implement window-decorations, but MPV not implements it.

therefore it is quite clear -- on whose side issue.

next...

"native-looking border" -- not needed for MPV, because MPV already looks as not native application :-) due own non-native button-controls and other-own control-elements . (and plus non-native looking window-border -- will not change this for the worst)

it would be nice to see only the minimal functional (vary simple, without native style of GTK/QT). only ugly-style black-colour rect for move and resize window. it's enough (for example https://bugzilla-attachments.libsdl.org/attachment.cgi?id=2605 )

[haasn]

As more distributions switch to Wayland by default, the usability issues in the ecosystem will become apparent to more people, hence hopefully more cross-vendor interest will exist in fixing these issues in a future-proof and sane way. Props to KDE for trying, but ideally they'd have some input from other ecosystems.

Never mind the fact that CSDs are far from the only usability issue with Wayland, due to it not supporting a host of other features we've come to expect from a modern OS (gestures, hotkeys, screensaver inhibition, screen recording, etc.), with the developers consistently shooting down extension proposals for these things. My personal guess is that GNOME and KDE people will just start ignoring the rest of the world and implementing their own hacky or NIH solutions for all of this, and then we'll end up with another glorious 10-20 years of everybody doing things their own way with nothing being compatible with anything else; except now possibly even worse than under X11.

[ghost]

everybody doing things their own way with nothing being compatible with anything else

And yet your beloved nvidia did just that to half-ass wayland support. Worse in fact. (to get facts straight, gestures, hotkeys, screen recording is all already sorted out in the wayland API or is up to the compositor, screensaver inhibition is WIP, but don't let that stop you from skipping how nvidia doesn't properly support it, you fanboy).

Point is, things will get sorted out, it just takes time. That's probably why redhat made gnome launch with wayland by default - to quicken the transition by getting more testing out of it.

[Hrxn]

Please.. let's just skip the flame war part, okay?

We all can agree that Wayland is not fully ready for the prime time yet, but things are on its way, right?

[Sunderland93]

@antonov-impulsm do you tried out gnome-mpv frontend in Wayland-session?

[simonbcn]

all mpv frontends can't use wayland backend, only wayland.

[antonov-impulsm]

@antonov-impulsm do you tried out gnome-mpv frontend in Wayland-session?

no, but last night i run again MPV on Wayland (GNOME) and was surprised that MPV works perfectly. :-)

windows-border (window-decoraton) absent. but window moving (via mouse left-button, or "SUPER" key + left mouse button) -- works. window resizing (via "SUPER" key + middle mouse button) -- work good. windows closing (via "Q" key) -- works.

and in general, i now agree that this bug (#3646) may not be fixed :-)

[Sunderland93]

no, but last night i run again MPV on Wayland (GNOME) and was surprised that MPV works perfectly. :-)

But gnome-mpv works fine

[swamp-fish]

i run again MPV on Wayland (GNOME) and was surprised that MPV works perfectly. :-) windows-border (window-decoraton) absent.

You do know what this bug is about don't you? How is it even perfect? Its a shame developers don't care hopefully others will take care of it.

[JasonWoof]

Looks like Wayland finally decided to support server-side decorations:

https://www.phoronix.com/scan.php?page=news_item&px=Wayland-Protocols-1.15 https://lists.freedesktop.org/archives/wayland-devel/2018-July/038831.html

It'll probably be quite a while before it works in practice. But at least things are moving in that direction.

[ssokolow]

Unfortunately, when the existing stakeholders (KDE and Sway) reached out to GNOME, their response could be distilled down to "RESO WONTFIX: We already told you. Use CSDs."

The mutter issue has been closed and, since Wayland must also support desktopless uses like In-vehicle Infotainment systems, the decoration protocol must remain optional.

As an end-user who cares about having consistent window decorations, I've more or less resigned myself to the Arcan developer's approach to ensuring everything gets SSDs in an SSD-capable compositor:

I’ll automatically detect where the top bar is, crop it out and hide it inside a titlebar toggle in the server side defined titlebar where I have the stuff that I want to be able to do to the client. There is practically nothing GTK, or anyone else for that matter, can do to counter that.

[Paianni]

I have a long term solution to this sort of issue - 'unify' the frontends as sub-components of the mpv project, and make the project names consistent. mpv for Android would remain as is, Celluloid would become mpv for GNOME, IINA would become mpv for Mac and mpv.net would become mpv for Windows.

This way, the core mpv project itself can focus on the backend, whilst the client-facing website can promote the virtues of a project that conforms to the HIG of more desktop environments than any other 'player' I can think of.

[CounterPillow]

@Paianni this issue has been resolved by wayland having a standardised server-side-decorations protocol, and every compositor that wants it has implemented it. Compositors that don't want it will have to live with their choices. There's no need to play ideas guy in this issue, especially with suggestions as vague and disconnected from development as that.

[Paianni]

@Paianni this issue has been resolved by wayland having a standardised server-side-decorations protocol, and every compositor that wants it has implemented it. Compositors that don't want it will have to live with their choices. There's no need to play ideas guy in this issue, especially with suggestions as vague and disconnected from development as that.

Is there an appropriate forum for non-development related discourse?

[Hrxn]

#mpv on irc.freenode.net, probably..

[aik]

Fedora 36, Wayland 1.20, mpv 0.34.1, still not borders, is the problem still in Wayland? Just wondering as allegedly Wayland has decorations protocol implemented in 1.15.

[ssokolow]

Fedora 36, Wayland 1.20, mpv 0.34.1, still not borders, is the problem still in Wayland? Just wondering as allegedly Wayland has decorations protocol implemented in 1.15.

Because Wayland is a protocol, like X11, rather than an implementation like X.org, the decorations protocol must be implemented separately in each compositor.

If you're on GNOME, that's their fault for refusing to implement the decorations protocol.

[developer91234]

Good decision. This is 100% a problem that Gnome self-conciously created to compel non-GTK devs to move to CSD. The fewer people play along the better. Maybe once half the apps on Gnome Wayland are visiby broken Gnome will learn its lesson.

[kcohar]

Good decision. This is 100% a problem that Gnome self-conciously created to compel non-GTK devs to move to CSD. The fewer people play along the better. Maybe once half the apps on Gnome Wayland are visiby broken Gnome will learn its lesson.

Suffice it to say, this comment hasn't aged well - the only problems I've seen have been with modern qt6 apps lately, but even they have titlebars. The only app that looks completely out of place on my desktop is mpv, but it's also faster and smoother than celluloid, doesn't "skip" when going into full screen mode (like celluloid does), and supports proper hardware acceleration (unlike Totem? and Clapper, or I just haven't set those up properly), not just through Xwayland (like VLC).

Also... what's with this devotion to server side decorations? mpv could be made to look great on GNOME, like a faster/smoother/hardware accelerated version of Clapper.

[ssokolow]

Also... what's with this devotion to server side decorations? mpv could be made to look great on GNOME, like a faster/smoother/hardware accelerated version of Clapper.

1. It makes little sense to require every application/toolkit to take responsibility for sourcing or implementing something that should come standard with the desktop.
2. Server-side decorations continue working when an overloaded application is too busy to service its event queue. (I've seen this go bad so much on Windows)
3. Server-side decorations ensure consistent access to special features of the window manager, such as the extra buttons and context menu offerings KWin provides, or the ability to merge multiple independent windows into a single tabbed window at the WM level like Fluxbox offers and KWin 4 offered for a relatively brief period before KWin 5 showed up and flushed away a ton of features.

By contrast, the only advantage to GNOME refusing to implement the Wayland extension for negotiating server-side decorations is that GNOME isn't forced to address Mutter's architectural failings.

It's basically the window management equivalent of how every MS-DOS application came with its own bundle of sound card drivers for want of a system-level audio driver interface.