MouseAndKeyInput on Linux64 --SOLVED-- lazarus / 32-Linux ---------------------------------------------------------------------- esvignolo · 2016-08-16 16:40 Hello, I wanted to know if any of you use the MouseAndKeyInput unit successfully, Linux 64bit (KUbuntu 16.14, but do not think this has something to do). Apparently not the onkeyup event runs. It is easy to replicate, you only need to compile the project in the \lazarus\components\mouseandkeyinput\example directory. This example work fine on Linux32. In the attached picture, you can see how the O key is pressed, and the code simulates the pulse of the H E L O keys, but the O is maintained because it is the last. ---------------------------------------------------------------------- Leledumbo · 2016-08-16 17:43 Doesn't happen on Manjaro 64-bit, kernel 4.7.0, KDE plasma 5.7.2, Lazarus 1.7 svn 52786 LCL Qt interface. ---------------------------------------------------------------------- esvignolo · 2016-08-16 17:56 Thanks @Leledumbo, maybe is the libxtst-dev, i will try changing this. Thanks again. Quote from: Leledumbo on August 16, 2016, 07:43:58 pmDoesn't happen on Manjaro 64-bit, kernel 4.7.0, KDE plasma 5.7.2, Lazarus 1.7 svn 52786 LCL Qt interface. ---------------------------------------------------------------------- bytebites · 2016-08-16 18:05 In file XKeyInput.pas 1.6 version has Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i function XTestFakeKeyEvent(dpy: PDisplay; keycode: dword; is_press: Boolean;  delay: dword): longint; cdecl; external; and trunk has correct definition: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i function XTestFakeKeyEvent(dpy: PDisplay; keycode: dword; is_press: Boolean32;  delay: dword): longint; cdecl; external; ---------------------------------------------------------------------- esvignolo · 2016-08-16 20:58 WOW!!! thanks, now is working!!! Thanks @bytebites! Quote from: bytebites on August 16, 2016, 08:05:38 pmIn file XKeyInput.pas 1.6 version has Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i function XTestFakeKeyEvent(dpy: PDisplay; keycode: dword; is_press: Boolean;  delay: dword): longint; cdecl; external; and trunk has correct definition: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i function XTestFakeKeyEvent(dpy: PDisplay; keycode: dword; is_press: Boolean32;  delay: dword): longint; cdecl; external; ---------------------------------------------------------------------- desliem · 2022-10-21 00:26 Six years on, this problem persists in Lazarus 2.3.0 (rev main-2_3-1602-gdb285860e3). Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i KeyInput.Press(VK_INSERT) generated a constant stream of VK_INSERT key down events. After changing the type of is_pressed to Boolean32, the function worked as expected generating one VK_INSERT key down event followed by a VK_INSERT key up event. The xkeyinput.pas file to edit is in the $(lazarus)/components/mouseandkeyinput/ directory. Thank you very much @bytebites for the solution. ---------------------------------------------------------------------- dsiders · 2022-10-21 00:39 Quote from: desliem on October 21, 2022, 02:26:20 amSix years on, this problem persists in Lazarus 2.3.0 (rev main-2_3-1602-gdb285860e3). Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i KeyInput.Press(VK_INSERT) generated a constant stream of VK_INSERT key down events. After changing the type of is_pressed to Boolean32, the function worked as expected generating one VK_INSERT key down event followed by a VK_INSERT key up event. The xkeyinput.pas file to edit is in the $(lazarus)/components/mouseandkeyinput/ directory. Thank you very much @bytebites for the solution. DId you file a bug report with the souition? ---------------------------------------------------------------------- desliem · 2022-10-21 02:46 @dsiders : Ok...  Here it is: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39964 Hopefully I didn't cause unnecessary work for anyone, bytesbites did say that the solution was in trunk and there was already a bug report that was closed a year ago: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/27819 ---------------------------------------------------------------------- dbannon · 2022-10-21 02:58 Hmm, yes, I am pretty sure its fixed in Main, I went through ALL the examples and fixed many and documented other problems back when I rewrote the Examples system for Lazarus earlier this year. Cannot test right now because I am not using trunk myself now because of the GoTo/Toggle Bookmark problem, I am stuck on Lazarus 2.2.0rc2 But pretty sure its really a case of getting it from Main to Fixes..... Davo ---------------------------------------------------------------------- bytebites · 2022-10-21 06:13 It is still wrong: is_press: Boolean https://gitlab.com/freepascal.org/lazarus/lazarus/- /blob/main/components/mouseandkeyinput/xkeyinput.pas ---------------------------------------------------------------------- dbannon · 2022-10-21 08:29 OK, so I put Lazarus Main back on my groaning hard disk (I have a new one but need to install it).  And running the example mentioned in the first post of this thread indicates, to me, that the issue does not exist in Main. So, back to my Lazarus 2.2.0rc2, it does not exist there either ! desliem - can you demonstrate the problem using the Mouse and key input example ?  Maybe an example programme of your own ? Davo ---------------------------------------------------------------------- desliem · 2022-10-21 18:05 @dbannon: Issue 39964 (https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39964) contains an example program, showkeys. Compiled with Lazarus 2.3.0 (rev main-2_3-1602-gdb285860e3) FPC 3.3.1 x86_64-linux-gtk2 (Trunk installed in June 20, 2022) it illustrates the problem. Cheers ---------------------------------------------------------------------- dbannon · 2022-10-22 04:35 Hmm, couple of points, 1. You have not included the Lazarus Project file in the demo. 2. Original thread was about a problem affecting KeyInput.Press(), that all seems to work fine now. 3. Your problem appears to relate to the normal keyboard auto-repeat. If you press a button down, hold it down, you see a stream of content until you release it. Two events. 4. If you press your KeyInput.Down() button and then, immediately, the KeyInput.UP() button, it behaves as you would expect.  Works with any key.... On the other hand, I am unsure why it appears to repeat a bit faster than I would expect. Maybe my imagination. Anyway, holding keys down generates a stream of content. Davo ---------------------------------------------------------------------- desliem · 2022-10-22 06:41 @dbannon 1. Sorry about that, I have modified the example to make it easier to reply and hopefully this time all needed files are in the archive. 2. As the saying goes, your mileage may vary. On my system,       Linux Mint 20.1 (Linux hp 5.4.0-128-generic #144-Ubuntu SMP Tue Sep 20 11:00:04 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux)       Lazarus 2.3.0 (rev main-2_3-1602-gdb285860e3)       FPC 3.3.1 x86_64-linux-gtk2, KeyInput.Press() does not work properly if is_press is type boolean in function XTestFakeKeyEvent. See the output of the modified example program below when run on my Linux desktop machine. I believe it shows that the problem is that KeyInput.Up() is actually the equivalent to a KeyInput.Down(). Presumably because is_press = (boolean)True (key down) is interpreted as is_press = (boolean32)False (key up). 3. Yes the repetition of the key down event is due to the autorepeat feature. But it should not occur in a KeyInput.Press() (as per your point 4)  and it definitely should not occur in KeyInput.Up(). 4. What you say is right, any keyboard event will stop an autorepeat sequence. If setting the type of is_press to boolean32 solves the problem experienced in some circumstances without causing problems elsewhere, would it no be prudent to do that? Of course, I differ to your judgment if there is a reason to use type boolean. Regards Standard output of showkeys When is_press type is boolean32 $ ./showkeys KeyUp: 13 KeyInput.Press(VK_B) KeyDown: 66 KeyUp: 66 KeyInput.Press(VK_INSERT) KeyDown: 45 KeyUp: 45 KeyInput.Up(VK_INSERT) KeyInput.Down(VK_INSERT) KeyDown: 45 KeyDown: 45 KeyDown: 45 KeyDown: 45 ... KeyDown: 45 KeyDown: 45 KeyDown: 85 KeyUp: 85 When is_press type is boolean $ ./showkeys KeyUp: 13 KeyInput.Press(VK_B) KeyDown: 66 KeyUp: 66 KeyInput.Press(VK_INSERT) KeyDown: 45 KeyDown: 45 KeyDown: 45 KeyDown: 45 ... KeyDown: 45 KeyDown: 85 KeyUp: 85 KeyInput.Up(VK_INSERT) KeyDown: 45 KeyDown: 45 KeyDown: 45 KeyDown: 45 ... KeyDown: 45 KeyDown: 85 KeyUp: 85 KeyInput.Down(VK_INSERT) KeyDown: 45 KeyDown: 45 KeyDown: 45 KeyDown: 45 ... KeyDown: 45 KeyDown: 85 KeyUp: 85 ---------------------------------------------------------------------- dbannon · 2022-10-22 08:20 Hmm, complicated ! Quote from: desliem on October 22, 2022, 08:41:24 am..... See the output of the modified example program below when run on my Linux desktop machine. I believe it shows that the problem is that KeyInput.Up() is actually the equivalent to a KeyInput.Down(). Presumably because is_press = (boolean)True (key down) is interpreted as is_press = (boolean32)False (key up). Hmm, I don't see that on my system. One triggers a stream of events, the other cancels that stream. They are not interchangeable. Quote3. Yes the repetition of the key down event is due to the autorepeat feature. But it should not occur in a KeyInput.Press() (as per your point 4)  and it definitely should not occur in KeyInput.Up(). OK, thats interesting, I do not see it (the event stream) after a KeyInput.Press(), for me, it only happens when I do a KeyInput.DOWN, so not for a KeyInput.UP and not for a KeyInput.PRESS. Note that the original poster of this thread apparently did see the event stream after an ordinary KeyInput.PRESS, the last one in a sequence. That just might be the core difference between what you see and what I see. QuoteIf setting the type of is_press to boolean32 solves the problem experienced in some circumstances without causing problems elsewhere, would it no be prudent to do that? Of course, I differ to your judgment if there is a reason to use type boolean. OK, first, don't differ to my judgment, I have neither the knowledge nor the authority. Just another user like yourself. Just trying to help you refine the bug report so to increase it likelyhood of getting fixed. 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. But that said, I think you may well be right ! I suspect your report should not worry too much about KeyDown  (although perhaps mention KeyUP in passing) the issue of PRESS is far clearer and easy to understand. The fact that it only shows up on some systems is a worry and must be mentioned because an exulted dev could test, not see it and dismiss your report. I'll test on a few more platforms to help clarify that varying mileage issue .....  So, lets drill down on these results, here is what I see if I press the three buttons other than KeyDown(VK_Insert) Code: [Select]------ Press(VK_V) KeyDown: 86, [] Keypress: 118 KeyUp: 86, [] ------- Press(VK_INSERT) KeyDown: 45, [] KeyUp: 45, [] ------- Up(VK_INSERT) (nothing) (results for boolean32 removed) When is_press type is boolean $ ./showkeys KeyUp: 13 KeyInput.Press(VK_B)          -- This is as expected but where is "KeyPress: xx" KeyDown: 66 KeyUp: 66 KeyInput.Press(VK_INSERT)  -- this is an anomaly KeyDown: 45 KeyDown: 45 KeyDown: 45 KeyDown: 45 ... KeyDown: 45 KeyDown: 85 KeyUp: 85 KeyInput.Up(VK_INSERT)          -- this is an anomaly KeyDown: 45 KeyDown: 45 KeyDown: 45 KeyDown: 45 ... KeyDown: 45 KeyDown: 85 KeyUp: 85 KeyInput.Down(VK_INSERT)      -- This is as expected KeyDown: 45 KeyDown: 45 KeyDown: 45 KeyDown: 45 ... KeyDown: 45 KeyDown: 85 KeyUp: 85 ---------------------------------------------------------------------- dbannon · 2022-10-22 09:45 OK, think I know why this issue has not been fixed. I have tested 13 distros from my test suite, only one showed the fault that is plaguing desliem ! I tested  MXLinux193KDE, Linux Mint 20.2, Linux Mint LMDE5, Manjaro21.2, Debian Bullseye Mate, Debian Bullseye KDE, Ubuntu 22.10 Gnome, Ubuntu 22.04 Gnome, Ubuntu 21.04 Gnome, Ubuntu 20.04 Mate, Ubuntu 18.04 and OpenSuse LEAP 15.4 and they all worked flawlessly. I was wondering if the problem relates the where it was built rather than where it was run but noticed that desliem was using a relatively old Linux Mint, so I went for my oldest VM, Ubuntu 16 and that behaved just as desliem described - badly. Wow. Davo ---------------------------------------------------------------------- desliem · 2022-10-22 16:35 Quote from: dbannon on October 22, 2022, 11:45:51 amI 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. Quote from: dbannon on October 22, 2022, 10:20:18 amJust 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 Code: C  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i 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) Code: C  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i #define Bool int 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?