More consistent typing

[gerw]

There are some issues like #414, where wrong keys are typed. This might be due to the fact that for typing, the xtest keyboard is used, but xdotool uses another keyboard to map keysyms to keycodes.

I tried to fiddle around and the changes in my repository seem to heal these issues. In some rare occasions, I still get some wrong key presses, though.

[gerw]

Now, I have realized that it is even more complicated:

If the variable use_xtest in _xdo_send_key is false, the keys are typed with XSendEvent. This utilizes the mapping of the last used keyboard device (I think this is the Core Keyboard Mapping). In this situation, the old code produces the correct result and the code from this PR might fail.

But it can be even weirded. Consider

xdotool key --window 39845900 o key o key --window 39845900 o

The first o is typed in another window, using the core keyboard mapping and this is the mapping of the keyboard which was used last. The next o is typed into the current window using XTestFakeKeyEvent, i.e. it is using the mapping from the xtest keyboard. This also sets the core keyboard mapping to the mapping of the xtest keyboard. Consequently, the last o is typed again with the core keyboard mapping which now equals the mapping from the xtest keyboard...

[jordansissel]

This is some good insight about the switching between keyboard devices on x11.

I’m wondering if, assuming it can be done correctly, the keyboard mapping code would need to put mappings onto the right xinput device instead of what xdotool does today?

It’s been a while since I’ve had my brain deep into the keyboard mapping code, though, so my mental model of things is a bit stale ;)

On Wed, May 29, 2024, at 10:32 AM, Gerd Wachsmuth wrote:

Now, I have realized that it is even more complicated:

If the variable use_xtest in _xdo_send_key is false, the keys are typed with XSendEvent. This utilizes the mapping of the last used keyboard device (I think this is the Core Keyboard Mapping). In this situation, the old code produces the correct result and the code from this PR might fail.

But it can be even weirded. Consider

xdotool key --window 39845900 o key o key --window 39845900 o The first o is typed in another window, using the core keyboard mapping and this is the mapping of the keyboard which was used last. The next o is typed into the current window using XTestFakeKeyEvent, i.e. it is using the mapping from the xtest keyboard. This also sets the core keyboard mapping to the mapping of the xtest keyboard. Consequently, the last o is typed again with the core keyboard mapping which now equals the mapping from the xtest keyboard...

— Reply to this email directly, view it on GitHub https://github.com/jordansissel/xdotool/pull/462#issuecomment-2137928861, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABAF2XU3SCMKESTFAGPJWTZEYGKLAVCNFSM6AAAAABIOOJDJCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZXHEZDQOBWGE. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[gerw]

I’m wondering if, assuming it can be done correctly, the keyboard mapping code would need to put mappings onto the right xinput device instead of what xdotool does today?

Yes, but this depends on the method which is used to send the keycodes (xtest vs XSendEvent) and might also change during execution...

[gerw]

I pushed a further commit. This is the best that I came up with. The only downside is that now, _xdo_populate_charcode_map is used in two methods with have a const xdo_t *xdo and the const is casted away... I am not sure how to deal with this...