Problem with Keypress simulation on Linux (Ubuntu 18)

Question

I'm making a hobby project that is basically a bot for a very old flash game, the mouse move and click works fine, but all key presses make the operating system lag/stutter and sometimes stop listening to all keyboard inputs, real or fake.

I started using just XLib with XTests but didn't work, so I tried XSendEvent instead of XTests, but all symptoms stayed the same, so the last attempt was with XDO, which gave better results, but still freezes the OS.

this is the current snippet that I'm trying to use to simulate a keypress:

//Constructor
CheatCore::CheatCore() {
    xdo_t x = xdo_new(NULL);

    Window *list;
    xdo_search_t search;
    unsigned int nwindows;
    memset(&search, 0, sizeof(xdo_search_t));
    search.max_depth = -1;
    search.require = xdo_search::SEARCH_ANY;
    search.searchmask = SEARCH_CLASS | SEARCH_ONLYVISIBLE;
    search.winclass = "Chrome";

    int id = xdo_search_windows(x, &search, &list, &nwindows);
    qDebug() << nwindows;
    if(!nwindows){
        qDebug() << "Chrome not found";
        return;
    }

    w = list[0];

    //I have to call activate twice to really bring it forward, I suspect that its
    //because I use a transparent "overlay" that show stats for the cheat and it is set as Aways on top
    //(i used Qt to set it to not get any Events)

    xdo_activate_window(x,w);
    xdo_activate_window(x,w);

}

//there is a function that executes every second to check if a pixel color has changed,
//if so, then the SendKey is called to Reload weapon magazine pressing the "space" key
void CheatCore::SendKey(){

    xdo_activate_window(x,w);
    xdo_activate_window(x,w);
    xdo_send_keysequence_window(x, w, "space", 500);

}

I'm using a transparent overlay to show the bot status, with just some numbers appearing, it is a widget created using Qt that is AlwaysOnTop and the paint event draws the desired information's, it is another object and don't have direct impact in the CheatCore, but this is the window flags used to draw over a transparent window and ignore events.

setWindowFlags(Qt::WindowTransparentForInput | Qt::FramelessWindowHint | 
Qt::WindowStaysOnTopHint);
setAttribute(Qt::WA_NoSystemBackground);
setAttribute(Qt::WA_TranslucentBackground);
setAttribute(Qt::WA_TransparentForMouseEvents);

I didn't manage to understand what could be provoking this weird behavior, could it be the windowing system?

Also, I tried to find a Qt way of simulating mouse/keyboard inputs, but i didn't manage to find any solution to send events to other windows if there is a way possible of achieving this would be great!

The game i'm trying to automate is called "Storm the House"

If interested this is the link to the online repo : link

Can you help me make this work? Thank you!

Context about the setup: Ubuntu 18.10 using VGA and Nvidia drivers (if it may influence the xserver)

any alternatives do XLib and XDo for mouse and keyboard inputs are welcome — Ollegn, Mar 11 '19 at 17:53
I tested this is different OSes and i noticed that this only happens with GNOME interfaces, does GNOME have some kind of incompatibility with event simulation with x11? — Ollegn, Mar 19 '19 at 18:26

score 0 · Answer 1 · answered Mar 11 '19 at 19:06

0

Did you ever try to use xdotool from command line. To use xdotool you need to install package first. To simualte a key press, you can use.

xdotool key <key>

For example if you want to simulate key press for X you can use this code

xdotool key x

Or any other combination like

xdotool key ctrl+f

Also you can replace key press with another one, for example if you want to replace pressing D with Backspace you can try this one

xdotool key D BackSpace

You can read complete guid online, also you can write script with this tool and use it in many different situations. Also you can use it for remote connection too.

I hope this helps you with your little problem.

answered Mar 11 '19 at 19:06

TAO

180
1
1
11

1

Yes, it lags a bit before actually sending the keypress, though the focus of the question is totally different than xdotool, It's about sending keypresses programmatically without the need of console commands, the tag xdotool was inserted due to the xdo.h which is the basis of xdotool – Ollegn Mar 12 '19 at 14:22
I Used this tool to test in different OSes how key simulation lags, i found that it happens only on GNOME interfaces, but this solution does not fix the problem – Ollegn Mar 19 '19 at 18:27
How is this answer `c++` related? – Deanie Aug 08 '22 at 16:54

score -1 · Answer 2 · answered Mar 17 '19 at 07:29

-1

Using evdev is a linux specific option.

It's a simpler solution as you just need to open the correct file and write to it.

Take a look at this similar question to see how to get started.

answered Mar 17 '19 at 07:29

TinfoilPancakes

238
1
13

This is kinda of a hack and probably hard to maintain. Is there a way of manipulating this using some lib different from xlib? – Ollegn Mar 19 '19 at 18:29
1

After some digging I found `uinput` kernel module that allows for a nicer interface: https://www.kernel.org/doc/html/v4.16/input/uinput.html – TinfoilPancakes Mar 24 '19 at 05:18

Problem with Keypress simulation on Linux (Ubuntu 18)

2 Answers2