left right assertion failures on intel/nvidia hybrid gpu laptop.

[Shinyzenith]

Hi! I tried running wl-screenrec on my hardware but I consistently get the following errors on both my NVIDIA card and my integrated intel gpu:

❯ ./wl-screenrec --dri-device /dev/dri/renderD129 -v
Using output eDP-1
[file @ 0x564a68e9ce00] Setting default whitelist 'file,crypto,data'
[AVHWDeviceContext @ 0x564a68e9d340] libva: VA-API version 1.18.0
[AVHWDeviceContext @ 0x564a68e9d340] libva: Trying to open /usr/lib/dri/iHD_drv_video.so
[AVHWDeviceContext @ 0x564a68e9d340] libva: va_openDriver() returns -1
[AVHWDeviceContext @ 0x564a68e9d340] libva: Trying to open /usr/lib/dri/i965_drv_video.so
[AVHWDeviceContext @ 0x564a68e9d340] libva: va_openDriver() returns -1
[AVHWDeviceContext @ 0x564a68e9d340] Failed to initialise VAAPI connection: -1 (unknown libva error).
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `-5`,
 right: `0`', src/avhw.rs:34:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[AVIOContext @ 0x564a68e9d180] Statistics: 0 bytes written, 0 seeks, 0 writeouts

If anyone can provide some context as to why this is occurring, I'd love to dig in deeper and provide more information.

[Shinyzenith]

The previous logs were from ArchLinux. I tried the same on NixOS on my Intel Iris Xe card laptop and I get the exact same error.

[russelltg]

Which GPU is renderD129? Could you post outputs of ls -lah /dev/dri/by-path, lspci, as well as vainfo? Also, does wf-recorder work in vaapi mode (wf-recorder -c h264_vaapi -d /dev/dri/renderD129)?

You cannot use vaapi on integrated nvidia graphics (or, I thought so, I had a hard time finding a reference that proved or disproved this), so I highly suggest you use the intel gpu for encode.

[Shinyzenith]

Which GPU is renderD129? Could you post outputs of ls -lah /dev/dri/by-path, lspci, as well as vainfo? Also, does wf-recorder work in vaapi mode (wf-recorder -c h264_vaapi -d /dev/dri/renderD129)?

I do not have that machine with me right now so I will provide the above details for the intel Iris Xe card I have. I'll report back with the logs from the hybrid machine when I have it available again.

~
❯ ls -lah /dev/dri/by-path
Permissions Size User Date Modified Name
lrwxrwxrwx@    8 root  3 Jul 20:57   pci-0000:00:02.0-card -> ../card0
lrwxrwxrwx    13 root  3 Jul 20:05   pci-0000:00:02.0-render -> ../renderD128

[nix-shell:~]$ lspci
00:00.0 Host bridge: Intel Corporation 11th Gen Core Processor Host Bridge/DRAM Registers (rev 01)
00:02.0 VGA compatible controller: Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] (rev 01)
00:04.0 Signal processing controller: Intel Corporation TigerLake-LP Dynamic Tuning Processor Participant (rev 01)
00:06.0 PCI bridge: Intel Corporation 11th Gen Core Processor PCIe Controller (rev 01)
00:0d.0 USB controller: Intel Corporation Tiger Lake-LP Thunderbolt 4 USB Controller (rev 01)
00:12.0 Serial controller: Intel Corporation Tiger Lake-LP Integrated Sensor Hub (rev 20)
00:14.0 USB controller: Intel Corporation Tiger Lake-LP USB 3.2 Gen 2x1 xHCI Host Controller (rev 20)
00:14.2 RAM memory: Intel Corporation Tiger Lake-LP Shared SRAM (rev 20)
00:14.3 Network controller: Intel Corporation Wi-Fi 6 AX201 (rev 20)
00:15.0 Serial bus controller: Intel Corporation Tiger Lake-LP Serial IO I2C Controller #0 (rev 20)
00:15.1 Serial bus controller: Intel Corporation Tiger Lake-LP Serial IO I2C Controller #1 (rev 20)
00:16.0 Communication controller: Intel Corporation Tiger Lake-LP Management Engine Interface (rev 20)
00:1c.0 PCI bridge: Intel Corporation Device a0be (rev 20)
00:1f.0 ISA bridge: Intel Corporation Tiger Lake-LP LPC Controller (rev 20)
00:1f.3 Multimedia audio controller: Intel Corporation Tiger Lake-LP Smart Sound Technology Audio Controller (rev 20)
00:1f.4 SMBus: Intel Corporation Tiger Lake-LP SMBus Controller (rev 20)
00:1f.5 Serial bus controller: Intel Corporation Tiger Lake-LP SPI Controller (rev 20)
01:00.0 Non-Volatile memory controller: Micron Technology Inc Device 5404 (rev 03)
02:00.0 SD Host controller: O2 Micro, Inc. SD/MMC Card Reader Controller (rev 01)

[nix-shell:~]$ vainfo
Trying display: wayland
libva info: VA-API version 1.18.0
libva info: Trying to open /run/opengl-driver/lib/dri/iHD_drv_video.so
libva info: Trying to open /usr/lib/dri/iHD_drv_video.so
libva info: Trying to open /usr/lib32/dri/iHD_drv_video.so
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Trying to open /usr/lib/i386-linux-gnu/dri/iHD_drv_video.so
libva info: va_openDriver() returns -1
libva info: Trying to open /run/opengl-driver/lib/dri/i965_drv_video.so
libva info: Trying to open /usr/lib/dri/i965_drv_video.so
libva info: Trying to open /usr/lib32/dri/i965_drv_video.so
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Trying to open /usr/lib/i386-linux-gnu/dri/i965_drv_video.so
libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit

[nix-shell:~]$ wf-recorder -c h264_vaapi -d /dev/dri/renderD128
selected region 0,0 0x0
[AVHWDeviceContext @ 0x7f4524005800] Failed to initialise VAAPI connection: -1 (unknown libva error).
Failed to create hw encoding device /dev/dri/renderD128:

[russelltg]

Yeah, so you do not have a functional libva installation--I suggest you follow your distributions documentation on vaapi.

[Shinyzenith]

Oh I didn't consider that. Thanks for taking a look. I'll try to setup vaapi, use wf-recorder to check if it's working and then try wl-screenrec again.

[Shinyzenith]

I have setup vaapi and wl-screenrec works now. Thanks. However the colors look "washed out" and the overall quality is a little blurry which is odd. I see there's an issue about this in the repo so I will take a look at that. Thanks for your help.

[russelltg]

Do they look overall worse than wf-recorder? Keep in mind the default bitrate is rather low, as this is what I like (I prefer small file sizes over high quality), but feel free to increase it with the --bitrate parameter

[Shinyzenith]

I'll try that! The colors are actually significantly better than wf recorder but the blurriness remains

[Shinyzenith]

Update: it looks like on passing --no-hw to force x264 does remove the color issue completely. However, does this practically remove all benefits of wl-screenrec? as we are using the CPU for encoding.