This was also my motivation for investigating this. With a script like the “enable-screens.sh” you can do runtime reconfiguration of the virtual displays. Apparently this only works if the kernel is not in a “lockdown” state. So this would depend on the distribution. And you have the “Switching the screens” section. It describes how to set up an application in Sunshine so that when you connect one screen turns of and back on again when you disconnect. I hope these two points fit your requirements.

Yeah, unfortunately a lot of useful information is hidden in these discord groups these days. I’d much rather see stuff like this posted and discussed on the fediverse. I used the discord to gather the necessary information and then shared the write-up back there initially.

Yes, once you disable the host’s display you can target the refresh rate of the client’s display. But you still might to have to change resolution in-game depending on the game, I think.

Yes. This allows the host’s display to be shut down and match exactly the resolution of the target display. It also makes for a very performant dual screen setup for work. I can use my tablet standing up for a terminal session or a video with very good latency.

Sure you can but you would mirror the resolution of your main display. I’m using a FHD 16:9 but stream to a 16:10 tablet and a 4k TV. So having the true resolution of the target display improves the image quality.

I first had it running with the kernel parameters. For this see the second link in the introduction. The problem there was it added to boot time, as the kernel generates an error message. Passing an EDID as kernel parameter was complicated, due initramfs modification being tricky on Bazzite (at least acccording to my limited understanding). So I moved to this method where I initialize the virtual display via the KMS debug API later in the boot process. This can also be used to arbitrarily modify the virtual display. I have not looked into doing it via parameter. Can you share the example commands?

I got new-lg4ff working some time ago and posted this on the Bazzite discord. I have not tried for some time though:

I managed to get new-lg4ff going at least on a per use basis. Not ideal this way but at least something. First you need to pull the driver from Github:

git clone https://github.com/berarma/new-lg4ff

Then you need a toolbox matching your base image in my case:

toolbox create --image ghcr.io/ublue-os/bazzite-gnome:testing --container bazzite-devel
toolbox enter bazzite-devel

Next you need to pull in the kernel-devel files. They are on a separate github page “kernel-bazzite”. Find your running kernel version.

uname -r

Then download the appropriate kernel-devel and kernel-devel-matched from https://github.com/hhd-dev/kernel-bazzite/releases, in my case:

wget https://github.com/hhd-dev/kernel-bazzite/releases/download/6.11.5-310/kernel-devel-matched-6.11.5-310.bazzite.fc41.x86_64.rpm
wget https://github.com/hhd-dev/kernel-bazzite/releases/download/6.11.5-310/kernel-devel-6.11.5-310.bazzite.fc41.x86_64.rpm

Install them into the toolbox:

sudo rpm -if kernel-devel-matched-6.11.5-310.bazzite.fc41.x86_64.rpm kernel-devel-6.11.5-310.bazzite.fc41.x86_64.rpm

Then the build of the module should succeed. From the folder you cloned the new-lg4ff repo run:

make

To insert the module you need to relax SELINUX (against idea of SELINUX, but it is a hacky solution).

sudo setenforce Permissive

Then you should be able to insert the kernel module:

sudo insmod hid-logitech-new.ko

This is it.