X11 VAAPI depends on Wayland
Categories
(Core :: Widget: Gtk, enhancement, P5)
Tracking
()
People
(Reporter: dylan.araps, Unassigned)
References
(Blocks 1 open bug)
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:80.0) Gecko/20100101 Firefox/80.0
Steps to reproduce:
Tried to build Firefox with X11 VAAPI support without the presence of Wayland in the system.
Actual results:
X11 VAAPI support not enabled as it is behind MOZ_WAYLAND ifdefs and depends on Wayland?
Expected results:
X11 VAAPI support should work without Wayland.
|
Reporter | |
Comment 1•4 years ago
|
||
My comment in the X11 VAAPI thread:
X11 VAAPI support seems to behind the MOZ_WAYLAND ifdefs and is not available when built in an environment which does not contain gtk+3 and > mesa built with wayland support and further does not contain 'wayland' and 'wayland-protocols'. In other words, compiling Firefox on a Xorg only > system does not result in the X11 VAAPI code being included the resulting binary. This code doesn't exist in the resulting binary as all the wayland > stuff isn't present.
Will this be decoupled from MOZ_WAYLAND in the future? I find it odd that the X11 support requires Wayland.
|
||
Updated•4 years ago
|
|
|
||
Comment 2•4 years ago
|
||
IMHO current behavior is useful and makes transition from XWayland to Wayland easier. Standalone X11 is legacy.
|
||
Comment 4•4 years ago
|
||
(In reply to Darkspirit, Servo QA from comment #2)
IMHO current behavior is useful and makes transition from XWayland to Wayland easier. Standalone X11 is legacy.
Shouldn't you keep such blanket statements for when it's actually the universal default among all major distros and when Firefox is able to at least query correct frame-rate, have VSync and playback HDR content ? And that isn't happening any rime soon. Not until https://bugzilla.mozilla.org/show_bug.cgi?id=1640779 and https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14
But what is happening are releases with regressions for GPU rendering such as v80 with WebRender slowdown on Intel and immediate crashes on AMD with current F/OSS drivers which requires going to "Basic".
For now, you're just playing in your little pool that does not include majority of your users. Not even ones that left after Google's web takeover. How about achieving parity with Flash from year 2010 (yes, I've checked exact release time for GPU offloading) before going for things that almost no one is able to use in practice yet ?
|
||
Comment 5•4 years ago
|
||
(In reply to Sergey Kondakov from comment #4)
(In reply to Darkspirit, Servo QA from comment #2)
IMHO current behavior is useful and makes transition from XWayland to Wayland easier. Standalone X11 is legacy.
Shouldn't you keep such blanket statements for when it's actually the universal default among all major distros and when Firefox is able to at least query correct frame-rate, have VSync and playback HDR content ? And that isn't happening any rime soon. Not until https://bugzilla.mozilla.org/show_bug.cgi?id=1640779 and https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14
But what is happening are releases with regressions for GPU rendering such as v80 with WebRender slowdown on Intel and immediate crashes on AMD with current F/OSS drivers which requires going to "Basic".For now, you're just playing in your little pool that does not include majority of your users. Not even ones that left after Google's web takeover. How about achieving parity with Flash from year 2010 (yes, I've checked exact release time for GPU offloading) before going for things that almost no one is able to use in practice yet ?
Please see my comment 3, the request is not declined.
|
|
||
Comment 6•4 years ago
|
||
(In reply to Martin Stránský [:stransky] from comment #5)
(In reply to Sergey Kondakov from comment #4)
(In reply to Darkspirit, Servo QA from comment #2)
…
Please see my comment 3, the request is not declined.
Sure. But my point is that your priorities are wrong based on flawed justification.
I wish that you were right because I also not a fan of dealing with X11 cruft, especially broken-by-design things like non-realtime configuration, protocol-level issues with proper frame-time controls and colour management per output, https://gitlab.freedesktop.org/xorg/xserver/issues/253 and https://gitlab.freedesktop.org/xorg/xserver/-/issues/258
But we just are not there yet and, AFAIK, no current Wayland-based configuration has those fixed either.
|
|
||
Comment 7•4 years ago
|
||
(In reply to Sergey Kondakov from comment #4)
such as v80 with WebRender slowdown on Intel and immediate crashes on AMD with current F/OSS drivers which requires going to "Basic".
Please check if these problems have been fixed in https://nightly.mozilla.org, otherwise report bugs for each if there aren't any existing. It doesn't really ring a bell for me. Thanks! Could you mean bug 1661441? bug 1640779 affects Wayland and X11, but there is an experimental implementation for Wayland: bug 1629140
|
||
Comment 8•4 years ago
|
||
(In reply to Sergey Kondakov from comment #6)
Sure. But my point is that your priorities are wrong based on flawed justification.
Note: that's your opinion.
AFAIK building X11 only is a small niche case by now as the major distributions don't do that. Further more: what's even the advantage? Slightly smaller binaries, a few small dependencies less, barely noticeable faster build time? Why do you think that should be the priority, in contrast to working on the bigger issues you mentioned above?
|
|
||
Comment 9•4 years ago
|
||
(In reply to Darkspirit, Servo QA from comment #7)
(In reply to Sergey Kondakov from comment #4)
such as v80 with WebRender slowdown on Intel and immediate crashes on AMD with current F/OSS drivers which requires going to "Basic".
Please check if these problems have been fixed in https://nightly.mozilla.org, otherwise report bugs for each if there aren't any existing. It doesn't really ring a bell for me. Thanks! Could you mean bug 1661441? bug 1640779 affects Wayland and X11, but there is an experimental implementation for Wayland: bug 1629140
I've read about recent Intel slowdown in some of those EGL/VAAPI/VSync-relevant bugs but can't find it now. However, I've figured out what triggered segfaults on startup with my Radeon RX580: for some reason FF 80 and TB 68.12.0 decided that they no longer like for WebRender to work when mesa_glthread=true with Mesa 20.1.7. Making exception in ~/.drirc for them allowed them to run as normal. TB also has multi-threading (browser.tabs.remote) broken now for some reason: mail view does not render with it active.
I run my build from https://build.opensuse.org/package/show/home:X0F:HSF/MozillaFirefox with custom default preferences, trying external binaries is not a good idea under properly packaged distro, especially with the thing that likes to occassionally nuke sessions on updates and block session backup manager extensions from working properly due to webextension deficiencies.
I've read that VAAPI is broken on v80 but it was not the cause of crash. I enabled it and/or ffmpeg's dmabuf after working around the crash and indeed it was drawing garbage instead of Youtube player. So, as it's known, I will wait for a new release.
As of VSync: AFAIK, FF & TB has never used correct frame-rate on Linux, despite numerous GL extensions for it. I don't really know how situation is with that on EGL but Vulkan apps do not seem to have a problem. Is it really all depends on an unofficial and non-merged extension draft for EGL ?
Unfortunately, using Wayland requires a proper Wayland session and KDE is not in a good shape in that regard, despite also dropping any improvement for X11 kwin version for years in favour of "better future" which never arrived. Such as:
https://www.phoronix.com/scan.php?page=news_item&px=KDE-KWin-On-Vulkan-Experimental
https://phabricator.kde.org/T11071
And it's own half-baked glitchy EGL backend (enabled with KWIN_OPENGL_INTERFACE=egl or GLPlatformInterface=egl in kwinrc).
And even if it was on par with X11 on VSync and latency, Wayland colour correction mechanism is not even defined yet, so it can't be implemented even if DE devs were on bleeding edge and made it immediately while X11 has one, even if it works on crutches and snots. X11 is also can be patched to report proper DPI, as you can see in linked bug, not sure how things on Wayland with that.
However, both Qt and GTK refuse to use that real DPI value by default, Qt/KDE can be forced with https://wiki.archlinux.org/index.php/HiDPI#KDE_Plasma but GTK refuses to actually query proper values, so FF & TB are stuck with manual hardcoding.
(In reply to Robert Mader [:rmader] (on PTO) from comment #8)
(In reply to Sergey Kondakov from comment #6)
Sure. But my point is that your priorities are wrong based on flawed justification.
Note: that's your opinion.
AFAIK building X11 only is a small niche case by now as the major distributions don't do that. Further more: what's even the advantage? Slightly smaller binaries, a few small dependencies less, barely noticeable faster build time? Why do you think that should be the priority, in contrast to working on the bigger issues you mentioned above?
I only urge you from repeating kwin's fate of abandoning one >90% working solution in favour of perpetual <90% one which may lead to such sudden breakages as my segfault after update due to lack of regression testing or something. Not being a priority doesn't equate to complete disregard. Are you sure that it's only build-time check and there is nothing in runtime ?
Even if it is, it doesn't make those Wayland compositors complete. I certainly can't migrate on one, unless I'm missing something that can actually surpass kwin_x11-lowlatency fork on my DPI-patched X11 with proper colour profiles for all my 3 different displays (one of which is CRT with >10 times better contrast and widest gamut) via colord/lcms2/DisplayCAL (later is dead now because of python2 dependency). Wayland session is just not there for any Wayland app to run on par and the only major things that it could bring, proper decoupled per-output rendering and colour correction, are still theories that have no implementation in compositors. At best, you will still be stuck with broken DPI due to GTK even on Wayland due to ridiculous "like-Windows" 96dpi hardcoding fad (see bug 1373607 and above Arch wiki link).
So, having Wayland support is nice but don't think that it what's most people on Linux would actually be running until its compositors can at least match X11's zombie. And you should be migrating to Vulkan & WebGPU from OpenGL/D3D & WebGL ASAP anyway too, as later are as obsolete as X11.
|
||
Comment 10•4 years ago
|
||
(In reply to Sergey Kondakov from comment #9)
This bug is not about requiring Wayland as a UI subsystem, but merely about requiring GTK built with Wayland support. That's a minor nuisance, not a showstopper. Actual decision on what Firefox is going to use is made at run time, so even if you build Firefox with Wayland support, it will still run fine on X.Org.
So, for a workaround, recompile GTK with Wayland support. That should suffice for now. Or just use prebuilt binaries from Mozilla FTP.
As for discussions about current EGL state (bugs, instability, features), I believe that bug 788319 is a more relevant place.
|
|
||
Comment 11•4 years ago
|
||
It may be fairly easy to patch Firefox build system, you just need to make sure libdrm >= 2.4 is available on X11, see:
https://searchfox.org/mozilla-central/source/toolkit/moz.configure#279
You may also remove MOZ_WAYLAND from the related code parts and build DMABufSurface.* and DMABufLibWrapper.* by default.
I will happily reviews such patches.
|
|
||
Comment 12•4 years ago
|
||
(In reply to Rinat from comment #10)
(In reply to Sergey Kondakov from comment #9)
This bug is not about requiring Wayland as a UI subsystem, but merely about requiring GTK built with Wayland support. That's a minor nuisance, not a showstopper. Actual decision on what Firefox is going to use is made at run time, so even if you build Firefox with Wayland support, it will still run fine on X.Org.
So, for a workaround, recompile GTK with Wayland support. That should suffice for now. Or just use prebuilt binaries from Mozilla FTP.
As for discussions about current EGL state (bugs, instability, features), I believe that bug 788319 is a more relevant place.
Sure. And, of course, I build it all with Wayland, no point of not doing so unless on Gentoo. Can't reliably test it for normal use though, not with current state of compositors. Just was addressing "…transition from XWayland to Wayland easier. Standalone X11 is legacy", as if using W-apps on X or X-apps on W is a norm, to prevent propagation of assumption that can provoke breakage.
(In reply to Martin Stránský [:stransky] from comment #11)
It may be fairly easy to patch Firefox build system, you just need to make sure libdrm >= 2.4 is available on X11, see:
https://searchfox.org/mozilla-central/source/toolkit/moz.configure#279
You may also remove MOZ_WAYLAND from the related code parts and build DMABufSurface.* and DMABufLibWrapper.* by default.
I will happily reviews such patches.
One would think that touching FF & TB build system is not a big deal, like with most others, but then there is perpetually reoccurring bug 1202175 (also duplicates: bug 1209420, bug 1202175 and bug 1240379) which kills the build if EGL is explicitly requested and EGL is the requirement of all that good stuff. Yes, I know that it doesn't have to be explicitly requested, it supposed to be implicitly enabled when Wayland is requested but still… the whole thing is clunky and no one dares to finally address it for 5 years.
Speaking of EGL, I had to make custom package with git-snapshot for mesa-demos and proper satisfaction of optional dependencies which includes eglinfo just to track EGL state in Mesa drivers. I would assume that many if not most distros also have obsolete eglinfo that may misrepresent state of Mesa. Although, you seem to be right about lack of sync extensions unlike GLX, where are multiple so X compositors can even pick and choose. Not sure how Wayland compositors and apps are supposed to deal with that.
|
|
||
Updated•3 years ago
|
Description
•