MouseAndKeyInput on Linux64 --SOLVED--

[esvignolo]

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]

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]

Thanks @Leledumbo, maybe is the libxtst-dev, i will try changing this.

Thanks again.

 

Doesn't happen on Manjaro 64-bit, kernel 4.7.0, KDE plasma 5.7.2, Lazarus 1.7 svn 52786 LCL Qt interface.

[bytebites]

In file XKeyInput.pas 1.6 version has

Code: Pascal  [Select][+][-]

1. function XTestFakeKeyEvent(dpy: PDisplay; keycode: dword; is_press: Boolean;
2.   delay: dword): longint; cdecl; external;

and trunk has correct definition:

Code: Pascal  [Select][+][-]

1. function XTestFakeKeyEvent(dpy: PDisplay; keycode: dword; is_press: Boolean32;
2.   delay: dword): longint; cdecl; external;

[esvignolo]

WOW!!! thanks, now is working!!!

Thanks @bytebites!

In file XKeyInput.pas 1.6 version has

Code: Pascal  [Select][+][-]

1. function XTestFakeKeyEvent(dpy: PDisplay; keycode: dword; is_press: Boolean;
2.   delay: dword): longint; cdecl; external;

and trunk has correct definition:

Code: Pascal  [Select][+][-]

1. function XTestFakeKeyEvent(dpy: PDisplay; keycode: dword; is_press: Boolean32;
2.   delay: dword): longint; cdecl; external;

[desliem]

Six years on, this problem persists in Lazarus 2.3.0 (rev main-2_3-1602-gdb285860e3).

Code: Pascal  [Select][+][-]

1. 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]

Six years on, this problem persists in Lazarus 2.3.0 (rev main-2_3-1602-gdb285860e3).

Code: Pascal  [Select][+][-]

1. 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]

@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]

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]

It is still wrong: is_press: Boolean
https://gitlab.com/freepascal.org/lazarus/lazarus/-/blob/main/components/mouseandkeyinput/xkeyinput.pas

[dbannon]

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]

@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]

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]

@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]

Hmm, complicated !

.....
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.

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().

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.

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.

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