Date: Mon, 29 Jun 2026 11:46:32 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 296372] linuxkpi does not set some flags nvidia-drm-kmod looks for activating vt_drmfb Message-ID: <bug-296372-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=296372 Bug ID: 296372 Summary: linuxkpi does not set some flags nvidia-drm-kmod looks for activating vt_drmfb Product: Base System Version: 15.1-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: keivan@motavalli.me brief context: Kde plasma >= 6.8 will be Wayland only, which requires using DRM on FreeBSD, that includes Nvidia users. Fortunately the proprietary nvidia-driver for FreeBSD can be used by an open source platform layer, nvidia-drm{-version}-kmod, based on the opensource nvidia linux platform layer, to expose drm functionality via drm-kmod. Once patched to avoid a kernel panic (see bug #296195 - patch about to go both into ports and in a future upstream nvidia release), it makes plasma6 able to run using wayland, including suspend/resume, with an Nvidia RTX 3060 as the sole system graphics adapter. When running a wayland client over nvidia-drm-kmod, switching consoles with crtl-alt-F{number} does not work and results in losing access to both the text consoles and the wayland client until it is externally terminated, eg, via ssh. The current VT integration with DRM drivers is via vt_drmfb, whose initialization is hooked into drm_fb_helper functions of drm-kmod, for what I understand (https://github.com/freebsd/drm-kmod/pull/243), and both i915/amdgpu call into drm_fb_helper to inizialize drm fb functionality instead of handling it directly, even if this may not always have been that way. When loading the nvidia-drm.ko and drm.ko modules, vt_drmfb does not get initialized (I added some printfs to vt_drmfb_init and drm_fb_helper_init to check and these functions are never called); VT continues to use vt_efifb. I do not understand well the inner workings of the nvidia driver and believe some calls are into the proprietary blob, so no assurance that it can work trough linux drm_fb_helper like amdgpu and i915, but config code (in /usr/ports/graphics/nvidia-drm-612-kmod/work/NVIDIA-FreeBSD-x86_64-595.84/src/nvidia-drm/nvidia-drm-conftest.h) seems to check for CONFIG_DRM_TTM_HELPER via <linux/kconfig.h> to enable framebuffer functionality. >From my understanding, CONFIG_DRM_TTM_HELPER is not set in the linuxkpi so nvidia-drm-kmod never enables related functionalities. Also from my understanding, drm_fbdev_ttm_setup() from drm-kmod/drivers/gpu/drm/drm_fbdev_ttm.c, if called into from the nvidia driver in nvidia-drm-drv.c:2076 (for release 595.84), dependent on a C preprocessor check around CONFIG_DRM_TTM_HELPER derived variables, would then invoke drm_fb_helper functions in drm-kmod and thus inizialize the vt_drmfb backend, as per drm-kmod implementation of drm_fbdev_ttm_setup(). This attribution of the bug is speculative, because I have no experience of systems programming nor prior understanding of the drm layer. I can test changes on my system, hoping that this is really just some config variables away from working, without requiring adaptation from the part of nvidia or changes into VT/vt_drmfb -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-296372-227>