-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No ESC key. #13
Comments
Yes, there is no ESC key by default, all four top buttons don't send any events over USB. This can be changed by customizing the firmware, you can chose one of the values from here https://github.com/solderparty/i2c_puppet/blob/main/app/keyboard.h#L25 and fill it out here: https://github.com/solderparty/i2c_puppet/blob/main/app/usb.c#L63 |
Thanks for your help. I'm making progress with the changes. I'm also adding Control-characters. |
Finally got it working with control codes and the missing ASCII characters remapped to the top 4 keys. I will make the repository available in a bit. |
Here's my updated version with the missing characters |
Thank you, grymoire, I was missing these as well for use with linux (and raspberry pi's :-)) I noted in xev, that keypresses are immediately followed by release events, also there's no middle mouse button, and the longpress on the mouse sensor/key is funny: button1 press+release, 1s, button 3 press, [waiting for user to release key], button 3 release. Also there's no way to send any (and also the more useful separate) lshift/lalt press/release events (maybe with your version for ctrl/sym?) . Separate press/release would also allow key repeat while the key is pressed on linux. What would you suggest to use to add these further missing keys and buttons, something like ctrl-lshift, with the currently sent ESC key being delayed with a timeout? (lshift on the bb20 for me is a bit funny in my fw version: ESC press+immediate-release, then IFF further kept press + a letter key, it continues to immediately send the combo of shift press, key press, key release, shift-release, which - same as button3 - has quite restricted usability). Do you think splitting the press/release events is feasable given the structure of the i2c-puppet (and ram/flash space constraints)? (All I did upto now, was merely a very quick skimming the source to confirm that the keys I couldn't trigger are indeed missing, and while you made my day, I've also still to look into building the firmware to update my bb20. Too little time..., sigh) Thx, |
First of all, look at LINUX Readme to see how I debugged the code. It might help you if you make any modifications. You can add as many print commands you want without affecting the keyboard functionality. Second - I didn't modify the basic flow of the code much. Arturo has a SYM-lock and number-lock mechanism, and he distinguishes between presses and releases, and the mouse functions. I left that alone, but and frankly didn't spend much time understanding all of the logic flow. To be honest, I didn't need to. So, honestly, I'm not sure how to answer your question. Maybe Arturo can offer some advice. |
@grymoire thanks for your notes, they are very helpful! I have been commenting the code base here https://github.com/rej696/bbq20/tree/rowan with a view to do something similar to you, but to refactor things slightly to more easily allow custom keymaps and layers like QMK (rather than hardcoding characters). I saw that you also modified the hex values of the KEY_X_Y macros for the buttons etc. would you be able to explain why you had to do that? Additionally, I am a bit confused by the difference between kbd_entries and btn_entries, as they both seem to be handled in the same way, and it appears that the right button is considered a button (in the btn_entres table) and the other buttons are considered keys (in the kbd_entries table). Can anyone explain why this is and what is going on here. |
As I recall, I had the keyboard working, but when I tried the Linux login screen, some buttons - like DELETE - didn't work. I think that's why I modified the KEY_X_Y map. It's been a while, and I have some personal things to take care up. I'll check it out later when I have time. |
I just looked at the code again and at my keyboard.h file. His original
version mapped the buttons on the keyboard to have the values 0x0 to 0X12
So what happens if you have the BB Q20 keyboard plugged into a linux
machine the same time as you have a real linux keyboard attached (i.e. I am
debugging the code on a Linux laptop)?
For instance, Control-A is hex 0x01.
But 0X01 is also the KEY_JOY_UP or up-arrow.
And the Left Shift modifier is 0X1B - which is the ESC button. How can I
type an ESC button in vi(1) if it is a shift modifier?
I wanted there to be a difference between the BBQ20 keyboard pressing
<newline>, <control-A>, etc and the keyboard doing the same thing. So I
added hex 0x80 to all of the BBQ20 keystrokes (this is the parity (8th) bit
for a 7-bit character set. So the difference between BBQ20 and the real
Linux keyboard was clear. Any character with the 8th bit set came from the
BBQ20 keyboard.
If not, it came from the real Linux keyboard.
Is that clear enough?
Frankly, without doing this, debugging would be very hard. And it didn't
really make a difference to the BBQ20 code - as they were just constants.
p.s. The modification to the kbd_entries[] array was needed so backspace
would work on the login page.
…On Sun, Jul 9, 2023 at 4:08 PM rej696 ***@***.***> wrote:
@grymoire <https://github.com/grymoire> thanks for your notes, they are
very helpful! I have been commenting the code base here
https://github.com/rej696/bbq20/tree/rowan with a view to do something
similar to you, but to refactor things slightly to more easily allow custom
keymaps and layers like QMK (rather than hardcoding characters). I saw that
you also modified the hex values of the KEY_X_Y macros for the buttons etc.
would you be able to explain why you had to do that?
Additionally, I am a bit confused by the difference between kbd_entries
and btn_entries, as they both seem to be handled in the same way, and it
appears that the right button is considered a button (in the btn_entres
table) and the other buttons are considered keys (in the kbd_entries
table). Can anyone explain why this is and what is going on here.
—
Reply to this email directly, view it on GitHub
<#13 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAX3WUAXOZEWFKLZYMP5VCLXPMFUPANCNFSM5ZQSA33Q>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I tried the keyboard on a raspberry pi, and quickly found no ESC key.
I couldn't even hit CNTL-[
This made exiting vi difficult..
The text was updated successfully, but these errors were encountered: