Le Fri, Jul 26, 2024 at 08:49:49PM -0400, José Maldonado a écrit : > El vie, 26 jul 2024 a la(s) 8:56 a.m., Landry Breuil > (lan...@openbsd.org) escribió: > > > > > There are numerous issues that will need to be fixed before va-api in > > > firefox will actually work. Some of them are pledge/unveil related, > > > others are firefox hardcoding specific library versions for dlopen > > > without fallback. > > > > thanks tb for looking into that :) > > > > > With the symlinks below and various additions to pledge and unveil, > > > I get sound to play in what looks like hardware decoded video. > > > Unfortunately, the player remains dark... > > > > the symlinks shouldnt be needed in all cases, because in the code i can > > find that wraps ffmpeg and tries to load the libva libs > > (https://searchfox.org/mozilla-central/source/dom/media/platforms/ffmpeg/FFmpegLibWrapper.cpp#366) > > and the libgbm libs > > (https://searchfox.org/mozilla-central/source/third_party/gbm/libgbm/mozgbm.cpp#31), > > (and maybe others ? havent seen libxaw in the source code) > > it uses nspr's PR_LoadLibraryWithFlags() which is patched to drop what's > > after the .so (cf > > https://github.com/openbsd/ports/blob/master/devel/nspr/patches/patch-nspr_pr_src_linking_prlink_c#L32) > > > > In my case, I am trying Firefox 128 from packages, and ffmpeg with > VAAPI patches and obtain VAAPI hwaccel with this changes
thanks, that's a start, because it makes us understand what files are opened by which process. But you do realize this adds lots of capacities to those process types that arent needed right now, thus shouldnt be added. The right process is to figure out _what_ codepaths open those libs/paths, and try to move those initializations *before* sandboxing, so that adding those capacities isnt needed. Preloading libs before sandboxing is a trick that has been done before (cf https://phabricator.services.mozilla.com/D193353 / https://bugzilla.mozilla.org/show_bug.cgi?id=1856301) now we need to add a bit more libs, make sure subsequent dlopens finds the preloaded lib, and do the same for the drm device fd. Right now wpath is needed because it tries to open /dev/dri/renderD128 read-write after sandboxing, doing that before sandboxing is the way to go. > On the other hand, there is one additional positive point in creating > the libgbm and libdrm symlinks (or patch hardcode name for this libs > in Firefox): enabling general DMAbuf support for Firefox which is > broken due to the library versioning not matching. creating the symlinks is a big no :) fixing hardcoded versions is easy, and upstreaming that is generally welcome. > If I'm not mistaken this leaves us with two things: > > 1.- Apply the patches you mentioned to pre-load libva and VAAPI > support without many changes in unveil/pledge, but I don't think this > enables full DRM and DMAbuf support for Firefox. that's a work in progress. we'll see if we get somewhere. If you want to help, try the patches in my branch (eg https://cgit.rhaalovely.net/mozilla-firefox/log/patches?h=vaapi) and if they dont work, start from that and move the code around... https://searchfox.org is a great tool to find codepaths/callers/etc. > 2.- Apply a patch to change the library lookup to match OpenBSD > versioning or directly make the symlinks and pledge/unveil settings so > that everything works as it is. i think you haven't been long enough in the openbsd community ;) if it's not done 'right', it's not done.
