Le Sun, Jul 28, 2024 at 09:43:55AM +0200, Landry Breuil a écrit :
> 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
> > (landry@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.

with the latest version of the patchset, i have something that doesnt
crash, but fails to properly initialize vaapi:

[(null) 51070: Main Thread]: D/Dmabuf DMABufDevice::Configure()          
[(null) 51070: Main Thread]: D/Dmabuf Loading DMABuf system library libgbm.so ...    
[(null) 51070: Main Thread]: D/Dmabuf Using DRM device /dev/dri/renderD128           
[(null) 51070: Main Thread]: D/Dmabuf DMABuf is enabled   
drmfd preopened, fd=12
[(null) 51070: Main Thread]: D/OpenBSDSandbox /tmp: unveil(/tmp, rwc)              
[(null) 51070: Main Thread]: D/OpenBSDSandbox /etc/firefox/pledge.rdd: pledge(stdio rpath tmppath recvfd sendfd unix)          
[RDD 51070: MediaSupervisor #1]: D/FFmpegVideo FFMPEG: FFmpegVideoDecoder::FFmpegVideoDecoder MIME video/avc Codec ID 27    
[RDD 51070: MediaPDecoder #1]: D/FFmpegVideo FFMPEG: Initialising VA-API FFmpeg decoder   
[RDD 51070: MediaPDecoder #1]: D/FFmpegVideo FFMPEG:   codec h264 : H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10   
[RDD 51070: MediaPDecoder #1]: D/FFmpegVideo FFMPEG:   Can't get DRM VA-API display. 
[RDD 51070: MediaPDecoder #1]: D/FFmpegVideo FFMPEG:   Failed to create VA-API device context 

the gfxvars object isnt initialized yet, so it requires
MOZ_DRM_DEVICE=/dev/dri/renderD128 in the env to find the right device.

Landry