Hi, On 6/7/23 00:45, Luke Jones wrote: <snip> >> I must admit I've lost track a bit of the state of v2 during this >> discussion. Can I pick up v2 as is, or were there (other) remarks >> which need addressing and should I expect a v3 ? > > There will be a V3. I don't anticipate any issues at all with this, and some > folks have been using this patch with Gnome and KDE since V2 was submitted. Ok. >> ####### Switch to (off-topic) GPU mux discussion ######## > **snip** >>>> I think the best thing to do here is to just use EFI on machines like >>>> this. That or put grub in text mode so that it makes BIOS calls to >>>> display text. Using GRUB_TERMINAL_OUTPUT=gfxterm combined with >>>> classic BIOS booting will make grub try to directly drive the gfx >>>> card itself and I'm not surprised that it gets that wrong in this >>>> case. >>>> Note I think that just using EFI is prefered over switching grub to >>>> GRUB_TERMINAL_OUTPUT=console. I would expect >>>> GRUB_TERMINAL_OUTPUT=console to also work but I'm not sure. I don't >>>> think that the classic BIOS boot stuff is still tested by laptop >>>> vendors and esp. not tested with non standard BIOS settings ... >>> >>> The grub gfx mode is GRUB_TERMINAL_OUTPUT="console", fedora default in >>> all cases here. Grub itself shows fine when the MUX mode is in dgpu >>> mode (aka, internal display connected to dgpu). >> >> Ah ok, so I misunderstood and the problem only happens *after* grub? >> >> Have I understood that correctly? >> >> And this is on Fedora with the nvidia binary driver ? >> >> The problem then likely is that the nvidia binary driver is not in >> the initrd (which is by design since it may need to be rebuild on >> a driver update while the kernel is kept at the same version, >> so the initrd won't be rebuild). > > That was indeed the issue. It also creates new problems for when a user wants > to use iGPU only via the plain (and frankly not adequate or good) method of > simply removing the dGPU from the device tree. > > Currently I maintain the supergfxd tool which is a lot more advanced than the > other gpu switchers around, and I expose both the above method, and also PCI > hotplug, and the ASUS WMI method (which I now think is used by other vendors > also). Hotplug and Asus method can force the device off, and it can't be > brought back by a PCI rescan - but to do so safely the Nvidia drivers must be > unused and unloaded. I guess I'll need to tweak the boot process of supergfxd > and block things until this is done. > > Maybe we can move this to a new topic, because there looks to be a few things > to discuss in relation to hybrid laptops, and specifically Nvidia with MUX, > and Advanced Optimus. Yes if you want to discuss this further please start a new mailinglist thread for this and also please put the dri-devel list on the Cc: dri-devel@xxxxxxxxxxxxxxxxxxxxx Regards, Hans