add support for Pico Keyboard

[qufb]

Moved from libretro#205

---

These changes introduce a new input method for the Pico Keyboard, a PS/2 peripheral for the Sega Pico, allowing emulation of games that use this peripheral:

• Keyboard Pico - Kantan Waku Waku Keyboard
• Keyboard Pico 2 - Sawattemiyou! Yoiko no Hajimete Keyboard
• Kitty to Minna no Keyboard Pico - Kitty to Minna no Hajimete no Keyboard!
• Kibodeu Piko

Requires a dedicated input update function for frontends, implemented in my libpicofe pull request (irixxxx/libpicofe#1). Once that one is merged, I can update the submodule repository in this one.

Since the original input handling used a bitmask for mapping keys to events, the larger number of keys required for this peripheral had to be implemented in another way, in this case it uses an array that is associated with a single input binding type (IN_BINDTYPE_PICO_PS2).

In order to sufficiently test the keyboard, I found that activating most minigames requires interacting with the Storyware via the pen button. Since these games don’t render a pen cursor, I added a pen position overlay to guide a player, disabled by default.

Tested under Linux with the generic SDL frontend.

Limitations

• Key bindings are hardcoded at compile time (see ./platform/common/input_pico.h and ./platform/common/inputmap_kbd.h), missing logic to allow reading and storing to configuration file.

For more context, see the following documentation: https://qufb.gitlab.io/writeups/pico#keyboard-pico

[irixxxx]

sorry it takes so long. I'm currently busy with a lot of offline tasks which prevents me from doing much development.
I'm looking into a more general approach, to include the SC3000 as well.

[qufb]

No worries. I also haven't look much into the libretro part, but it will probably be similar to the dedicated keyboard input that was done some time ago for a Dreamcast core (https://www.libretro.com/index.php/reicast-libretro-now-supports-the-keyboard-as-an-input-peripheral/)

[irixxxx]

@qufb are you still available for this? I have finally come around to do the preparations for SC-3000 support, hence we could now discuss how to generalize your approach in libpicofe and picodrive in a way that would allow using it for both pico and SC-3000.

[qufb]

Right now I'm focused on other projects, but you can leave some comments on the pull request and I'll try to address them when I have time.

From what I recall, the new input update functions on libpicofe are probably what is more convenient to generalize for any keyboard-based input. The rest of the stuff like key mappings will be different.

[irixxxx]

This seems to be getting fairly complicated when considering international keyboard layouts:

• the SDL1.2 keysym contains sym and mod. sym has the base key value, no matter what the modifier state is, so e.g. pressing the 'A' key always gives you 'a' as sym, no matter what modifiers are additionally pressed. While this is rather straight forward for alpha characters, it is by no means for anything else. You can't even count on the number keys, if you look at the french layout those are only accessible with the shift modifier. I would need to know the current layout, which SDL isn't providing me with.
• the scancode is hardware dependent and as such unusable, so just mapping keys 1:1 to the desired layout ignoring what the actual mapping is in the users' layout isn't working.
• the only way seems to be to get the Unicode value for the character, but that would require mapping to the desired keyboard matrix, including simulating modifier keys if needed.

International keyboard layout can be quite different even for Latin letter keyboards, just look at the french one. What a mess.