[GH-ISSUE #23] Auto Mouse Hiding Enhancement #24

Open
opened 2026-03-03 11:13:26 +03:00 by kerem · 10 comments
Owner

Originally created by @andiohn on GitHub (Jul 22, 2024).
Original GitHub issue: https://github.com/debloper/xiosk/issues/23

Seems like this would be a good option here:

https://raspberrypi.stackexchange.com/questions/145382/remove-hide-mouse-cursor-when-idle-on-rasbperry-pi-os-bookworm/145390#145390

2

I've had success with installing the hideaway plugin for Interception Tools using the script below.

Adapted from https://forums.raspberrypi.com/viewtopic.php?t=358285#p2176499

#!/bin/bash
# hide mouse in wayland raspbian

sudo apt install -y interception-tools interception-tools-compat
sudo apt install -y cmake
cd ~
git clone https://gitlab.com/interception/linux/plugins/hideaway.git
cd hideaway
cmake -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build
sudo cp /home/$USER/hideaway/build/hideaway /usr/bin
sudo chmod +x /usr/bin/hideaway

cd ~
wget https://raw.githubusercontent.com/ugotapi/wayland-pagepi/main/config.yaml
sudo cp /home/$USER/config.yaml /etc/interception/udevmon.d/config.yaml
sudo systemctl restart udevmon
Originally created by @andiohn on GitHub (Jul 22, 2024). Original GitHub issue: https://github.com/debloper/xiosk/issues/23 Seems like this would be a good option here: https://raspberrypi.stackexchange.com/questions/145382/remove-hide-mouse-cursor-when-idle-on-rasbperry-pi-os-bookworm/145390#145390 2 I've had success with installing the [hideaway](https://gitlab.com/interception/linux/plugins/hideaway) plugin for [Interception Tools](https://gitlab.com/interception/linux/tools) using the script below. Adapted from https://forums.raspberrypi.com/viewtopic.php?t=358285#p2176499 ```bash #!/bin/bash # hide mouse in wayland raspbian sudo apt install -y interception-tools interception-tools-compat sudo apt install -y cmake cd ~ git clone https://gitlab.com/interception/linux/plugins/hideaway.git cd hideaway cmake -B build -DCMAKE_BUILD_TYPE=Release cmake --build build sudo cp /home/$USER/hideaway/build/hideaway /usr/bin sudo chmod +x /usr/bin/hideaway cd ~ wget https://raw.githubusercontent.com/ugotapi/wayland-pagepi/main/config.yaml sudo cp /home/$USER/config.yaml /etc/interception/udevmon.d/config.yaml sudo systemctl restart udevmon ```
Author
Owner

@debloper commented on GitHub (Jul 23, 2024):

Thank you... let's make it part of 3.0 release!

<!-- gh-comment-id:2244046590 --> @debloper commented on GitHub (Jul 23, 2024): Thank you... let's make it part of 3.0 release!
Author
Owner

@debloper commented on GitHub (Jul 29, 2024):

On a second thought, going to postpone this feature to round back at later.

None of the existing solutions are up to the mark in terms of quality of implementation. They have all sorts of issues - from dependencies to distributions & everything in-between. They do not follow the "do one thing, and one thing well" methodology & hence suffer from the feature overloading problem. Half of them are also tied to specific display server or compositor, even though this can be done by directly talking to the Kernel.

The one that comes closest is ydotool, but aptitude installs an older broken version v0.1.8, and the new versions (v1.0.x) don't have ARM release. So, we'll have to build/distribute it ourselves, and potentially risk becoming a (supply chain exploit vector), which is on the rise recently. So I am not walking into that.

If I really have to build C code anyway, I'd rather write a better/leaner implementation.

All that's needed is to send input_event to kernel to proper device/stream... something like:

// NOTE: IT'S NOT VALIDATED & SHOUDN'T WORK
// THIS IS JUST A REFERENCE, NOT AN EXAMPLE
// I NEED TO FIND THE DEVICE TO fwrite() TO

#include <linux/input.h>

void main (int argc, char *argv[]) {
    struct input_event ie;

    ie.type = EV_REL;
    ie.code = REL_X;
    ie.value = 1000;

    fwrite(&ie, sizeof ie, 1, THE_INPUT_DEVICE_TO_HANDLE_THIS);
    // you can include stdio.h & use `stdout` to fwrite to
    // that should allow you to compile & run it
    // and spit event bytecode in terminal... xP

    return;
}

But we'll come back to it at a later point. Meanwhile, 👍 the issue to flag it as important, to help me prioritize this.

<!-- gh-comment-id:2256618388 --> @debloper commented on GitHub (Jul 29, 2024): On a second thought, going to postpone this feature to round back at later. None of the existing solutions are up to the mark in terms of quality of implementation. They have all sorts of issues - from dependencies to distributions & everything in-between. They do not follow the "do one thing, and one thing well" methodology & hence suffer from the feature overloading problem. Half of them are also tied to specific display server or compositor, even though this can be done by directly talking to the Kernel. The one that comes closest is `ydotool`, but aptitude installs an older broken version v0.1.8, and the new versions (v1.0.x) don't have ARM release. So, we'll have to build/distribute it ourselves, and potentially risk becoming a ([supply chain exploit vector](https://nvd.nist.gov/vuln/detail/CVE-2024-3094)), which is on the rise recently. So I am not walking into that. If I really _have to_ build C code anyway, I'd rather write a better/leaner implementation. All that's needed is to send `input_event` to kernel to proper device/stream... something like: ```c // NOTE: IT'S NOT VALIDATED & SHOUDN'T WORK // THIS IS JUST A REFERENCE, NOT AN EXAMPLE // I NEED TO FIND THE DEVICE TO fwrite() TO #include <linux/input.h> void main (int argc, char *argv[]) { struct input_event ie; ie.type = EV_REL; ie.code = REL_X; ie.value = 1000; fwrite(&ie, sizeof ie, 1, THE_INPUT_DEVICE_TO_HANDLE_THIS); // you can include stdio.h & use `stdout` to fwrite to // that should allow you to compile & run it // and spit event bytecode in terminal... xP return; } ``` But we'll come back to it at a later point. Meanwhile, :+1: the issue to flag it as important, to help me prioritize this.
Author
Owner

@andiohn commented on GitHub (Oct 3, 2024):

I wonder if all it had to do was to send the mouse into the bottom right or something after 10 minutes of boot up. Do that once. Easy, effective :)

<!-- gh-comment-id:2392065235 --> @andiohn commented on GitHub (Oct 3, 2024): I wonder if all it had to do was to send the mouse into the bottom right or something after 10 minutes of boot up. Do that once. Easy, effective :)
Author
Owner

@andiohn commented on GitHub (Oct 3, 2024):

Holy crap, I might have found a solution:
https://gabrielstaples.com/ydotool-tutorial/#gsc.tab=0

ydotool

<!-- gh-comment-id:2392081517 --> @andiohn commented on GitHub (Oct 3, 2024): Holy crap, I might have found a solution: https://gabrielstaples.com/ydotool-tutorial/#gsc.tab=0 ydotool
Author
Owner

@andiohn commented on GitHub (Oct 3, 2024):

"ydotool mousemove -x 0 -y 0" should put it to the top left. Might be good enough...

<!-- gh-comment-id:2392083195 --> @andiohn commented on GitHub (Oct 3, 2024): "ydotool mousemove -x 0 -y 0" should put it to the top left. Might be good enough...
Author
Owner

@andiohn commented on GitHub (Oct 3, 2024):

https://askubuntu.com/questions/956640/equivalent-to-xdotool-for-wayland

wtype and evemu might be better even. No need to reinvent the wheel, just move the mouse. :)

<!-- gh-comment-id:2392085392 --> @andiohn commented on GitHub (Oct 3, 2024): https://askubuntu.com/questions/956640/equivalent-to-xdotool-for-wayland wtype and evemu might be better even. No need to reinvent the wheel, just move the mouse. :)
Author
Owner

@debloper commented on GitHub (Oct 7, 2024):

As mentioned before, the problem here is:

The one that comes closest is ydotool, but aptitude installs an older broken version v0.1.8, and the new versions (v1.0.x) don't have ARM release. So, we'll have to build/distribute it ourselves, and potentially risk becoming a (supply chain exploit vector), which is on the rise recently. So I am not walking into that.

Which means, I don't wanna take responsibility for building and distributing binary of a third party solution... but, you (and anyone else needing this feature) can totally use it for themselves.

If you can please write down the method you've followed to make it work for yourself, then I can mark that as the solution and close this issue for now.

<!-- gh-comment-id:2397590442 --> @debloper commented on GitHub (Oct 7, 2024): As mentioned before, the problem here is: > The one that comes closest is ydotool, but aptitude installs an older broken version v0.1.8, and the new versions (v1.0.x) don't have ARM release. So, we'll have to build/distribute it ourselves, and potentially risk becoming a ([supply chain exploit vector](https://nvd.nist.gov/vuln/detail/CVE-2024-3094)), which is on the rise recently. So I am not walking into that. Which means, I don't wanna take responsibility for building and distributing binary of a third party solution... but, you (and anyone else needing this feature) can totally use it for themselves. If you can please write down the method you've followed to make it work for yourself, then I can mark that as the solution and close this issue for now.
Author
Owner

@andiohn commented on GitHub (Oct 10, 2024):

Ya, good point. I used the solution from the first one. I just found that "Wayfire extra plugins" has a hide cursor plugin, perhaps that would be a good starting point.

<!-- gh-comment-id:2405434455 --> @andiohn commented on GitHub (Oct 10, 2024): Ya, good point. I used the solution from the first one. I just found that "Wayfire extra plugins" has a hide cursor plugin, perhaps that would be a good starting point.
Author
Owner

@tismofied commented on GitHub (Nov 28, 2024):

I did it this way.
1- sudo apt update && sudo apt full-upgrade -y

2- sudo apt install ydotool

3- nano cursor_hide.sh

sleep 8
sudo ydotool mousemove --delay 1000 10000 10000

4- sudo chmod +x cursor_hide.sh

5- sudo reboot

<!-- gh-comment-id:2506702449 --> @tismofied commented on GitHub (Nov 28, 2024): I did it this way. 1- `sudo apt update && sudo apt full-upgrade -y` 2- `sudo apt install ydotool` 3- `nano cursor_hide.sh` ``` sleep 8 sudo ydotool mousemove --delay 1000 10000 10000 ``` 4- `sudo chmod +x cursor_hide.sh` 5- `sudo reboot`
Author
Owner

@debloper commented on GitHub (Jul 21, 2025):

Let's contribute to ydotool upstream to add ARM builds to the build strategy matrix, which we can then download and use from the releases. If not, I'll fork and maintain it for this base purpose (not ideal, but best of bad options).

Once we have that blocker cleared, this would be a dashboard global configuration flag; so users can enable/disable it (hide pointers by default upon installation); because not all users may want this feature.

<!-- gh-comment-id:3098974902 --> @debloper commented on GitHub (Jul 21, 2025): Let's contribute to `ydotool` upstream to [add ARM builds](https://github.com/ReimuNotMoe/ydotool/blob/master/.github/workflows/push_pr_build_cmake.yml) to the build strategy matrix, which we can then download and use from the releases. If not, I'll fork and maintain it for this base purpose (not ideal, but best of bad options). Once we have that blocker cleared, this would be a dashboard global configuration flag; so users can enable/disable it (hide pointers by default upon installation); because not all users may want this feature.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/xiosk#24
No description provided.