Why double translation on keydown?

[Shachar Shemesh]

Hi all,

The current code for keyboard translation goes something like this, if I
understood it correctly:

* An X11 event arrives with the physical keycode for the key pressed.
    * Said code is translated into a VKey based on the current keyboard
      (fair enough)
    * Keycode is translated into a, well, keycode for Windows. 99% of
      the cases this is the same one, as it's the same PC keyboard as ever.
    * The vkey and translated keycode are sent as WM_KEYDOWN or
      WM_SYSKEYDOWN events.
    * In all probability, the process calls TranslateMessage
    * TranslateMessage calls (indirectly) X11DRV_ToUnicodeEx
    * X11DRV_ToUnicodeEx takes the virtual key, looks it up (using a for
      loop!!!!) in the same table consulted before to find out what the
      original X11 keycode was.
    * That vkey is passed, after some manipulation, to XKeysymToKeycode
      to produce a keycode
    * Said keycode is passed to XLookupString to get an actual key for it

This process seems, to me, overly long and inefficient. It requires
building fairly complex lookup tables for both vkey and Windows keycode.
I fail to see what is gained. Why not use the following process instead:

* An X11 event arrives
    * Use the native keycode as the keycode.
    * Translate the vkey as before.
    * Send WM_(SYS)KEYDOWN as before
    * In X11DRV_ToUnicodeEx:
    * Use the keycode to lookup with key using XLookupString

I fail to see why the forward and backwards translation is good for.

Explanation?

Shachar

[Dmitry Timoshkov]

"Shachar Shemesh"  wrote:
> This process seems, to me, overly long and inefficient. It requires
> building fairly complex lookup tables for both vkey and Windows keycode.
> I fail to see what is gained. Why not use the following process instead:
> - An X11 event arrives
> - Use the native keycode as the keycode.
> - Translate the vkey as before.
> - Send WM_(SYS)KEYDOWN as before
> - In X11DRV_ToUnicodeEx:
> - Use the keycode to lookup with key using XLookupString

X11DRV_ToUnicodeEx is a backend of the Win32 API ToUnicodeEx and it takes
a virtual key code. I.e. ToUnicodeEx takes a predefined input and should
return data very closely resembling what Windows does.

[Shachar Shemesh]

Dmitry Timoshkov wrote:
> X11DRV_ToUnicodeEx is a backend of the Win32 API ToUnicodeEx and it takes
> a virtual key code. I.e. ToUnicodeEx takes a predefined input and should
> return data very closely resembling what Windows does.

Ok, then maybe we should have TranslateMessage not call that, and use
something else instead? This is particularly prominent from this
sentence in the ToUnicodeEx documentation
(http://msdn2.microsoft.com/en-us/library/ms646322.aspx):
> The parameters supplied to the ToUnicodeEx function might not be
> sufficient to translate the virtual-key code because a previous dead
> key is stored in the keyboard layout.

Maybe I don't understand the code well enough, but it seems to me that
we report on the dead-key press, but not translate the following
character. Is that correct?

Shachar

[Dmitry Timoshkov]

"Shachar Shemesh"  wrote:
> > X11DRV_ToUnicodeEx is a backend of the Win32 API ToUnicodeEx and it takes
> > a virtual key code. I.e. ToUnicodeEx takes a predefined input and should
> > return data very closely resembling what Windows does.
>
> Ok, then maybe we should have TranslateMessage not call that, and use
> something else instead?

For instance what? Apparently Windows does use ToUnicodeEx internally in
TranslateMessage, if you are planning to change that you have to make sure
that current semantics doesn't change. In any case nothing prevents the apps
to call ToUnicodeEx on their own while handling WM_KEYxxxx messages.
> This is particularly prominent from this
> sentence in the ToUnicodeEx documentation
> (http://msdn2.microsoft.com/en-us/library/ms646322.aspx):
> > The parameters supplied to the ToUnicodeEx function might not be
> > sufficient to translate the virtual-key code because a previous dead
> > key is stored in the keyboard layout.
>
> Maybe I don't understand the code well enough, but it seems to me that
> we report on the dead-key press, but not translate the following
> character. Is that correct?

winex11.drv never reports dead keys to the applications, dead keys are
handled internally.