Consider archiving xf86-video-*

[Xi Ruoyao]

The KMS driver shipped in xorg-server already supports the acceleration for Xorg via Glamor. So when a GPU is supported by Mesa Gallium 3D, the KMS driver automatically supports Glamor acceleration.

For ATI/AMD:

• The GPUs supported by xf86-video-ati are all supported by Mesa (r300 or r600 drivers).
• The GPUs supported by xf86-video-amdgpu are all supported by Mesa (radeonsi driver).

For Intel:

• Everything after the "Grantsdale" chipset (910GL and 915GL/GV/G, launched in 2004) is supported by Mesa (i915, crocus, or iris drivers).
• The latest models (Alder Lake, Raptor Lake, and discrete Intel GPUs) are not supported by xf86-video-intel at all, but they are supported by KMS driver.
• The development of xf86-video-intel seems stopped.
• The only models supported by xf86-video-intel but not KMS are 845 - 865 chipsets. They were launched in 2001-2003.

For Nouveau:

• Everything after NV30 (Geforce FX 5xxx, launched in 2003) but not RTX 30/40 series is supported by Mesa.
• NV140 (Titan V and Quadro GV100) and NV160 (RTX 20 series and GTX 16 series) are supported by KMS, but not xf86-video-nouveau.
• The models supported by xf86-video-nouveau but not KMS are NV04 (RIVA TNT), NV10 (Geforce 256, Geforce 2, Geforce 4, Quadro, Quadro 2, Quadro 4), NV20 (Geforce 3, Geforce 4 Ti, Quadro DCC, Quadro 4, XBOX GPU). They were launched in 1999-2003.

For VMWare: The VMWare GPU is supported by Mesa (the svga driver).

For fbdev: Is it really tested for latest BLFS releases?

So the conclusions:

1. xf86-video-* do not provide more functionalities than the built-in KMS driver, except for very old GPUs. And I don't think people will like to build LFS on some pre-2004 systems...
2. If we'd keep xf86-video-*, we need to spend a lot of time to describe their rationale (i.e. why and when they are better than KMS). Or people can start to install drivers not really useful (for example, installing xf86-video-intel on Raptor Lake is completely useless).
3. With the maintenance effort liberated we can use it on some modern thing (like virglrender for QEMU).

To me it's the time to archive xf86-video-*. Or is there some reason we must keep them (or some of them)?

[ken@…]

I have used KMS ('modesetting') on intel haswell and skylake without obvious problems (distros moved to that for intel ages ago). On my AMD machine I use amdgpu because it means I can test what is in the book.

I have not used qemu in ages, and don't see myself using it anytime soon (lack of adequate hardware). But in the ticket for firefox-115esr #18220 I noted that on VMs mesa drivers are blacklisted because of [​​https://bugzilla.mozilla.org/show_bug.cgi?id=1815481] - not sure what, if any, difference that would make in practice, my memory says that when I last used qemu acceleration was not impressive. That firefox change seems to have gone in in 115.0b9.

[Tim Tassonis]

Well, /opt/X11/lib/xorg/modules/drivers/intel_drv.so is still pulled on all my Dell Laptops by Xorg. So, it seems, Xorg still defaults to those.

How would one go about replacing those with your "KMS driver" driver? I assume this is modesetting_drv.so? Xorg does not seem to prefer it, so why should we?

[Bruce Dubbs]

That's true for my AMD raedeon system also. I generally use:

$ cat /etc/X11/xorg.conf.d/videocard-0.conf 
Section "Device"
    Identifier  "Videocard0"
    Driver      "amdgpu"
    VendorName  "AMD"
    BoardName   "Radeon RX 550 640SP / RX 560/560X"
    #Option      "NoAccel" "true"
EndSection

If I remove that, I still get the system using the amdgpu driver: /opt/xorg/lib/xorg/modules/drivers/amdgpu_drv.so. The only drivers I have in that directory are amdgpu_drv.so and modesetting_drv.so.

I do have /opt/xorg/lib/dri/radeonsi_{dri,drv_video}.so.

Changing the above configuration file to Driver "radeonsi" causes xorg to crash:

[  8470.067] (II) LoadModule: "radeonsi"
[  8470.067] (WW) Warning, couldn't open module radeonsi
[  8470.067] (EE) Failed to load module "radeonsi" (module does not exist, 0)
[  8470.067] (EE) No drivers available.

So, how do I tell xorg to use radeonsi?

[ken@…]

Replying to Bruce Dubbs:

If I remove that, I still get the system using the amdgpu driver: /opt/xorg/lib/xorg/modules/drivers/amdgpu_drv.so. The only drivers I have in that directory are amdgpu_drv.so and modesetting_drv.so.

I do have /opt/xorg/lib/dri/radeonsi_{dri,drv_video}.so.

Changing the above configuration file to Driver "radeonsi" causes xorg to crash:

[  8470.067] (II) LoadModule: "radeonsi"
[  8470.067] (WW) Warning, couldn't open module radeonsi
[  8470.067] (EE) Failed to load module "radeonsi" (module does not exist, 0)
[  8470.067] (EE) No drivers available.

So, how do I tell xorg to use radeonsi?

You don't - radeonsi is within Mesa, the relevant options to specify to Xorg are amdgpu or modesetting. I'm not aware of how to interrogate the system to see which Mesa driver is in use - I normally use 'glxinfo -B' - I see a lot more detail if I use 'glxinfo -B -t | less' but not anything identifying which driver. I expect there might be some envvars to set before starting X which could say more about what Mesa is doing - maybe a LOT more.

[ken@…]

Possibly, 'glxinfo | grep -e OpenGL.vendor -e enderer' - I'm currently using amdgpu on 11.3, so it doesn't tell me anything unexpected, and renderer or Renderer seems to have different capitalization on different versions or drivers, but on Skylake with modesetting that shows I'm using the Mesa Intel(R) HD Graphics 530 (SKL GT2) driver.

[Tim Tassonis]

So, how can I try the modesetting driver, as it is not chosen by Xorg automatically?

[Bruce Dubbs]

Replying to ken@…:

Possibly, 'glxinfo | grep -e OpenGL.vendor -e enderer' - I'm currently using amdgpu on 11.3, so it doesn't tell me anything unexpected, and renderer or Renderer seems to have different capitalization on different versions or drivers, but on Skylake with modesetting that shows I'm using the Mesa Intel(R) HD Graphics 530 (SKL GT2) driver.

I removed all /opt/xorg/lib/xorg/modules/drivers/ files and all /etc/X11/xorg.conf.d/files and have:

$ glxinfo | grep vendor
server glx vendor string: SGI
client glx vendor string: Mesa Project and SGI
OpenGL vendor string: AMD

Checking for version:

server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
    Max core profile version: 4.6
    Max compat profile version: 4.6
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
OpenGL core profile version string: 4.6 (Core Profile) Mesa 23.1.2
OpenGL core profile shading language version string: 4.60
OpenGL version string: 4.6 (Compatibility Profile) Mesa 23.1.2
OpenGL shading language version string: 4.60
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 23.1.2
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
    GL_EXT_shader_group_vote, GL_EXT_shader_implicit_conversions, 

[Xi Ruoyao]

Xorg driver and Mesa driver do not map one-to-one.

[Xi Ruoyao]

Replying to Tim Tassonis:

Well, /opt/X11/lib/xorg/modules/drivers/intel_drv.so is still pulled on all my Dell Laptops by Xorg. So, it seems, Xorg still defaults to those.

How would one go about replacing those with your "KMS driver" driver? I assume this is modesetting_drv.so? Xorg does not seem to prefer it, so why should we?

But we already have

Note: This driver is for Intel integrated GPU, and a development version is needed to work properly with the latest hardware. This version is now one year old and has some problems. The “Kernel Modes Setting (KMS)” driver shipped along with Xorg Server is said to give better results.

in the book. And it just does not work for Alder Lake, Raptor Lake, or Intel discrete graphic cards, and I've not seen any development activities in one year so it's likely intel_drv should be considered dead.

[Xi Ruoyao]

Xorg searches for installed drivers automatically:

• If it cannot find the specific driver installed for the hardware (listed below), it first searches for fbdev (xf86-video-fbdev), which does not include any 2D or 3D acceleration.
• If that is not found, it searches for vesa (xf86-video-vesa), the generic driver, which handles a large number of chipsets but does not include any 2D or 3D acceleration.
• If vesa is not found, Xorg will fall back to kernel mode setting, which includes GLAMOR acceleration (see modesetting(4)).

So if we just remove any xf86-video-* from the book, the KMS driver will be used.

I think the approach should be "test if things work without the xf86-video-* driver for our graphic cards" during the 11.4 tagging process. If everything just works fine w/o any xf86-video-* packages, we can just archive them. Or if some of them are really needed, we can keep the subset.

[ken@…]

Replying to Tim Tassonis:

How would one go about replacing those with your "KMS driver" driver? I assume this is modesetting_drv.so?

If you are using startx, try renaming the intel driver so that it is not found (I normally add '.hidden' to the end of filenames for such exercises). Before that, perhaps look at the log in .local/share/xorg.

On my skylake, without the intel driver I have:

[    25.798] (==) Matched intel as autoconfigured driver 0
[    25.798] (==) Matched modesetting as autoconfigured driver 1
[    25.798] (==) Matched fbdev as autoconfigured driver 2
[    25.798] (==) Matched vesa as autoconfigured driver 3
[...]
[    25.798] (II) LoadModule: "intel"
[    25.798] (WW) Warning, couldn't open module intel
[    25.798] (EE) Failed to load module "intel" (module does not exist, 0)
[    25.798] (II) LoadModule: "modesetting"
[    25.798] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[    25.802] (II) Module modesetting: vendor="X.Org Foundation"
[    25.802]    compiled for 1.21.1.8, module version = 1.21.1
[    25.802]    Module class: X.Org Video Driver
[    25.802]    ABI class: X.Org Video Driver, version 25.2
[    25.802] (II) LoadModule: "fbdev"
[    25.802] (WW) Warning, couldn't open module fbdev
[    25.802] (EE) Failed to load module "fbdev" (module does not exist, 0)
[    25.802] (II) LoadModule: "vesa"
[    25.802] (WW) Warning, couldn't open module vesa
[    25.802] (EE) Failed to load module "vesa" (module does not exist, 0)
[    25.802] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[    25.802] (II) modeset(0): using drv /dev/dri/card0

As long as your current log shows that modesetting has been matched as a possible driver, and exists, you should be fine to try it.

[Bruce Dubbs]

I hid the video drivers as you suggested:

[ 29618.467] (==) Matched amdgpu as autoconfigured driver 0
[ 29618.467] (==) Matched ati as autoconfigured driver 1
[ 29618.467] (==) Matched modesetting as autoconfigured driver 2
[ 29618.467] (==) Matched fbdev as autoconfigured driver 3
[ 29618.467] (==) Matched vesa as autoconfigured driver 4
[ 29618.467] (==) Assigned the driver to the xf86ConfigLayout
[ 29618.467] (II) LoadModule: "amdgpu"
[ 29618.467] (WW) Warning, couldn't open module amdgpu
[ 29618.467] (EE) Failed to load module "amdgpu" (module does not exist, 0)
[ 29618.467] (II) LoadModule: "ati"
[ 29618.467] (WW) Warning, couldn't open module ati
[ 29618.467] (EE) Failed to load module "ati" (module does not exist, 0)
[ 29618.467] (II) LoadModule: "modesetting"
[ 29618.467] (WW) Warning, couldn't open module modesetting
[ 29618.467] (EE) Failed to load module "modesetting" (module does not exist, 0)
[ 29618.467] (II) LoadModule: "fbdev"
[ 29618.467] (WW) Warning, couldn't open module fbdev
[ 29618.467] (EE) Failed to load module "fbdev" (module does not exist, 0)
[ 29618.467] (II) LoadModule: "vesa"
[ 29618.467] (WW) Warning, couldn't open module vesa
[ 29618.467] (EE) Failed to load module "vesa" (module does not exist, 0)
[ 29618.467] (EE) No drivers available.
[ 29618.467] (EE)
Fatal server error:
[ 29618.467] (EE) no screens found(EE)

[Xi Ruoyao]

Replying to Bruce Dubbs:

I hid the video drivers as you suggested:

[ 29618.467] (==) Matched amdgpu as autoconfigured driver 0
[ 29618.467] (==) Matched ati as autoconfigured driver 1
[ 29618.467] (==) Matched modesetting as autoconfigured driver 2
[ 29618.467] (==) Matched fbdev as autoconfigured driver 3
[ 29618.467] (==) Matched vesa as autoconfigured driver 4
[ 29618.467] (==) Assigned the driver to the xf86ConfigLayout
[ 29618.467] (II) LoadModule: "amdgpu"
[ 29618.467] (WW) Warning, couldn't open module amdgpu
[ 29618.467] (EE) Failed to load module "amdgpu" (module does not exist, 0)
[ 29618.467] (II) LoadModule: "ati"
[ 29618.467] (WW) Warning, couldn't open module ati
[ 29618.467] (EE) Failed to load module "ati" (module does not exist, 0)
[ 29618.467] (II) LoadModule: "modesetting"
[ 29618.467] (WW) Warning, couldn't open module modesetting
[ 29618.467] (EE) Failed to load module "modesetting" (module does not exist, 0)
[ 29618.467] (II) LoadModule: "fbdev"
[ 29618.467] (WW) Warning, couldn't open module fbdev
[ 29618.467] (EE) Failed to load module "fbdev" (module does not exist, 0)
[ 29618.467] (II) LoadModule: "vesa"
[ 29618.467] (WW) Warning, couldn't open module vesa
[ 29618.467] (EE) Failed to load module "vesa" (module does not exist, 0)
[ 29618.467] (EE) No drivers available.
[ 29618.467] (EE)
Fatal server error:
[ 29618.467] (EE) no screens found(EE)

I guess it's because you've renamed modsetting_drv.so as well :(.

[martyj19]

I can only speak to Intel. I believe the best characterization of xf86-video-intel is "unmaintained" and has been so since 2014 when it became clear that there would not be another release. That is around when I started using the modesetting driver, which comes with xorg-server, and it has been trouble free and been improved over time. If you build xorg-server with --enable-glamor it will use GPU acceleration provided by whatever Mesa driver is available for your card. If you have newer hardware xf86-video-intel does not have code to support it nor is there any interest upstream in providing it.

If you have xf86-video-intel installed you need

Section "Device"
	Identifier "whatever"
	Driver "modesetting"
EndSection

to get Xorg not to use it. I would guess that they will not be interested in changing the search order at this point.

All of this will be academic when everyone has a Wayland and Xwayland setup in which Xserver and the Xorg drivers are no longer used.

[Bruce Dubbs]

For xorg-server using meson like we do in the book:

option('glamor', type: 'combo', choices: ['true', 'false', 'auto'], value: 'auto',

description: 'Enable glamor (default yes for Xorg builds)')

---

I did have modesetting disabled. Re-enabling:

[ 30290.810] (==) Matched amdgpu as autoconfigured driver 0
[ 30290.810] (==) Matched ati as autoconfigured driver 1
[ 30290.810] (==) Matched modesetting as autoconfigured driver 2
[ 30290.810] (==) Matched fbdev as autoconfigured driver 3
[ 30290.810] (==) Matched vesa as autoconfigured driver 4
[ 30290.810] (==) Assigned the driver to the xf86ConfigLayout
[ 30290.810] (II) LoadModule: "amdgpu"
[ 30290.810] (WW) Warning, couldn't open module amdgpu
[ 30290.810] (EE) Failed to load module "amdgpu" (module does not exist, 0)
[ 30290.810] (II) LoadModule: "ati"
[ 30290.810] (WW) Warning, couldn't open module ati
[ 30290.810] (EE) Failed to load module "ati" (module does not exist, 0)
[ 30290.810] (II) LoadModule: "modesetting"
[ 30290.810] (II) Loading /opt/xorg/lib/xorg/modules/drivers/modesetting_drv.so
[ 30290.810] (II) Module modesetting: vendor="X.Org Foundation"
[ 30290.810]   compiled for 1.21.1.7, module version = 1.21.1
[ 30290.810]   Module class: X.Org Video Driver
[ 30290.810]   ABI class: X.Org Video Driver, version 25.2
[ 30290.810] (II) LoadModule: "fbdev"
[ 30290.810] (WW) Warning, couldn't open module fbdev
[ 30290.810] (EE) Failed to load module "fbdev" (module does not exist, 0)
[ 30290.810] (II) LoadModule: "vesa"
[ 30290.810] (WW) Warning, couldn't open module vesa
[ 30290.810] (EE) Failed to load module "vesa" (module does not exist, 0)
[ 30290.810] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
...
[ 30290.810] (II) Loading sub module "glamoregl"
[ 30290.810] (II) LoadModule: "glamoregl"
[ 30290.810] (II) Loading /opt/xorg/lib/xorg/modules/libglamoregl.so
[ 30290.812] (II) Module glamoregl: vendor="X.Org Foundation"
[ 30290.812]   compiled for 1.21.1.7, module version = 1.0.1
[ 30290.812]   ABI class: X.Org ANSI C Emulation, version 0.4
[ 30290.827] (II) modeset(0): glamor X acceleration enabled on AMD Radeon RX 550 Series (polaris11, LLVM 16.0.5, DRM 3.49, 6.1.11-20221103)
[ 30290.827] (II) modeset(0): glamor initialized

[Tim Tassonis]

Cool, thanks, that did the trick!

I made a:

root@gomez:~# cat /etc/X11/xorg.conf.d/15-modesetting.conf 
 Section "Device"
         Identifier "whatever"
         Driver "modesetting"
 EndSection

And now, the intel driver is not loaded anymore (first loader, then unloaded, accoriding to the log file).

Xfce4 now sees me as a different desktop, but that's no problem. I'll let the system run like this for a while and see if all is well.

Replying to martyj19:

I can only speak to Intel. I believe the best characterization of xf86-video-intel is "unmaintained" and has been so since 2014 when it became clear that there would not be another release. That is around when I started using the modesetting driver, which comes with xorg-server, and it has been trouble free and been improved over time. If you build xorg-server with --enable-glamor it will use GPU acceleration provided by whatever Mesa driver is available for your card. If you have newer hardware xf86-video-intel does not have code to support it nor is there any interest upstream in providing it.

If you have xf86-video-intel installed you need

Section "Device"
	Identifier "whatever"
	Driver "modesetting"
EndSection

to get Xorg not to use it. I would guess that they will not be interested in changing the search order at this point.

All of this will be academic when everyone has a Wayland and Xwayland setup in which Xserver and the Xorg drivers are no longer used.

Yeah, I think this will actually coincident with the arrival of all IPV6....

[pierre]

For me, with an AMD GPU RX 6400, I have removed the amd driver, and got some video glitch when using HW webrender in firefox. Not sure whether it comes from new version of firefox or removing the amdgpu driver (unfortunately, I have not tried the new version of firefox with the amdgpu driver). Will let you know, but right now, I'm doing a full rebuild on the machine with the AMD GPU.

[pierre]

Actually, webrender runs perfectly well under X11. It is with wayland or xwayland that it has some small, luminous dots appearing randomly on the screen... Will try with the amdgpu driver now, but I suspect the results will be the same (shouldn't change wayland result, at least)

[pierre]

Replying to pierre:

Will try with the amdgpu driver now, but I suspect the results will be the same (shouldn't change wayland result, at least)

Was wrong: summary:

• only modesetting driver:
  • X11 ok
  • wayland has random luminous spots when using webrender on firefox (will try to upload a video), whether using wayland or xwayland
• with the amdgpu driver:
  • X11 ok
  • wayland ok in the same situation(s) as above

BTW, the wayland compositor I use is mutter. I guess it is worth trying another compositor... Building plasma now.

[Xi Ruoyao]

Replying to pierre:

Replying to pierre:

Will try with the amdgpu driver now, but I suspect the results will be the same (shouldn't change wayland result, at least)

Was wrong: summary:

• only modesetting driver:
  • X11 ok
  • wayland has random luminous spots when using webrender on firefox (will try to upload a video), whether using wayland or xwayland
• with the amdgpu driver:
  • X11 ok
  • wayland ok in the same situation(s) as above

BTW, the wayland compositor I use is mutter. I guess it is worth trying another compositor... Building plasma now.

Hmm interesting... Does mutter even loads xf86-video-amdgpu?

[Xi Ruoyao]

Replying to Xi Ruoyao:

Replying to pierre:

Replying to pierre:

Will try with the amdgpu driver now, but I suspect the results will be the same (shouldn't change wayland result, at least)

Was wrong: summary:

• only modesetting driver:
  • X11 ok
  • wayland has random luminous spots when using webrender on firefox (will try to upload a video), whether using wayland or xwayland
• with the amdgpu driver:
  • X11 ok
  • wayland ok in the same situation(s) as above

BTW, the wayland compositor I use is mutter. I guess it is worth trying another compositor... Building plasma now.

Hmm interesting... Does mutter even loads xf86-video-amdgpu?

This is very strange to me. Can you see which program is loading the amdgpu driver by grep amdgpu_drv.so -l /proc/*/maps?

[pierre]

Replying to Xi Ruoyao:

Replying to Xi Ruoyao:

Replying to pierre:

Replying to pierre:

Will try with the amdgpu driver now, but I suspect the results will be the same (shouldn't change wayland result, at least)

Was wrong: summary:

• only modesetting driver:
  • X11 ok
  • wayland has random luminous spots when using webrender on firefox (will try to upload a video), whether using wayland or xwayland
• with the amdgpu driver:
  • X11 ok
  • wayland ok in the same situation(s) as above

BTW, the wayland compositor I use is mutter. I guess it is worth trying another compositor... Building plasma now.

Hmm interesting... Does mutter even loads xf86-video-amdgpu?

This is very strange to me. Can you see which program is loading the amdgpu driver by grep amdgpu_drv.so -l /proc/*/maps?

Hmm, I may have been mislead: when there is a popup window (such as when I hove the mouse over the "pocket" button, and the pop up appears telling "save to pocket"), then there is no video problem anymore! Let me try again...

Looks like having the amdgpu driver does not make a difference under wayland (still some random luminous dots dancing)

[pierre]

Summary again:

• with amdgpu driver:
  • session: X11; window protocol in firefox: X11; webrender ok (the grep suggested above returns the process id of Xorg server)
  • session: wayland; window protocol in firefox: xwayland: webrender ok (the grep suggested above returns nothing)
  • session wayland; window protocol in firefox: wayland: webrender has some defects (the grep suggested above returns nothing)
• without amdgpu driver:
  • session: X11; window protocol in firefox: X11; webrender ok (the grep suggested above returns nothing (but replacing amdgpu with modesetting, then, it retruns the process id of the Xorg server))
  • session: wayland; window protocol in firefox: xwayland: webrender ok (the grep suggested above returns nothing, even when grepping only for _drv.so)
  • session wayland; window protocol in firefox: wayland: webrender has some defects (the grep suggested above returns nothing, even when grepping only for _drv.so))

[martyj19]

If you are able to isolate the conditions for those drawing artifacts I would think the responsible component would be interested in knowing about it. You could try the reference standard compositor weston to see if it appears there.

[Tim Tassonis]

Quick question: would this also mean the intel-media-driver stuff goes away?

[martyj19]

intel-media-driver is acceleration for video decoding/encoding. It's not applicable to most drawing that the Xorg video drivers do. It hooks into libva which would be accessed by special code in for example ffmpeg when you are decoding video into frames ready for display. Once you have the frame it gets drawn by whatever surface-drawing mechanism is in use. I am eliding a lot of the detail on that because the video normally gets decoded to YUV rather than RGB and is then displayed on a separate video plane.

Newer hardware is being supported by oneAPI replacing libva and the oneVPL video processing library replacing the intel-media-driver, which I haven't been able to experiment with because I don't yet have hardware for it.

[Tim Tassonis]

Replying to martyj19:

intel-media-driver is acceleration for video decoding/encoding. It's not applicable to most drawing that the Xorg video drivers do. It hooks into libva which would be accessed by special code in for example ffmpeg when you are decoding video into frames ready for display. Once you have the frame it gets drawn by whatever surface-drawing mechanism is in use. I am eliding a lot of the detail on that because the video normally gets decoded to YUV rather than RGB and is then displayed on a separate video plane.

Newer hardware is being supported by oneAPI replacing libva and the oneVPL video processing library replacing the intel-media-driver, which I haven't been able to experiment with because I don't yet have hardware for it.

Well, it's actually the details I care about, I do know the broader picture. On the video front, I usually use mpv, which seems to do a good job in getting the best performing mechanism, a fallback to X11 usually means stuttering.

My second "video client" usually is firefox, for Youtube and Netflix mostly. There, I'm not really sure how firefox decides on the best performing video decoding.

As they now support hardware decoding for intel, I'm just not sure what this means in practice, if the X11 intel drives is not selected. Does libva for video decoding still get selected?

[martyj19]

The video decoding/processing path is really independent of the main drawing path. So yes libva can be used to access video decoding hardware present on the GPU no matter what is managing the framebuffer that your monitor is displaying. The video helpers are separate functional blocks that don't participate in the main rendering pipeline.

There is some good discussion on ArchLinux of how it all fits together and how you could test to satisfy yourself that video acceleration is working for mpv and firefox.

[Tim Tassonis]

Thank you, the whole stuff is really quite interesting, I hope I get the time to look at that properly.

[pierre]

Replying to martyj19:

If you are able to isolate the conditions for those drawing artifacts I would think the responsible component would be interested in knowing about it. You could try the reference standard compositor weston to see if it appears there.

That's one of my plans (the other is to use kwin). I've also a machine with Haswell integrated graphics. There is no problem in webrender (still with mutter), but the frame rate goes below 60 for more than 1000 fishes (see ​https://webglsamples.org/aquarium/aquarium.html), while with the AMD GPU, it needs more than 15,000 fishes to have the frame rate drop (whatever it means, may be related to CPU (much newer on the AMD GPU machine) or GPU or both)...

[Xi Ruoyao]

Replying to martyj19:

The video decoding/processing path is really independent of the main drawing path. So yes libva can be used to access video decoding hardware present on the GPU no matter what is managing the framebuffer that your monitor is displaying. The video helpers are separate functional blocks that don't participate in the main rendering pipeline.

Yep, the accelerated video encoding or decoding really have nothing to do with a Graphical Environment. We can even use the GPU to transcode videos in a virtual console. So IMO we should move the five Hardware Video Acceleration packages from "Graphical Environment" section into "Multimedia" section as well.

[Xi Ruoyao]

Replying to pierre:

Replying to martyj19:

If you are able to isolate the conditions for those drawing artifacts I would think the responsible component would be interested in knowing about it. You could try the reference standard compositor weston to see if it appears there.

Is there a difference between Firefox 102 and 115?

[Douglas R. Reno]

Without xf86-video-vmware, an instance of LFS in VMWare Workstation will refuse to bring X up, as it complains about not finding any screens. I'd like to at least keep that driver but think checking everything out during tagging is a good idea

[Xi Ruoyao]

Replying to Douglas R. Reno:

Without xf86-video-vmware, an instance of LFS in VMWare Workstation will refuse to bring X up, as it complains about not finding any screens. I'd like to at least keep that driver but think checking everything out during tagging is a good idea

This is strange. Arch only mentions xf86-video-vmware as a work around for "Potential Issue 5 of the VMWare Guest Tools" and they don't say xf86-video-vmware is needed for Xorg:

​https://wiki.archlinux.org/title/VMware/Install_Arch_Linux_as_a_guest

[Xi Ruoyao]

I've installed Arch Linux on VMWare and startx works without xf86-video-vmware.

I guess it depends on some kernel configurations, though.

[Douglas R. Reno]

Another potential variable is the version of VMWare in use. I generally use VMWare Workstation 15 as that's what I get from my college. I have a suspicion it might be kernel config related too though, last time I tried was for 11.3's release

[Joe Locash]

Thought I'd report my testing:

Daily use box (BLFS-11.3):

Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz/NVIDIA Corporation G96CM [GeForce 9650M GT] (rev a1)

Build box(BLFS-11.3):

AMD Ryzen 7 PRO 4750U with Radeon Graphics

Backup box (BLFS-11.1):

Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz

Removing the xf86-video-* drivers on all boxes was no problem.

Removing xf86-video-nouveau actually resolved an artifact issue I was seeing with firefox on my daily use box when marco (the window manager for MATE) was built with libXpresent support.

[Xi Ruoyao]

Now ATI and fbdev are still not tested by anyone.

I guess ATI would be fine.

But perhaps fbdev is still needed if we want to run Xorg on a plain frame buffer (for example, efifb or vesafb). Simpledrm should be able to replace efifb and vesafb and it supports modesetting. The BLFS EFI boot configuration uses simpledrm, but simpledrm does not work with LFS grub.cfg (for using simpledrm a "set gfxpayload=" line is needed in grub.cfg if booting via BIOS).

However is there any BLFS user running Xorg on a plain frame buffer in 2023?

[Douglas R. Reno]

For ATI, I can test it at freeze time

[Xi Ruoyao]

For fbdev we can just set CONFIG_DRM=n and test in a VM.

[martyj19]

It looks like CONFIG_DRM_VMWGFX enables a virtual DRM/KMS device for VMWare that would work with the modesetting driver. I don't have a setup to test this however.

[Xi Ruoyao]

Replying to martyj19:

It looks like CONFIG_DRM_VMWGFX enables a virtual DRM/KMS device for VMWare that would work with the modesetting driver. I don't have a setup to test this however.

I've tested it on Arch Linux running in VMWare Workstation 17. But I've not tested LFS yet.

[Xi Ruoyao]

WIP branch: xry111/xf86-video-removal.

[Xi Ruoyao]

Fixed:

• r11.3-985-g951fa4c6de changelog: Add entry for xf86-video-* removal
• r11.3-984-gcb88494ae6 xorg-server: Align kernel config
• r11.3-983-ge56ca04202 Merge branch 'xry111/xf86-video-removal' into trunk
• r11.3-976-gdb58c760c1 firmware: No "firmwares"
• r11.3-975-gd2058eb069 Merge branch 'trunk' into xry111/xf86-video-removal
• r11.3-968-gb674aa10f7 Merge remote-tracking branch 'origin/trunk' into xry111/xf86-video-removal
• r11.3-962-ged179d1c5c firmware: Add back how to include firmwares into the kernel image
• r11.3-961-g5c7ad049db Move Xorg mode line setting from qemu to xorg-config
• r11.3-960-g9b492b4d91 Merge branch 'trunk' into xry111/xf86-video-removal
• r11.3-955-g797182d11a xorg-server: Add kernel configuration section
• r11.3-954-gc97d35e2f6 xorg-server: Force -Dglamor=true
• r11.3-953-g22c1bfc373 Archive xf86-video-*

[Bruce Dubbs]

Milestone renamed