Make key mapping configurable.

[dennizzzz]

Changing the key mappings requires recompilation. Extracting them to a file would make the system way more flexible.

Example:

00, Select, ENTER,
01, Up, ARROW_UP
02, Down, ARROW_DOWN
03, Left, ARROW_LEFT
04, Right, ARROW_RIGHT
0A, Options, C
0D, Exit, BACKSPACE
20, 0, 0
21, 1, 1
22, 2, 2
23, 3, 3
24, 4, 4
25, 5, 5
26, 6, 6
27, 7, 7
28, 8, 8
29, 9, 9
35, Display Information, I
44, Play, P
45, Stop, X
46, Pause, SPACE
48, Rewind, R
49, Fast Forward, F
51, Subtitle, L

Thoughts?

[gkoh]

Interesting suggestion.
How would you envisage this working in:

• development
• installation

Note, this is an embedded system and there is no filesystem right now, so reading a file during runtime would require integrating more stuff.

[dennizzzz]

Note, this is an embedded system and there is no filesystem right now, so reading a file during runtime would require integrating more stuff.

My reference before this was a full RPi with Raspbian which has a Linux kernel, filesystems, Kodi and an integrated Pulse-Eight compatible(?) interface.

The absolute best option would be to embed a fat filesystem and a usb-driver and have the board present itself like a regular USB stick. Users write the configuration, including mapping, on it and the system reads it. That would take this project from the developer realm to the consumer realm and could make it a commercial product. (Making it fully Pulse-Eight compatible would also be a giant step in that direction.) And the flexibility of configuration could even make it a better product than the Pulse-Eight adapter. If you wonder if there is a market for this ... create a Kickstarter to gauge demand.

But for now take a look at littlefs or something similar. I have used jffs(2) on my Asus router in the past, but that runs a beefy kernel and has a lot of flash.

[gkoh]

@dennizzzz Thank you for the considered comment, appreciated.
OK, I think I understand your motivation, allow me to offer some thoughts.

full RPi with Raspbian

Comparing to such a setup is misleading (but not incorrect). My 'other' HTPC is exactly this and indeed was my reference for what kind of 'experience' to replicate.

fully Pulse-Eight compatible

The Pulse-Eight HDMI CEC hardware cost is what drove me to create this project. One should note however that it presents as a special USB device requiring driver installation to function. pico-cec was deliberately created to emulate an HID keyboard so it would be "plug'n'play", I would like to retain that.
Furthermore, I wonder about possible legal issues with mirroring a commercial product.

the flexibility of configuration could even make it better

OK, I believe this is the real core of the issue.
Yes, it is inconvenient for an end user to install a full development environment because they want to map, say, 'red' button to the 'backspace'.
As you note, the useful configuration is just the mapping table, and we want to expose that. There are several options:

• present as a USB mass storage device, offer a virtual filesystem and a file defining the mapping
  • this is possible, we can create a virtual FAT filesystem and file and allow the user to edit said file
  • this solution is challenging, it opens up a lot of vectors for instability due to the 'free' nature:
    • user tries to format the device
    • user misconfigures the file
    • user uploads garbage
  • with no UI, we have no way to help the user correct the issue
    • not totally true, we could blink morse code on the LEDs
• present a serial console, offer a basic CLI to show and edit mapping
  • this seems the simplest, the user can open a serial terminal to pico-cec and is restricted by what they can do
  • the CLI doesn't need to be complex, all it needs is:
    • show - display the mappings
    • edit - edit/add a mapping entry
      • config can be validated
  • we have text UI now, we can report errors
  • this could even provide the ability to debug the CEC traffic or other aspects
• use a PicoW
  • everything is wifi enable these days
  • we could migrate to PicoW (or ESP32) and present a simple web UI
  • this costs more and requires wifi configuration (eg SSID, key, etc)

My order of preference and ease of implementation:

• USB serial interface
• Pico W + web UI
• USB mass storage + configuration file

Apologies for the long comment, it's a really interesting discussion.
Please let me know if I have misinterpreted anything.

[dennizzzz]

@dennizzzz Thank you for the considered comment, appreciated. OK, I think I understand your motivation, allow me to offer some thoughts.

full RPi with Raspbian

Comparing to such a setup is misleading (but not incorrect). My 'other' HTPC is exactly this and indeed was my reference for what kind of 'experience' to replicate.

How can MY reference be misleading? To flatten it: a box that works very well with HDMI-CEC.

fully Pulse-Eight compatible

The Pulse-Eight HDMI CEC hardware cost is what drove me to create this project.

👍 👍 👍 The P8 is becoming rare and so the price is going up even more.

One should note however that it presents as a special USB device requiring driver installation to function. pico-cec was deliberately created to emulate an HID keyboard so it would be "plug'n'play", I would like to retain that. Furthermore, I wonder about possible legal issues with mirroring a commercial product.

The device could be configured the HID-keyboard way (better for Windows) or the P8-driver-compatible way (better for Linux). If the P8 does not have a specific patent then there are no legal grounds for this.

the flexibility of configuration could even make it better

OK, I believe this is the real core of the issue. Yes, it is inconvenient for an end user to install a full development environment because they want to map, say, 'red' button to the 'backspace'. As you note, the useful configuration is just the mapping table, and we want to expose that.

👍

There are several options:

* present as a USB mass storage device, offer a virtual filesystem and a file defining the mapping
  
  * this is possible, we can create a virtual FAT filesystem and file and allow the user to edit said file
  * this solution is challenging, it opens up a lot of vectors for instability due to the 'free' nature:
    
    * user tries to format the device
    * user misconfigures the file
    * user uploads garbage
  * with no UI, we have no way to help the user correct the issue
    
    * not totally true, we could blink morse code on the LEDs

Blink twice ... 😄 .

* present a serial console, offer a basic CLI to show and edit mapping
  
  * this seems the simplest, the user can open a serial terminal to `pico-cec` and is restricted by what they can do
  * the CLI doesn't need to be complex, all it needs is:
    
    * show - display the mappings
    * edit - edit/add a mapping entry
      
      * config can be validated
  * we have text UI now, we can report errors
  * this could even provide the ability to debug the CEC traffic or other aspects

* use a PicoW
  
  * everything is wifi enable these days
  * we could migrate to PicoW (or ESP32) and present a simple web UI
  * this costs more and requires wifi configuration (eg SSID, key, etc)

My order of preference and ease of implementation:

* USB serial interface

Yes, this could work very well with an ncurses interface. (You duplicated 'serial' here 😄 )

* Pico W + web UI

Different hardware, big 👎, and you would need to configure something to be able to configure something else. But once that is out of the way, writing complex web UI's is part of my day job.

* USB mass storage + configuration file

This would be easiest for the user, not the developer.

I would like to propose two more options:

1. A dedicated configuration application ("pico-cec-configurator" with a web UI?) that takes a compiled version of pico-cec, lets you configure everything and then flashes the entire thing.
2. Pico W + bluetooth + phone app.

Apologies for the long comment, it's a really interesting discussion. Please let me know if I have misinterpreted anything.

None needed, yes it is, only the misleading part.

[gizmomelb]

Hi all, loving this project and the ideas coming out of it. If ok, I'd like to also throw in my ideas?

From looking at the code, currently it looks like the HID USB keyboard output only responds to known general CEC codes - If the CEC code isn't known would it be possible to output the CEC code string (even just as ascii characters) to the USB HID i/o? This would be good (for devs at least) to be able to test CEC compatible remotes and buttons to implement support for various 'unused' (by this project, so far) buttons like the red, green, blue yellow etc. - potentially an addition I can work on (still wating for my Seeed RP2040s to arrive)

This potentially then may be used down the track (with something like dedicated configuration application mentioned above) to assist end users generate their own config.txt file with CEC commands to USB HID keyboard / kodi compliant commands, which is then ''baked into'' the rp2040 firmware which is uploaded to the device.

[Prikith]

@gizmomelb Currently if you build the firmware from source you get a debug firmware file, if you flash that you get a serial interface instead of the HID output. if you open a serial connection and start pressing buttons you will see all the unmapped keycodes.

If we do get a HID + Serial firmware in the future it might also be nice to implement certain features like software resetting to bootloader mode through the serial interface to get around bad access to the button on the current case design.

I'd also argue against trying to make it only pulse-eight compatible (possibly a seperate firmware file or serial command setting) since those adapters don't let you input into your bios or multi-boot select screen.

[gkoh]

@dennizzzz Long comments and replies just grow, so I'll just summarise the major thrust here quickly.
None of the suggestions are necessarily mutually exclusive or permanent.
Unlike commercial activities, we can make mistakes, try again and not get fired.
I am light on free time so obviously prefer the 'developer easy' paths.

If we avoid changing hardware, then wifi and bluetooth are out (for now).
Our options come down to:

• a terminal interface
• a mass storage device interface

These can coexist and thus should just be part of some roadmap.

I would like to propose two more options:

1. A dedicated configuration application ("pico-cec-configurator" with a web UI?) that takes a compiled version of pico-cec, > lets you configure everything and then flashes the entire thing.

I looked into Pico flashing from a web UI, it exists quite well for ESP32, but isn't there for Pico.
Ultimately, yes, this is the best way if achievable, maybe in future when easier/simpler ways to flash are created.

2. Pico W + bluetooth + phone app.

This would make sense if we did go PicoW route, let's keep it as a possible future.

[gkoh]

@gizmomelb Currently if you build the firmware from source you get a debug firmware file, if you flash that you get a serial interface instead of the HID output. if you open a serial connection and start pressing buttons you will see all the unmapped keycodes.

Just be aware that this debug mode is prone to hang. I think the serial output from multiple tasks isn't properly mutex protected.
This would be fixed if the serial UI we are discussing is implemented properly.

If we do get a HID + Serial firmware in the future it might also be nice to implement certain features like software resetting to bootloader mode through the serial interface to get around bad access to the button on the current case design.

Agreed, I can imagine useful things like:

• show and edit mappings
• reset mappings to default
• reboot
• reboot to bootloader
• dump/analyse CEC/HID traffic

I'd also argue against trying to make it only pulse-eight compatible (possibly a seperate firmware file or serial command setting) since those adapters don't let you input into your bios or multi-boot select screen.

I don't know enough about pulse-eight to make an informed comment, I defer to others.

[gkoh]

I just enabled discussions for this project, which may or may not be a place for further discussions. I'm not fussed.

[gkoh]

@gizmomelb Currently if you build the firmware from source you get a debug firmware file, if you flash that you get a serial interface instead of the HID output. if you open a serial connection and start pressing buttons you will see all the unmapped keycodes.

Just to add more, I believe both unmapped CEC messages and CEC user control messages are printed to serial.

NB. The output is not well formatted, it down right sucks, but I didn't have enough motivation to prettify it.

[dennizzzz]

I just enabled discussions for this project, which may or may not be a place for further discussions. I'm not fussed.

I would advise you to disable that again for now and just be agnostic about the differences between a real issue, a discussion posted as an issue, an issue that turns into a discussion and a discussion that leads to an issue. (Just add a 'Discussion' tag (x)or prepend the title with [DISCUSSION]) You probably don't want entropy of information where you eventually have to look everywhere for information. This means you would also rather extend the README.md than creating a Wiki or a dedicated website until that just isn't feasible anymore.

[dennizzzz]

I'd also argue against trying to make it only pulse-eight compatible (possibly a separate firmware file or serial command setting) since those adapters don't let you input into your bios or multi-boot select screen.

No, not pulse-eight compatible mode only but configurable of course.

• If P8 compatibility would be supported, what would be the default mode? (P8, HID)

[dennizzzz]

@gkoh Okay, it looks like we are landing on a terminal interface. What are the limitations/possibilities of that? Some more decisions to make ...

• Real telnet-like interface or custom a client-server (PC-Pico) interface?
• If we go for a real telnet-like interface, what would be the UI type? (CLI or ncurses ...)
• If we go for a client-server interface what would be the client UI type? (CLI, ncurses, Web, ...)
• If we go for a client-server interface what would be the fatness / thinness of each side? (I would suggest thin server in this case.)
• If we go for a client-server interface what would the protocol type be like? (Binary <=> JSON, custom <=> existing, ... )

Note that this is YOUR project (for now) and that you should make decisions (/lean towards something) based on your experience, interests and your planned investment of time. "When you point in a direction and move in that direction, you are on a path to something happening." - Me.

[dennizzzz]

@gizmomelb

... If the CEC code isn't known ... buttons like the red, green, blue yellow etc. ...

AFAIK the meat of a CEC message is just a single byte containing the standard(-ish?) code of the button pressed. The entire discussion in this issue is HOW to configure the mappings of these codes to keystrokes (or series of keystrokes?), currently these mappings are statically compiled from code and we want to at least move away from that.

I could envisage some interactive/live learning mode where you are asked to press a button (Or highlight a row associated with a button pressed) and then select the corresponding mapping or create a new mapping.

[Prikith]

@dennizzzz

• If P8 compatibility would be supported, what would be the default mode? (P8, HID)

It would probably have to be a separate firmware file if it gets implemented at all from looking at the libcec library and the way it communicates over serial with compatible adapters like the pulse-eight adapter or the raspberry pi built-in adapter and the way it handles message queuing.

Real telnet-like interface or custom a client-server (PC-Pico) interface?

You mean a serial interface? It will probably just be ascii command > response messages and you can design how you want to interact with that however you want.
Look at how other projects use serial to set settings like tasmota.

I could envisage some interactive/live learning mode where you are asked to press a button (Or highlight a row associated with a button pressed) and then select the corresponding mapping or create a new mapping.

This should be relatively easy to do once the HID + Serial is up and running.

@gkoh Since it seems like this project is getting some traction it might be worth it to look into adding a code of conduct.