**snip** > >> Question 2: > >> > >> If you turn the second screen off through drm/kms, using the desktop > >> environments monitor config panel does this also turn off the > >> backlight ? > > > > The screen is dark but there is still some backlight coming out of it. > > I think this means I need to add a small pre-off to the patch to ensure > > backlight is fully off when display is turned off. > > I'm afraid that this is not going to be easy to fix at the kernel level, > we first need to tie backlight control to drm-connectors as I proposed > (and plan to implement when I can make time): > > https://lore.kernel.org/dri-devel/b61d3eeb-6213-afac-2e70-7b9791c86d2e@redha > t.com/ > > Once that is in place we can simply make the drm-code call out to > the backlight driver and have it turn the backlight off when disabling > the output through the drm/kms interface. Okay cool. But until then I can set the screenpad to turn brightness off when it does the call to: err = asus_wmi_set_devstate(ASUS_WMI_DEVID_SCREENPAD_POWER, 0, NULL); here I can also do before that call: err = asus_wmi_set_devstate(ASUS_WMI_DEVID_SCREENPAD_LIGHT,ctrl_param, NULL); Then when the patch you mention is done this can be removed. **snip** > > I would like to go with the backlight patch as it seems more likely I > > can adjust this without breaking userspace if required in future. The > > WMI controls behave as expected to. > > Ok, lets go with the v2 which adds /sys/class/backlight support then. > > I must warn you though if this does turn out to cause issues I'll have > no choice but to revert it. > > 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. > > ####### 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. Cheers, Luke.
Attachment:
signature.asc
Description: This is a digitally signed message part.
