Problem with the number keys on the keyboard

[vavelpo]

The number keys 1 to 9 on the keyboard are not working, confirmed on the Windows and Android versions. The numeric keypad is fine.

This is not a problem on the desktop version of QUASI88.

Windows 10 64bit
RetroArch 64bit 1.10.3
QUASI88 0.6.4 2548625

[gilmorem560]

I did some tinkering in the keyboard code last night, I'm not in a place to make a PR or anything but some of the changes that may be necessary in libretro.c are:

quasi88-libretro/src/LIBRETRO/libretro.c

Line 141 in ff94d9d

else if (!key_on)

As an example here, the key off case is not also checking if the key event has already been intercepted (i.e. not checking that key_buffer[key] is true). I found adding a check on the key buffer value fixed issues with keys like comma, period, etc. not working for me.

Another problem is in the method starting here:

quasi88-libretro/src/LIBRETRO/libretro.c

Line 208 in ff94d9d

static void handle_input(void)

Therein are established all the mappings between KEY88 enum members from Quasi88 and the libretro RETROK key codes. Several assumptions are made like:

   /* Basics, numbers */
   for (i = 0; i < 64; i++)
      handle_key(i, i);

which assumes the first 64 keycodes are exact matches...which is not entirely the case. I've completely redone the key mappings in a local copy and things tend to behave much better. However, I suspect I'm not catching everything, that or there may be enum members on one side or the other that aren't mapping right, because for instance if I map

handle_key(KEY88_APOSTROPHE, RETROK_QUOTE);
handle_key(KEY88_QUOTEDBL, RETROK_QUOTEDBL);

Then I inexplicably get a single quote/apostrophe printed when I try and type a double quote...I then get a 7 if I try to type a single quote without shift held.

This is my first exposure to this codebase, so I'm sure there's something I'm missing, but that's my assessment, the handle_key and handle_pad methods need to ensure they're checking their respective butters on every operation and that the key mapping is done a bit more precisely rather than with assumptions about ranges of keycodes matching between the two sides.

Additionally, there is possibly a performance boost in there because right now, handle_key and handle_pad are constantly calling quasi88_key() when a key isn't pressed because they aren't checking their respective buffers to see if the key change has already been emitted. Only key press is doing this. These constant key up events going away may be another benefit.

Good luck!

[celerizer]

Thank you very much for the detailed write-up! I would encourage a PR if you get a chance, as it's unlikely anyone else will contribute all the changes listed. When I wrote the keyboard stuff it was "good enough" for my own usage and I hadn't heard complaints, so I'm not surprised there are some key mismatches and will happily take any improvements

…

On Thu, Aug 15, 2024, 1:16 PM Matthew Gilmore ***@***.***> wrote: I did some tinkering in the keyboard code last night, I'm not in a place to make a PR or anything but some of the changes that may be necessary in libretro.c are: https://github.com/libretro/quasi88-libretro/blob/ff94d9d2884d71580c163fcd71b6850c0f393f44/src/LIBRETRO/libretro.c#L141 As an example here, the key off case is not also checking if the key event has already been intercepted (i.e. not checking that key_buffer[key] is true). I found adding a check on the key buffer value fixed issues with keys like comma, period, etc. not working for me. Another problem is in the method starting here: https://github.com/libretro/quasi88-libretro/blob/ff94d9d2884d71580c163fcd71b6850c0f393f44/src/LIBRETRO/libretro.c#L208 Therein are established all the mappings between KEY88 enum members from Quasi88 and the libretro RETROK key codes. Several assumptions are made like: /* Basics, numbers */ for (i = 0; i < 64; i++) handle_key(i, i); which assumes the first 64 keycodes are exact matches...which is not entirely the case. I've completely redone the key mappings in a local copy and things tend to behave much better. However, I suspect I'm not catching everything, that or there may be enum members on one side or the other that aren't mapping right, because for instance if I map handle_key(KEY88_APOSTROPHE, RETROK_QUOTE); handle_key(KEY88_QUOTEDBL, RETROK_QUOTEDBL); Then I inexplicably get a single quote/apostrophe printed when I try and type a double quote...I then get a 7 if I try to type a single quote without shift held. This is my first exposure to this codebase, so I'm sure there's something I'm missing, but that's my assessment, the handle_key and handle_pad methods need to ensure they're checking their respective butters on every operation and that the key mapping is done a bit more precisely rather than with assumptions about ranges of keycodes matching between the two sides. Additionally, there is possibly a performance boost in there because right now, handle_key and handle_pad are constantly calling quasi88_key() when a key isn't pressed because they aren't checking their respective buffers to see if the key change has already been emitted. Only key press is doing this. These constant key up events going away may be another benefit. Good luck! — Reply to this email directly, view it on GitHub <#63 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AH5UPFXBPOKCO2NZOVVDKIDZRTWBNAVCNFSM6AAAAABMSVHJCGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJRHA4TAMZZGM> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[gilmorem560]

It'll probably just be a patch I post here, this account is tied to my day job and so I tend to shy away from non-work related commits, just issue chit chat. I use GitLab for my personal stuff for a clean separation but I don't think I can fork and merge across providers...never tried anyway.

I'll keep playing with this the next few days and see if I can get the keyboard stuff into a more reliable spot. Then I'll spit out a diff and post it in a comment here.