Explicit device layout

[BrendanGrant]

Preflight checklist

If you remove this checklist, this pull request will be closed without explanation.

• I understand that if this pull request is about support for non-Elgato or non-Tacto hardware, it will be closed without explanation, as per issue Statement regarding device support #38.
• I certify the compliance of this pull request with the Jellyfin LLM/"AI" Development Policy adopted by the OpenDeck project.
• I thoroughly understand the changes that I am proposing in this pull request, and I will be able to respond to questions and review feedback.
• [] I reasonably believe that the changes that I am proposing are of production quality, or I am otherwise opening this pull request as a draft.
• I have thoroughly reviewed the diff of my changes and ensured that I have neither introduced any unrelated additions, nor differences in unmodified code.
• I have ensured that I have run the appropriate formatter on my changes and that my code produces no linter violations.
• I will keep "Allow edits from maintainers" enabled for this pull request.

---

At present, OpenDeck devices can only describe their layout using a small set of fixed properties: button matrix rows and columns, encoder count, and touchpoint count. That works well for regular devices like the Stream Deck Mk.2, XL, and Neo, but it does not model irregular devices cleanly.

OpenDeck’s policy is that only Elgato hardware is officially supported in the core application, while support for other hardware vendors belongs in plugins. This PR does not add built-in support for any non-Elgato device. Instead, it extends the plugin registration model so plugins can describe the layout of the devices they already register.

This change adds an optional explicit layout model that lets a plugin provide the position, size, shape, and surface grouping for each control. The existing registration shape remains supported, so plugins that only provide rows, columns, encoders, and touchpoints continue to use the legacy renderer.

I have been testing this in two ways: with a fake-device plugin branch and with a real Loupedeck Live connected to a Raspberry Pi 3 running a build of OpenDeck based on this change. The Loupedeck plugin is here: BrendanGrant/OpenDeck.Loupedeck. The fake-device plugin branch is here: OpenDeck.FakeDevicesPlugin.Web fake_devices. The installable fake plugin package can be downloaded here: opendeck-fake-devices-web.sdPlugin.

This is working well in my testing, but I am opening the PR as a draft to solicit feedback on the approach. In particular, I would like feedback on whether this explicit layout model is a good direction for plugin-provided devices, and whether the shape of the registration metadata feels appropriate for OpenDeck long term.

[CLAassistant]

All committers have signed the CLA.

[nekename]

Thank you for the submission and for the Loupedeck plugin. Re: Loupedeck, someone else just showed off a Loupedeck plugin a day or two ago: https://github.com/Aib0t/opendeck-loupedeck - in case you were interested.

More flexible device layouts have often been requested so I'd be happy to take a look at this soon.

[Terrorwolf01]

Just to clarify since I don't think I saw it, does this Support LCD Screens like they are on the SD+? And how about touch Points like on the SD Neo?

(Sorry if I just missed it, its late already)

[BrendanGrant]

@nekename

Re other Loupedeck

Ha! I didn't search too far for a solution so took it as an opportunity to do some reverse engineering of a pcap.

I happen to have a couple different devices supported by the official Loupedeck software so will need to contribute over there as well.

@Terrorwolf01

Yes, that is the intent.

For the Stream Deck+, the layout model can describe the touch strip as a 'touchpanel' surface, with one or more logical 'Keypad' controls placed over it. In the fake-device plugin I’m using for testing, the SD+ strip is modeled as one continuous touch-panel surface with four logical touch zones.

For the Stream Deck Neo, the same model can represent the small non-LCD/touch-style controls separately from the main LCD key grid. The fake Neo layout uses a main display surface for the 2x4 LCD keys and a separate touch-panel/info-bar region for the lower controls.

So the model separates two concepts:

• 'surfaces': physical display or touch-panel regions, such as the SD+ strip
• 'controls': logical assignable positions, such as keys, encoders, or touch zones on top of a surface

That lets the UI show the physical shape while still routing drops/clicks to the correct logical position.

The exact hardware behavior still depends on the plugin that owns the device. This PR gives plugins a way to describe those regions to OpenDeck; it does not by itself add built-in hardware support for non-Elgato devices.

[Terrorwolf01]

The exact hardware behavior still depends on the plugin that owns the device. This PR gives plugins a way to describe those regions to OpenDeck; it does not by itself add built-in hardware support for non-Elgato devices.

Ofc. Never thought so. Was just checking. For the Touchpanel name: Wouldn't it make more sense to keep the same naming? In this case Touchstrip since thats the official Name in the Elgato Universe and in OpenDeck?

[BrendanGrant]

Had to re-write a little history as the wrong email address got used for the commit.

@Terrorwolf01

That's a fair point.

I used 'touchpanel' because I was trying to describe the generic shape of the capability rather than the Stream Deck+ specifically. The intent was to cover things like the SD+ touch strip, Neo-style touch areas, and non-Elgato devices that may have larger or differently shaped touch/display regions.

That said, consistency with existing OpenDeck / Elgato terminology matters. If 'touchstrip' is already the established term in OpenDeck, I'm fine renaming the layout surface kind to that, or using 'touchstrip' for the narrow horizontal SD+ case and reserving something more generic only if we later need it.

Being new here, my preference would be whatever fits the existing OpenDeck vocabulary best.