Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

libdrm: move dependency on nvidia-drm out of weston-init #1760

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

kekiefer
Copy link
Contributor

The nvidia-drm kernel module and associated load config are needed by libdrm but were only getting picked up by weston-init.

There are valid configurations (headless, egl-only) that need libdrm but do not pull in weston, so the runtime recommendation is moved to the libdrm bbappend.

@madisongh
Copy link
Member

There used to be a conflict between enabling modesetting in the nvidia-drm driver and the nvidia_drv X server driver module, which is why we had it tied in with weston, despite that not being the true nature of the dependency. Is that conflict still there? If so, we'll need to come up with a different scheme here.

@kekiefer
Copy link
Contributor Author

That makes sense - I didn’t check with the X server, so I’ll follow up here.

The nvidia-drm kernel module and associated load config are needed
by libdrm but were only getting picked up by weston-init.

There are valid configurations (headless, egl-only) that need
libdrm but do not pull in weston, so the runtime recommendation
is moved to the libdrm bbappend.

Signed-off-by: Kurt Kiefer <[email protected]>
@kekiefer
Copy link
Contributor Author

Interestingly, it is fine with this option in the linux-yocto kernel (doesn't matter one way or another there), but with jammy it's old problem with the modeset=1 parameter.

I'll change this to adjust that parameter if x11 is enabled and not xwayland.

We want to be able to pull in the module load configuration by default
but need to be careful to not enable the 'modeset' parameter on the
driver unless we won't be using x11 in the image. We can't check
distro features, so we make the modprobe conf RCONFLICT with x11, and
don't allow it to be pulled in if 'modeset' is enabled.

Also add variables to allow overriding the setting for the 'modeset'
and 'fbdev' parameters in a bbappend, local.conf file, or similar.

Signed-off-by: Kurt Kiefer <[email protected]>
@kekiefer
Copy link
Contributor Author

I've updated this to RCONFLICT a ${PN}-modeset package against whatever is stated to be ${XSERVER} if the modeset parameter is 1. The main nvidia-drm-loadconf package will always be present and load the module, but only RRECOMMENDs the ${PN}-modeset part.

Copy link
Member

@madisongh madisongh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks... mostly looks good, see in-line for a fix and a suggestion.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The weston-init recipe is already marked as machine-specific, but libdrm is not. Adding

PACKAGE_ARCH:tegra = "${TEGRA_PKGARCH}"

as part of this change will help prevent weird build failures when mixing tegra and non-tegra builds.

RRECOMMENDS:${PN} = "${PN}-modeset"

# if modesetting was enabled at build time, don't include the modprobe conf at runtime alongside the XSERVER packages
RCONFLICTS:${PN}-modeset = "${@d.getVar('XSERVER') if bb.utils.to_boolean(d.getVar('NVIDIA_DRM_MODESET')) else ''}"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of all of the XSERVER variable contents, you could be more specific here and just name xserver-xorg-video-nvidia, which where we have the conflict.... but I'm not sure it makes that much difference.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants