Make key mapping configurable. #11
Comments
|
Interesting suggestion.
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. |
|
@dennizzzz Thank you for the considered comment, appreciated.
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.
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.
OK, I believe this is the real core of the issue.
My order of preference and ease of implementation:
Apologies for the long comment, it's a really interesting discussion. |
How can MY reference be misleading? To flatten it: a box that works very well with HDMI-CEC.
👍 👍 👍 The P8 is becoming rare and so the price is going up even more.
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.
👍
Blink twice ... 😄 .
Yes, this could work very well with an ncurses interface. (You duplicated 'serial' here 😄 )
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.
This would be easiest for the user, not the developer. I would like to propose two more options:
None needed, yes it is, only the misleading part. |
|
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. |
|
@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. |
|
@dennizzzz Long comments and replies just grow, so I'll just summarise the major thrust here quickly. If we avoid changing hardware, then wifi and bluetooth are out (for now).
These can coexist and thus should just be part of some roadmap.
I looked into Pico flashing from a web UI, it exists quite well for ESP32, but isn't there for Pico.
This would make sense if we did go PicoW route, let's keep it as a possible future. |
Just be aware that this debug mode is prone to hang. I think the serial output from multiple tasks isn't properly mutex protected.
Agreed, I can imagine useful things like:
I don't know enough about pulse-eight to make an informed comment, I defer to others. |
|
I just enabled discussions for this project, which may or may not be a place for further discussions. I'm not fussed. |
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. |
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. |
No, not pulse-eight compatible mode only but configurable of course.
|
|
@gkoh Okay, it looks like we are landing on a terminal interface. What are the limitations/possibilities of that? Some more decisions to make ...
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. |
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. |
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.
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.
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. |
It depends on the CEC message. ie: if we were wanting to display some feedback from the dongle (playback device 1) to the display device (display device 0) then we could send a CEC frame' like 40:64:00:74:65:73:74 and it would display ''test" using the display device's OSD (created using this site - https://www.cec-o-matic.com/ ). I feel this could be used as at the very least as a test diagnostic to display what different button codes have been pressed on the remote, so that the frame/button code can then be noted and be used to remap buttons. Any potential 'unique' codes (ie: SONY being a great example of doing things in a non-standard fashion) could then be discovered and help the end user to map the codes to KODI functions. My LG TV remote doesn't have a subtitle / text button on it, so mapping that for subtitle enable / disable would be nice - I can see in your code submission you're using CEC frame command 51 to enable subtitles - that is PIP (Picture in Picture), which my remote also doesn't have.. so it won't work for all devices.
Agreed. But since all remotes don't have all functions we need to be able to first display the CEC code for each button that may be remapped on screen, so at the very worst the end user can write down the button code number, then use a separate app to generate the mapping config file which the dongle can then interpret.
See above. I've finally received my Seeed rp2040s so I'm hoping to spend some time tinkering this coming weekend. |
|
@gizmomelb About the CEC messages, yes they can be longer, but I was talking about the messages related to button presses. And furthermore, they might all be possibly great ideas but @gkoh first needs to make some decisions about where to go next. |
|
See #13 for the most basic foundation to support the features discussed here. For this issue (configurable user keymap):
|
|
@gizmomelb Hope you were able to get your rp2040s going. I'm going to split out the vendor support to a new issue. Unlike the user control keymap, vendor commands don't appear to be strictly defined. Edit: see #14 |
|
with serial output enabled I've seen a youtube video where the user wrote data to a (MacOS) desktop, so data could be exported from the rp2040 to an external desktop app like that.. or reading and writing keymap settings to a fat32 file system with SDcard could be added like as shown here - https://youtu.be/JrYT7aJnP_I?t=610 |
|
@gizmomelb What problem are you trying to solve here? AFAICT @gkoh is working on full serial communication with a CLI. Why would we need to read/write from/to an SD card? One of my suggestions was to emulate a USB stick. Is this related perhaps? |
Yes, sorry I was thinking aloud for an easy solution to write/read remote control and keyboard bind configs for end user. Potentially using serial communication may not be easiest for end users (also I am thinking now about binding key configs to different keyboard keys for Kodi / Jellyfin client / VLC / MPC-HC support). all outside the scope of this project at the moment. |
|
@gizmomelb No apologies necessary. I was just wondering where you were going with that. I was thinking about how a Kodi plugin for configuring the pico-cec might work. Since the up/down/left/right/enter buttons are standard (correct?) you could configure the rest from within Kodi. (If Kodi is allowed to open a serial connection of course.) |
|
hey all.. ok I've re-read this thread and here are my observations and thoughts. GKoh's initial vision was for a plug and play device which would mimic a usb keyboard to output key pressess in response to specific HDMI CEC commands. This also allows the dongle to control other media player apps besides KODI. Therefore we need to be able to store the (eventually) user defined key presses somehow on the RP2040 without it being encoded into the compiled uf2 file - so the file needs to either be able to be stored in the 2MB FLASH on the RP2040, OR needs to be accessible another way on boot (without the RP2040 being connected to a PC) if the RP2040 loses power by being unplugged or the host device being switch off etc. FUTURE STUFF: As an aside - the VCC and GND pins on the underside of the Seeed XAIO RP2040 can be connected to HDMI pins 17 (GND) and 18 (+5V) to continuously power the RP2040 even when it is not drawing power from USB. This could be useful with some extra investigation I am doing with powering down the host pc and using WAKE ON LAN to start it back up - useful for the HDMI CEC power on / power off along with the TV and AVR etc.) If we can read the config file from RP2040 FLASH, then serial over USB is fine for storing the config file on the RP2040. However if we cannot easily store the config file in the flash, then may I suggest using SPI and an SD CARD as a way for the RP2040 to read the config file at boot time? The data format could be like dennizzzz suggested in the first post and essesntially be a lookup table (referenced in the HDMI-CEC.C code loop) where the CEC command is looked up and then the second data lot is output to the USB keyboard. We may also need a value (or value pattern such as &FFFF) to distinguish between values in the 'list' / signify end of data. eg:first value is CEC code value, followed by the HID_KEY command/string x00,&FFFF,HID_KEY_ENTER command,&FFFF FUTURE STUFF: With development this may potentially allow ''macros'' to be run where a HDMI CEC command could be configured by the user and the configured keyboard output is text string which could be used to launch a program, shutdown a pc etc. So to me the main thing seems we need to define the data format for the key configuration and how it is implemented So my newbie code loop would be something like: Initialisation: (system is fresh booted) sorry, gotta go.. just some thoughts and trying to get back on track. |
|
ok found this article about writing to the flash - https://www.makermatrix.com/blog/read-and-write-data-with-the-pi-pico-onboard-flash/ |
Thanks. RP2040 flash access requires interrupts to be disabled before access to prevent corruption.
|
I did originally look into dual-power (VIN + USB-C) and it was unclear if the power protection was sufficient to prevent smoke. It will interesting to see what you find. Responding to CEC 'power on' actually adds a third category of command mapping, so the three are now:
|
|
also having even a basic checksum when saving / loading the config will help avoid any corruptions. I'm not an experienced programmer but I'm willing to have a go, especially the stuff outside of the main loop. That way I hopefully can't stuff up too easily :) |
There still has to be a statically compiled default/base configuration. Reading about wear and tear of flash memory, I suggest we split up what we write into:
Upon booting pico-cec reads A to get the address of C. A should start with a 4 byte magic number to identify it as an address block. If A does not have the magic number we do not read C and we revert to the statically compiled configuration. If A does have the magic number we parse the configuration from C. When we change the configuration it gets prepared for writing to C, a CRC is calculated and put at the end. When the configuration is written to C, we read back C but NOT as configuration, recalculate the CRC, and match with the previously written CRC. If the CRC does not match then C is corrupt, A will be changed to point to an 8KB lower address to a new C and the prepared configuration block will be written to C and rechecked with CRC. Two(?) consecutive write fails indicates flash failure. How to deal with that?
No. The pico-cec needs to work stand-alone. So we don't read/write a file, we read/write blocks of flash. The way flash works does impact the flow of pico-cec. We can't record a button and write it to flash immediately. We need to record all the buttons to RAM and then write the configuration as a single block. Other than that your suggested loop looks reasonable. I also think that there should be something like the Konami code to do a "factory reset" with the remote control. Ah, I see now some of our comments have crossed each other, we appear to be in sync on most of this. Of course, with another level of address block indirection you could flash the configuration 20 * 20 * 20 = 8000 times. |
Changing the key mappings requires recompilation. Extracting them to a file would make the system way more flexible.
Example:
Thoughts?
The text was updated successfully, but these errors were encountered: