I have tested 13 distros from my test suite, only one showed the fault that is plaguing desliem !
Amazing amount of work by dbannon. Thank you very much.
Your research explains why the bug has been so rarely reported. I'll be much more circumspect about the need to edit XKeyInput in my GitHub project that uses the lazmouseandkeyinput package.
Just fixing it by replacing the boolean ? The devs, quite rightly, like to understand the issue before acting. When playing with compilers and libraries, the side effect can be very off to one side and not show up until much later.
Must agree with dbannon, of course. It also strikes me that my "explanation" for the need to use a longbool type doesn't really make sense. After all KeyUp with the letter B (and most other keys, including O which the OP reported on) works with the is_press type being boolean on my system.
Looking at it from another perspective, the
current code for XTestFakeKeyEvent (
https://gitlab.freedesktop.org/xorg/lib/libxtst/-/blob/master/src/XTest.c) is
int XTestFakeKeyEvent(Display *dpy, unsigned int keycode, Bool is_press, unsigned long delay) {...
What is the size of Bool? I found this in XLib.h (
https://code.woboq.org/gtk/include/X11/Xlib.h.html)
My very limited understanding of C/C++ is that
int is not a fixed size, but depends on the implementation. However
int and
unsigned int are usually the same size. Since the
keycode type in the Pascal declaration is
dword (32 bits), would it not make sense to declare
is_press as a 32 bit boolean also?
My head hurts, all this is very much above my pay scale.
I'll reference dbannon's previous message in the bug report, for the very reason quoted above.
By the way, did anyone else notice the memory leaks?
Recent
