Feature #1227
closed
Need keyboard support for volume up/volume down.
100%
Description
The autokiosk system is playing audio with rather low volume. If a keyboard were connected then the arrow up/down keys could be used to adjust the volume of the video playback. Support for this is already in videofe for touchscreens. It just needs to be extended to support keyboards.
If this works then all touchscreen features can be extended to keyboards because most, if not all, of them are simply system calls to the dbuscontrol.sh script.
Note: This may already work because key presses on non-kiosk playback already handles fast-forward and next-video even though those keypress evevents are not handled by key_press() in videofe.c. Try "+" for volume up and - for volume down.
Related issues
Updated by Hammel 24 days ago
- % Done changed from 0 to 40
The "+" and "-" keys didn't appear to work, but then I found the RCA plug was pushed too far into the Pi so audio wasn't playing correctly. I need to retry with the plug properly inserted to see if these keys have any affect. I don't think they do, as these are supposed to map to omxplayer but I'm not sure they are. Some of the other omxplayer keyboard bindings do work, so it's not clear yet. I'll have to retest to verify.
VideoFE has been updated to support key presses to bump audio up and down via dbuscontrol.sh so I can try that if the omxplayer key bindings don't work. To do that I need to copy the existing VideoFe out of the way before uploading the new version, and this can't be done unless the Pi is connected to the network. So it will have to brought to the test station and plugged into a TV.
Updated by Hammel 7 days ago
Capturing keyboard input in videofe doesn't work because matchbox has the xterm over videofe. Even if I try to keep the window on top via gtk function it doesn't work. Keyboard focus goes to the xterm.
So this idea doesn't work. I can map around the X input events by reading /dev/input directly and using the evdev interface. That will require some special decoding, I think. But keyboards differ on their keycodes for up/down left/right keys.
For the MCSaite tiny keyboard and the FAVI keyboards:
Event: time 1761086642.192100, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70052 Event: time 1761086642.192100, type 1 (EV_KEY), code 103 (KEY_UP), value 1
This is fine for now. I can write a thread that watches the keypresses and then calls the key_press() function via a mutex. And I can write a keyboard discovery function similar to libpibox:touchProcessor.c:ts_setup(). While that will FIND keyboards it doesn't present a mapping to which codes go with which arrow keys. I'll need some kind of external map that matches the keyboard name or similar.
Updated by Hammel 5 days ago
- Status changed from New to In Progress
- % Done changed from 40 to 80
Ported input dev handling from libpibox for touchscreens into videofe for handling keyboards. It's not ideal - it only handles the first keyboard it finds and the keyboard needs to be connected before the application starts - but it basically works.
More importantly, videofe was incorrectly tying start of DBUS handling to use on LCDs only. This has been changed so that either LCDs or AutoKiosk will enable DBUS support. This was preventing key presses captured by the new events thread in videofe from sending messages to omxplayer. Once this was fixed, keypresses are passing messages to omxplayer.
And it appears to be working. Certainly Next and Previous video commands are working. I need to validate audio changes be hooking up a speaker to the RPi.
For now, only up/down (audio) and left/right (video) and ESC (exit) are supported in this way.
I also need to retest videofe on- Media
- Player (maybe - Media might be enough)
- Kiosk
Update¶
Verified audio up/down does work. Yippee!
Update 2¶
Media Player verified working with these changes, although (and as expected and designed) with Media Player videofe does not handle keyboard input - omxplayer does that itself.
h2: Update 3
Worked fine on kiosk.
I'm not worried about player since this feature is not enabled on non-kiosk systems, as Media tests showed.
Code is committed and pushed
Closing issue.