libCEC support

[gkoh]

Discussed in #91

^{Originally posted by kkjdroid July 15, 2026}
I don't know if this is remotely within scope, but if this device could show up as a /dev/cec* via V4L2's driver or libCEC, it would integrate with a pretty decent amount of software that's already compatible with devices that have built-in CEC (e.g. Raspberry Pi, Steam Machine). Even Konsole can use my remote's directional buttons on the Pi.

[gkoh]

As per initial research, I believe this does fit the project scope.
My current thoughts:

• out-of-box remains USB HID, no host driver requirements
• via console, can configure USB 'profile' to either:
  • USB HID (default)
  • USB CDC (new (and additional))

From a host perspective two USB CDC devices should appear:

• ttyACM0: existing serial console
  • this is required to (re)configure pico-cec at all times
• ttyACM1: libCEC attach compliant, requires some host drivers/configuration (eg. inputattach), as per:
  • https://docs.kernel.org/admin-guide/media/cec.html

Achieving this will require some redesign of the current data flow.
As of now, the data management is deliberately simple:

• physical layer CEC driven by cec-task
• cec-task handles CEC protocol
• cec-task handles user command -> key code -> queue -> hid-task
• hid-task drives USB HID

Using the Linux kernel as a reference target, the host operating system drives the CEC protocol, exposing /dev/cec* to user space applications.
This requires the existing 'cec-task' to be refactored into multiple pieces.

With the recent addition of the send capability, I think we can now refactor like this:

• cec-physical task drives physical layer with two queues:
  • CEC receive queue
  • CEC transmit queue
• two configurable queue consumers are now possible:
  • cec-protocol task handles the existing CEC state machine and user key code hand-off to USB HID
  • cec-passthrough task is a (very) transparent bridge for hand-off to USB CDC

For cec-protocol this is just a re-mash of the current code with an added set of queues to separate interaction with the physical layer.
For cec-passthrough all logic is essentially delegated to the upstream host, we just need enough code to:

• validate CEC messages (mostly already done?)
• format as per upstream requirements, either (or perhaps both):
  • Rainshadow ASCII
  • Pulse-Eight binary
• transfer to/from USB CDC

Usefully we can implement in this in stages without compromising existing functionality or compatibility.