Just as a note, I’m not running Ubuntu, so paths and filenames might not be correct.
With Ubuntu/systemd gpumanager.service is set to start before display-manager.service start/restart.
When zapping gdm, gdm(3?).service restarts.
Now it depends on how Ubuntu glued together gdm.service and display-manager.service and systemd reacts to this. Obviously in a way it doesn’t get restarted. So the easy workaround would be to alter gpumanager.service to start on gdm.service instead of display-manager.service. Maybe gdm.service has to be altered too. Changes made will be reverted on update of gpumanager i.e. ubuntu-drivers-common but those are rare.
The touchpad not working is a side-effect of the acpi_osi setting, unfortunately the most difficult one to work around.
The background is, there are currently several kernel acpi bugs hitting current laptops with nvidia gpus, yours looks like it’s hit by this https://bugzilla.kernel.org/show_bug.cgi?id=156341
and probably also this https://bugs.acpica.org/show_bug.cgi?id=1333
So without the acpi_osi settings you will likely have freezes and hangs when turning on/off the dGPU.
Just try to run without them but keep an eye on dmesg, in the first logfile you posted the dGPU failed to power off, which can be ugly especially on suspend/resume.
To get your touchpad working and work around the power management issues, you will have to alter your corresponding ACPI table, in your case it is ssdt9.
Here somebody made some scripts:
WARNING: this is for a different laptop which has its dGPU methods in ssdt5 so the scripts have to be altered for yours.
With an altered ACPI table for the dGPU you don’t need the acpi_osi settings anymore and touchpad works again.
Ah! The gpu-manager issue isn’t much of a problem. I could just install the prime-indicator applet and change it to run systemctl restart display-manager instead of simply logging out.
I used the tables from the acpidump so I have much more .dat files. Put back the ssdt10.dat file and then
grep PRT0 *
It will tell you which file contains the duplicate definition to remove. Of course don’t remove dsdt.dat.
If the dat files are reordered, you should grep first for LKEN to know the right ssdt to alter.
The acpidump files and the SSDT files in /sys/firmware/acpi/tables are mismatched! Its SSDT9 through acpidump, and SSDT3 through /sys/firmware/acpi/tables. I used the /sys/firmware/acpi/tables method since I think that is what the kernel is currently using.
I deleted SSDT1.dat, after which it succesfully disassembled. I replaced all instances of OSYS except the declaration in SSDT3.dsl to 0x07D9. And then I bumped the number in the DefinitionBlock line by 1. I then followed these instructions to compile it and pack into an image: DSDT - ArchWiki
After booting with the new DSDT image, I am able to switch between GPUs without rebooting.
Thank you, much appreciated. Everything looks good now. Funny thing is, the kernel always complained and still complains about the duplicate ACPI definition, too. So the ssdt you had to remove in order to disassemble was never loaded anyway.