debloper / piosk

One-shot set up Raspberry Pi in kiosk mode as a webpage shuffler, with a web interface for management.
Mozilla Public License 2.0
60 stars 5 forks source link

Auto Mouse Hiding Enhancement #23

Open andiohn opened 1 month ago

andiohn commented 1 month ago

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
debloper commented 1 month ago

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

debloper commented 1 month ago

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, :+1: the issue to flag it as important, to help me prioritize this.