Greetings,
I have a side project to get the vm-display-fbdev up on Linux using libevdev.
I am at the point where I have hacked the evtest program to capture events bu need more info to "fill out the forms" (i.e. register events).
At this point I am confused as to the current state of "Cross Platform Input Event" handling.
A state machine and usage API would be most helpful.
Current Status:
Events come in at each (debounced) keypress, with repeats [sample-events.txt].
KeyModifiers (and MouseBUttons) are tracked as expected [misc-code.txt]
I need to fill in the event structures [e.g. record-key.txt].
I have been looking through the "Porting Squeak" and source code.
As the "Cross-platform differences for CTRL keys" topic has been raised here, a state machine recognizer would be helpful to understand how mouse/key/trackpad/gamepad/.. events are recognized across platforms -- along with scancode>keycode translation mappings.
Perhaps a good project to undertake?
Any hints appreciated. I really am confused as to what mappings are required.
Thanks much, -KenD
OK. What I am gleaning is that I should map from
/usr/include/linux/input-event-codes.h #define KEY_L 38 #define KEY_PAGEDOWN 109
to:
/usr/include/X11/keysymdef #define XK_L 0x004c /* U+004C LATIN CAPITAL LETTER L */ #define XK_l 0x006c /* U+006C LATIN SMALL LETTER L */ #define XK_Page_Down 0xff56
UNICODE L -> 0x004C l -> 0x006C page down -> 0x21DF
given recordKeyboardEvent(int keyCode, int pressCode, int modifiers, int ucs4)
When I see Key: (38 = x26) 'l' -> recordKeyboardEvent( 0x006c, EventKeyChar, 0, 0x006c)
when I see Key: (38 = x26) + Shift 'L' -> recordKeyboardEvent( 0x004c, EventKeyChar, ShiftKeyBit, 0x004c)
When I see Key: (109=0x6d) KEY_PAGEDOWN -> XK_Page_Down = 0xFF56 -> recordKeyboardEvent( 0xFF56, EventKeyUp, 0, 0x21DF)
Is this close to right?
Thanks much, -KenD
Hi Ken, there is work in progress wrt keyboard events.
Currently, we have to generate: - an EventKeyDown at each keydown, and at each repeat - an EventKeyStroke if ever the key is producing a character (or several EventKeyStroke if we produce several characters) - an EventKeyUp when the key is released
Those events should have a platform independent key code in charCode field (event at: 3) And a 32 bits unicode character in utf32 field (event at: 6) - that is also known as ucs4
Currently, the key code is almost universal, but not realy, this is WIP as I said above. The code is not explicit.
It matches iso latin1 encoding for printable characters. Good news, it's also the choice of X11 KeySym and windows virtual key codes!
When Ctrl+letter is pressed, it delivers an ASCII control character (code 1 to 26) instead of the keycode of the letter But PharoVM wants the uppercase character code in both charCode and utf32 fields...
For some well known "symbolic" keys (tab escape backspace del insert pageUp pageDown arrows...) the encoding chosen by OSVM is not that of X11 KeySym. It's rather that of curses or ncurses (If I remember, it's too long ago, and too late to start searching the net), see function translateCode https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/f70cf5f34041e0e197542... We also deliver a EventKeyChar (keystroke) for these events with the same encoding for utf32 field.
You get the essentials... You will have to do something with dead keys too (^ ¨ ` etc...). Having a single keystroke with precomposed unicode would be nice, but it can eventually be 2 keystroke with decomposed unicode...
I was suggesting to further use thre reserved1 field to pass the device dependent keycode to the image, if ever we want to experiment leaner VM (and fater image!). But this will necessitate passing ore state, like caps lock, num lock, etc... See https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/456
In other issues, I tried to reverse engineer all those layers. Some are dusty, we do not change VM everyday... And when we do it, we always add, never remove code, compatibility oblige!!! I always tell that I pay removed lines twice than added, but only figurativley, otherwise my colleagues would immediately start committing many useless lines to pocket thrice ;)
Le ven. 27 déc. 2019 à 19:29, ken.dickey@whidbey.com a écrit :
OK. What I am gleaning is that I should map from
/usr/include/linux/input-event-codes.h #define KEY_L 38 #define KEY_PAGEDOWN 109
to:
/usr/include/X11/keysymdef #define XK_L 0x004c /* U+004C LATIN CAPITAL LETTER L */ #define XK_l 0x006c /* U+006C LATIN SMALL LETTER L */ #define XK_Page_Down 0xff56
UNICODE L -> 0x004C l -> 0x006C page down -> 0x21DF
given recordKeyboardEvent(int keyCode, int pressCode, int modifiers, int ucs4)
When I see Key: (38 = x26) 'l' -> recordKeyboardEvent( 0x006c, EventKeyChar, 0, 0x006c)
when I see Key: (38 = x26) + Shift 'L' -> recordKeyboardEvent( 0x004c, EventKeyChar, ShiftKeyBit, 0x004c)
When I see Key: (109=0x6d) KEY_PAGEDOWN -> XK_Page_Down = 0xFF56 -> recordKeyboardEvent( 0xFF56, EventKeyUp, 0, 0x21DF)
Is this close to right?
Thanks much, -KenD
Am Fr., 27. Dez. 2019 um 23:29 Uhr schrieb Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
Currently, we have to generate:
- an EventKeyDown at each keydown, and at each repeat
What do you mean by repeat here? That the event reoccurs if you hold the key down? I would only expect that for the character events, not for down and up events.
Le dim. 29 déc. 2019 à 14:14, Jakob Reschke forums.jakob@resfarm.de a écrit :
Am Fr., 27. Dez. 2019 um 23:29 Uhr schrieb Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
Currently, we have to generate:
- an EventKeyDown at each keydown, and at each repeat
What do you mean by repeat here? That the event reoccurs if you hold the key down? I would only expect that for the character events, not for down and up events.
Yes, I mean auto-repeat. I would have same expectations as you. I don't describe how it should be, just how it is ("currently").
Hi Nicolas,
On Dec 27, 2019, at 2:28 PM, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Hi Ken, there is work in progress wrt keyboard events.
Currently, we have to generate:
- an EventKeyDown at each keydown, and at each repeat
- an EventKeyStroke if ever the key is producing a character (or several EventKeyStroke if we produce several characters)
- an EventKeyUp when the key is released
Those events should have a platform independent key code in charCode field (event at: 3) And a 32 bits unicode character in utf32 field (event at: 6) - that is also known as ucs4
Currently, the key code is almost universal, but not realy, this is WIP as I said above. The code is not explicit.
It matches iso latin1 encoding for printable characters. Good news, it's also the choice of X11 KeySym and windows virtual key codes!
When Ctrl+letter is pressed, it delivers an ASCII control character (code 1 to 26) instead of the keycode of the letter But PharoVM wants the uppercase character code in both charCode and utf32 fields...
For some well known "symbolic" keys (tab escape backspace del insert pageUp pageDown arrows...) the encoding chosen by OSVM is not that of X11 KeySym. It's rather that of curses or ncurses (If I remember, it's too long ago, and too late to start searching the net), see function translateCode https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/f70cf5f34041e0e197542... We also deliver a EventKeyChar (keystroke) for these events with the same encoding for utf32 field.
You get the essentials... You will have to do something with dead keys too (^ ¨ ` etc...). Having a single keystroke with precomposed unicode would be nice, but it can eventually be 2 keystroke with decomposed unicode...
I was suggesting to further use thre reserved1 field to pass the device dependent keycode to the image, if ever we want to experiment leaner VM (and fater image!). But this will necessitate passing ore state, like caps lock, num lock, etc... See https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/456
In other issues, I tried to reverse engineer all those layers. Some are dusty, we do not change VM everyday... And when we do it, we always add, never remove code, compatibility oblige!!! I always tell that I pay removed lines twice than added, but only figurativley, otherwise my colleagues would immediately start committing many useless lines to pocket thrice ;)
Indeed. One idea would be to split the file into three. One would be a small “root” file that includes either sqUnixX11Legacy.c or sqUnixX11Spur.c. The existing, or last known good, or 4.5 release version would be made into sqUnixX11Legacy.c, and the current version into sqUnixX11Spur.c. We can then remove any backward compatibility prior to 4.6, which IIRC is the first Spur release, or 5.0 if we don’t care about 4.x with Spur, since 4.6 was really a prerelease. We leave sqUnixX11Legacy.c to rot, only ensuring it can compile, and attempt to cleanup sqUnixX11Spur.c as best we can.
Does that make sense? Are there better ideas? Are there better file organizations, such as having Spur and legacy directories? (eg unix/vm-display-X11.spur unix/vm-display-X11.legacy, better for searching, etc)
Le ven. 27 déc. 2019 à 19:29, ken.dickey@whidbey.com a écrit :
OK. What I am gleaning is that I should map from
/usr/include/linux/input-event-codes.h #define KEY_L 38 #define KEY_PAGEDOWN 109
to:
/usr/include/X11/keysymdef #define XK_L 0x004c /* U+004C LATIN CAPITAL LETTER L */ #define XK_l 0x006c /* U+006C LATIN SMALL LETTER L */ #define XK_Page_Down 0xff56
UNICODE L -> 0x004C l -> 0x006C page down -> 0x21DF
given recordKeyboardEvent(int keyCode, int pressCode, int modifiers, int ucs4)
When I see Key: (38 = x26) 'l' -> recordKeyboardEvent( 0x006c, EventKeyChar, 0, 0x006c)
when I see Key: (38 = x26) + Shift 'L' -> recordKeyboardEvent( 0x004c, EventKeyChar, ShiftKeyBit, 0x004c)
When I see Key: (109=0x6d) KEY_PAGEDOWN -> XK_Page_Down = 0xFF56 -> recordKeyboardEvent( 0xFF56, EventKeyUp, 0, 0x21DF)
Is this close to right?
Thanks much, -KenD
vm-dev@lists.squeakfoundation.org
-
Eliot Miranda -
Jakob Reschke -
ken.dickey＠whidbey.com -
Nicolas Cellier