Add "portable" PlayOS flavour

[yfyf]

Meant to be installed on laptops, used for Flex device demos via distributors.

Main current issue is sound. The fixes applied here seem to make sound on my laptop (tested via live ISO) work, however users do not have any way control the sound volume, since the media keys are not mapped to anything.

TODOs:

• Add+test volume media key support
• Maybe reduce update download limit to 1MB/s or so? To minimize interference in the scenario where download starts during a demo. Requires making it configurable in controller.

[yfyf]

@knuton @dividat-jgu could you please build a live ISO of this, using:

QUICK_BUILD=1 nix-build --arg buildVm false --arg buildInstaller false --arg buildBundle false --arg buildLive true --arg buildDisk false --arg applicationPath ./flavors/portable.nix

and check on some laptop if audio works "out of the box" when you boot and start using Play?

EDIT: added experimental media key bindings, would be good to also check if volume up/down works.

[dividat-jgu]

Having a look this afternoon.

[dividat-jgu]

Working well!

• ☑️ I have sound from the laptop
• ☑️ If I plug headphones, I get sounds on the headphones
• ☑️ If I unplug headphones, I get sounds back from the laptop
• ☑️ The pre-selected volume looks good

But:

• ❎ If I plugged an HDMI screen which can play sound, the sound keeps being played from the laptop. What’s the current target? Would it be an idea to use HDMI over the laptop if available with the external screen?

Also, related but not concerning audio, external screens are mirrored, which looks sensible. But as an optimization, we could disable the laptop screen when closing the lid. Or disable the laptop screen when plugging an external screen. I’m guessing that this would reduce the computation need to display the screen, and let it available for other things.

[yfyf]

Working well!

Thank you for testing!

❎ If I plugged an HDMI screen which can play sound, the sound keeps being played from the laptop. What’s the current target? Would it be an idea to use HDMI over the laptop if available with the external screen?

Yes, in general this would be nice. However, at the moment the intention is to only use this with a laptop for Play/Flex demo purposes, without an external monitor, so it is not an immediate problem. I have no idea how to make pulseaudio auto-switch to an HDMI profile reliably - it cannot get it to work on my personal Debian setup and it also doesn't work on PlayOS. Online sources have confusing info, e.g. some sources say it should work out of the box with module-switch-on-connect, while this one provides a complex solution with udev rules 🤷

I also don't have a monitor with audio output at hand I could test with.

We can probably find a solution, but I propose to delay this until the portable hardware configuration matures, since this is very hard to test without targeting specific hardware. There are plans to use a lightweight portable monitor in the future.

Also, related but not concerning audio, external screens are mirrored, which looks sensible. But as an optimization, we could disable the laptop screen when closing the lid. Or disable the laptop screen when plugging an external screen. I’m guessing that this would reduce the computation need to display the screen, and let it available for other things.

Yes, but same as above, this is not an immediate use case, so I think it's best to avoid any optimizations. It's also not clear this is always desired - e.g. presenter might interact/observe from a different point. I doubt a mirrored extra screen adds much extra load, since all the rendering is already done (especially assuming identical resolutions) for the primary screen.

[yfyf]

Audio + media controls seem to work on a Lenovo V15 G5, tested by jvhr

[yfyf]

@knuton I propose we actually merge this into main, so that we don't need to dig through branches if we need to update this. I could also add a CI workflow that builds the portable flavor as a test.

Alternatively, I can create separate PRs for the non-config changes, but keep the flavors/ existing only in a branch. However, the non-config changes will look a bit strange when there's no actual usage in the source tree.