[Vm-dev] INFO REQUEST: key & mouse state machine / API

[Eliot Miranda]

Hi Nicolas,

> On Dec 27, 2019, at 2:28 PM, Nicolas Cellier <nicolas.cellier.aka.nice at 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/f70cf5f34041e0e197542651e90505a0b86325f6/platforms/unix/vm-display-X11/sqUnixX11.c#L4558
> 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20191229/6bebfca8/attachment.html>