Are the NvKmsKapiFunctionTable functions single-buffered or double-buffered?

[Cacodemon345]

As the title says.

Looking at https://github.com/NVIDIA/open-gpu-kernel-modules/blob/main/kernel-open/common/inc/nvkms-kapi.h doesn't tell me much about whether it's single buffered or double buffered.

[aritger]

The NvKmsKapiFunctionsTable structure is assigned by nvKmsKapiGetFunctionsTableInternal(), overwriting any existing values in that structure, if I understand the question correctly.

[Cacodemon345]

What I am saying is, can the functions work on a single framebuffer surface without the need for flipping?

[misyltoad]

I have no context of the NVIDIA specific interfaces, but for DRM atomic, the fb_ids (surface)s you provide will be used for the next scanout.

[aritger]

The functions in nvkms-kapi.h are part of nvidia-drm.ko's DRM atomic implementation, so Joshua-Ashton's response applies. That said, yes, you can work on the currently displayed surface without flipping if you really want, with the usual artifacts that will create.

[hramrach]

If you don't have fbdev there is no fbdev resolution so you can't get any fbdev resolution when console reappears. If you are using kmscon then you get console in graphics.

If you are using fbdev then you have another problem - any program that opens the fb blocks the graphics completely, and this is not possible to solve with any kind of arbitration, unlike the DRM master problem.

[Cacodemon345]

But the problem is that on average x86 desktops and workstations, Linux will tend to stick with bootloader's framebuffer with either vesa and efifb at initial stage before loading KMS drivers, and so far only built-in KMS drivers provide both KMS and fbdev and therefore are able to switch the resolution to the highest one when loading those.

KMS alone isn't enough to switch framebuffer console resolutions; it only provides DRI interfaces for Xorg/Wayland to use it. When you switch from a Xorg/Wayland screen to a framebuffer console VT screen, you will see that the monitor can blank out when both are using different resolutions. Which means KMS can't be used to set framebuffer console resolution on other terminal VTs.

The official NVIDIA drivers only deal with Xorg/Wayland DRI interfaces and does not deal with fbdev, so Linux will be still stuck with vesa/efifb because it provides no fbdev support for the kernel to use for its framebuffer console, whereas the built-in GPU/display drivers provide fbdev support for the kernel to use for high-resolution framebuffer consoles.

[hramrach]

If you do care about high resolution console kmscon and similar do provide that on top of KMS.

vesafb/efifb cannot be active together with a KMS driver so when nVidia driver loads these should be deactivated.

fbdev is broken and can never work so it would be backwards for the nVidia drivers to implement it.

Instead it would be more constructive to add support for KMS to init systems other than systemd if you care about that.

[Cacodemon345]

Except kmscon isn't officially maintained anymore; only unofficial versions. And not many people know or even bother to care about it either, instead being content with the framebuffer console provided by Linux.

And generally other init systems follow the Unix philosophy in doing a single thing and doing so well which again leaves KMS to be dealt with by other programs and not the init system itself.

[Cacodemon345]

For reference, see #228 where Fedora's removal of fbdev drivers left NVIDIA users with non-working framebuffer console output, because again, NVIDIA drivers do not implement fbdev. There also isn't any effort to port the Linux framebuffer console to work with KMS drivers that doesn't provide fbdev support to my understanding.