question about the behaviour of DebugConfig::render_drm_device

[nyawox]

hi, i'm new to rust. please forgive my ignorance. I was reading the code, trying to figure out how niri chooses the primary GPU by default unless explicitly specified. then I stumbled across this line:

niri/niri-config/src/lib.rs

Line 3544 in 9c7e8d0

render_drm_device: Some(PathBuf::from("/dev/dri/renderD129")),

This suggests it may default to /dev/dri/renderD129 (maybe to prioritize using dgpu on laptops??) and then... perhaps fallback to another device, since not every machines has dual gpu. Is my assumption correct? I want to do the opposite: default to /dev/dri/renderD128 (amd dgpu), then fall back to nvidia dgpu if it's not available (due to being allocated to a VM guest). I just didn't want to write 700 lines of Nix code to set up automated macOS vm installation, only to later find out this approach isn't possible😸 hopefully explicitly setting render-drm-device also let fallback

[YaLTeR]

Hey, that line is from a test. You can see above in a big string where I set that option to that value for the test:

niri/niri-config/src/lib.rs

Line 3152 in 9c7e8d0

render-drm-device "/dev/dri/renderD129"

The setting defaults to None (unset), which causes niri to try to get the primary (boot) GPU from udev:

niri/src/backend/tty.rs

Lines 253 to 272 in 9c7e8d0

	let (primary_node, primary_render_node) = primary_node_from_config(&config.borrow())
	.ok_or(())
	.or_else(|()| {
	let primary_gpu_path = udev::primary_gpu(&seat_name)
	.context("error getting the primary GPU")?
	.context("couldn't find a GPU")?;
	let primary_node = DrmNode::from_path(primary_gpu_path)
	.context("error opening the primary GPU DRM node")?;
	let primary_render_node = primary_node
	.node_with_type(NodeType::Render)
	.and_then(Result::ok)
	.unwrap_or_else(|| {
	warn!(
	"error getting the render node for the primary GPU; proceeding anyway"
	);
	primary_node
	});
	Ok::<_, anyhow::Error>((primary_node, primary_render_node))
	})?;

On Asahi (and KMSRO in general) this logic doesn't always work (which could be improved but I don't have any such devices), so you can override it manually in the config if you need.

[nyawox]

Thank you for kindly answering! 😸 I will dive deeper into this. still unsure about the outcome - whether I'll end up finding a workaround, giving up, or learning Rust and sending a PR to implement a mutter-device-preferred-primary kind of udev tag (though this is very unlikely as I don't know what I'm doing).

For the record, the udev::primary_gpu code mentioned above seems to use a Smithay function to determine the primary GPU. The relevant code can be found here: https://github.com/Smithay/smithay/blob/f182a7d1b3d04081b9e639327f2e089f4a55bae8/src/backend/udev.rs#L233C1-L266C1

If specifying boot_vga is what I need, I imagine this unmerged kernel patch might suffice? idk https://lore.kernel.org/lkml/[email protected]/

looking through the kernel code, it seems to default to the firmware's default device, which in many cases it default to the second gpu slot with lower pcie link speed and we don't have the option to choose.

edit: the kernel patch i mentioned above works!