Need help to understand the logic of key processing

[andrecbarros]

Hi,

I thought would be useful to process a whole sentence and send it to an application. I modified _xdo_send_keysequence_window_to_keycode_list so that it can handle properly any encoded utf8 multibyte string.

But when I try to use it I get just the first key (with any modifier that may be present).

May you give me directions of what I need to change to achieve my goal?

Best regards.

Obs.: there is some warnings I still need to clean-up but nothing really important, I think.

[andrecbarros]

Just to make things easier to understand, I made an isolated module for tests purposes.

Run it (after compiling) with: ./xdo-test '\BApenas um teste de digitação\EControl_L+C+++Meta_L+X'

Obs compiling: gcc -g -ggdb -o xdo-test xdo-test.c -I/usr/include $( pkg-config --cflags xkbcommon ) $( pkg-config --libs xkbcommon xkbcommon-x11 xcb x11 ) xdo-test.c.txt

[andrecbarros]

Fixed some mistakes. Now I know what to do, it is going to take some time.

The latest source code for tests purposes is attached below.

xdo-test.c.txt

[andrecbarros]

There are lots of changes to be made on xdo.c so that what I wanted to achieve would work. Part of the difficulty relates on key mappings done there. It is going to take some time. Help welcome.

[jordansissel]

so that it can handle properly any encoded utf8 multibyte string

I don't know of any way to type any arbitrary UTF-8 codepoint with the keyboard, so I dont' know how to achieve this with xdotool (which simulates the keyboard).

For typing, libxdo will look at the keyboard map to see if the key symbol is mapped, and if it isn't, it will try to create a mapping to an unused keycode, then it will use that keycode to type the symbol. I don't know if this is possible for all UTF-8 codepoints?

It's possible there's a way to do this using xkbcommon or by using an alternate API in X11 to send arbitrary UTF-8 as keyboard input?

[andrecbarros]

Hi,

I'm not sure, but if Control+C plus Control+V can past UTF8 chars even in simple terminals then there is a chance it will work on any application that accepts input via paste action. The worst case would be to have the keys (action) ignored, I think. So, perhaps, we could experiment put the text on clipboard buffer and issue an Control_L+V?

In this case, there are modifications that should be applied to the logic in the code (I really only saw what it does after the code failed to give the results I expected).

I think that the idea of having \B ... \E to delimit blocks would be used to insert the text on clipboard buffer. I also think that we could keep the \A ... \T. The other parts would be the same, send a key at time unless it is unmapped unicode, in which case we could send the text to clipboard and then issue Control_L+V.

What you think?

[andrecbarros]

Relevant links: https://stackoverflow.com/questions/7841832/implementing-clipboard-functionality-on-x-nix-without-access-to-event-loop https://stackoverflow.com/questions/8755471/x11-wait-for-and-get-clipboard-text

The X clipboard is quite different of Windows and OS-X counterparts. Anyway, most DE implement a clipboard buffer, but seems to me that xdotool will have to interact with them, even if in general form, to be able to insert the text

Perhaps, it would need a special new function like "string" instead of using "key"?

[andrecbarros]

Best explanations I have found: https://www.uninformativ.de/blog/postings/2017-04-02/0/POSTING-en.html https://stackoverflow.com/questions/27378318/c-get-string-from-clipboard-on-linux

[jordansissel]

I've done this in the past by with a the xclip tool. You can write to the clicpboard by passing text to stdin with xclip -i and then I would paste it with xdotool key shift+Insert

[andrecbarros]

I forgot to say that it does works with utf8 chars for some apps under xfce or kde but there are things I need to add:

• must be one key at time (to have key press and key release events properly handled). I want to modify the logic of xdotool to handle a string, instead of just a key;
• should be noted that some applications do not understand utf8 encoded symbols, not even when pasting from clipboard, and that the events generated for these symbols will confuse some (key press and then key release, I suspect it may be needed to generate a kind of different event for key release for utf8 symbols with codes that are not mapped directly to keyboard keys);
• some programs accept "Control_L+V" and past the text the clipboard manager of a particular DE has stored and some will fail with the simulation xdotool does and all I tested accepted the traditional (english) "Alt_L+e" plus "p" combination so, it must be explained to the user that some features are dependent of the application support (what seems to be the logic thing to do);
• see the attached shell script testing cases (you may need to download the xdo.c from my fork to test them under xdotool.

WARNING: do not try to use the other things that not just single composed chars (you may use \U### and other processed characters too).

Best regards.

test-utf8-xdotool.sh.txt xdo-test.c.txt

[andrecbarros]

Will give xclip a try, thanks for suggesting it, but I still think that it would be useful to implement sequencing of multi-byte utf8 encoded string chars under xdotool.

[andrecbarros]

Do you proceed with the inversion of key releases when compared with key presses on composed keys? If not that explain the strange cases of repeated chars I've been getting with composed utf8 chars (or, perhaps, it is a bug on key press / key release handling on some applications I have been testing). Hopefully, this is the source of errors I got.

[andrecbarros]

OK, what I have found so far is that, indeed, there exist a difference on key press and key release codes for some sets of characters not inside the 0x00..0xf7 range, for example, pressing AtlGr+[ on my keyboard will produce:

pressed KEY: 65027 count: 2 buffer: ª status: 4 pressed KEY: 170 released KEY: 65027 in release buffer: [ released KEY: 91

So, if we try to generate a key release 170, X may be badly impacted, I think.

The order though, indeed, seems irrelevant.

[andrecbarros]

OK, forget about the whole thing, the original code is working properly and the code I wrote had many wrong assumptions and instructions glitches. Sorry. Best regards, André

[andrecbarros]

Hi Jordan,

Redid the whole thing but now in the right place and with a better knowledge about Xlib and Xkb and their handling of utf-8, keysym and keycode.

Now it does exactly what I wanted.

May you think it can be useful to someone else or needs adjustments, let me know.

Best regards.