drm: Respect XDG_SEAT for libinput seat selection

[alchark]

Instead of hardcoding "seat0" for enumerating available inputs under the DRM platform, use the value optionally provided by the standard environment variable XDG_SEAT, and fall back to the previous default if unavailable.

This allows running cog on a dedicated seat with its own display and input devices, while leaving the default seat0 available for other uses.

[aperezdc]

@alchark I like the idea of allowing configuring the seat, but rather than using only an environment variable, it would be better to allow setting it in the configuration file and/or via the -O/--platform-params= command line option. Would you be open to try and implement that in the init_config() function?

P.S: Please don't use Copilot for code reviews.

[alchark]

@aperezdc sure, let me try and add config/cmdline parsing too. I believe the precedence should be:

1. Use cmdline value if available
2. Else use config value if available
3. Else use environment variable value if available
4. Else fallback to seat0

As for Copilot, I don't think I did anything to trigger it, but it might be some "helpful" default buried somewhere in Github settings. Any pointers welcome :-D

[aperezdc]

@aperezdc sure, let me try and add config/cmdline parsing too. I believe the precedence should be:

1. Use cmdline value if available

2. Else use config value if available

3. Else use environment variable value if available

4. Else fallback to `seat0`

This makes sense, indeed.

Also I was checking around and it looks like the name of the XDG_SEAT environment variable is commonly used by Wayland compositors and other applications. So we may want to actually keep using that for consistency with the rest of the ecosystem.

As for Copilot, I don't think I did anything to trigger it, but it might be some "helpful" default buried somewhere in Github settings. Any pointers welcome :-D

It looks like it was some repo setting that triggered it automatically, hopefully it is disabled now after some fiddling with the repo settings (not they make it easy to disable 🙃).

[aperezdc]

@alchark Thanks for iterating on this. I left one small comment, and otherwise the patch looks good to me. Could you take a look?

(Don't worry about the failed ARM build in the CI, the job is having some issue picking the toolchain, so that's on us.)

[zhovner]

@alchark can we resolve conflict please?

So we can ask Patrick @TingPing to look here too.

Resolved

[TingPing]

This branch cannot be rebased due to conflicts

[alchark]

This branch cannot be rebased due to conflicts

That's weird. Let me rebase manually and re-publish, sorry for the noise.

[alchark]

@TingPing would you mind giving this another look? No conflicts now.