Replies: 2 comments 3 replies
-
|
Hi! Thanks for asking! Yes, I am currently working on and off on bringing a new Linux backend for SharpHook (and my libuiohook fork in the process). I don't really want to take the evdev branch from the original libuiohook repo because I'm currently actively looking into What I have right now is just some vague ideas about how to implement this. If you don't mind, I will start a new discussion once I have some more concrete steps towards implementing this support. Also, as a note, I have little experience with C and low-level programming (though I definitely know the basics), so this change will take quite some time for me to implement. But, as a user of SharpHook myself, I have interest in having Wayland support in it, so this is definitely something that I really want to do. |
Beta Was this translation helpful? Give feedback.
-
Glad to hear it!
I'm guessing the second "libuiohook" was meant to be something else? But if you manage to find a less invasive way than grabbing devices with evdev, please let me know :)
👍 |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I meant libinput, not libuiohook 😄 I'm also thinking about not implementing event blocking due to its complexity. I've read your answer in the Wayland thread in the libuiohook issue, but I think it would be too difficult for me to implement. Nevertheless, having a working solution for Wayland, even if it cannot block events, is better than having no solution at all. |
Beta Was this translation helpful? Give feedback.
-
|
If evdev+uinput is used then blocking vs listening shouldn't be too different difficulty-wise. In both cases the app needs to be in the input group (so a daemon would likely be necessary, or all apps using SharpHook would need to be ran as root at least once), device enumeration logic is the same, event reading logic is the same, input synthesizing with uinput looks the same. The difference would be the device grabbing part (not difficult), captured input resynthesizing (not sure how difficult this is), and maybe the event handler calling logic if we want to avoid totally blocking up the system with a rogue event handler. |
Beta Was this translation helpful? Give feedback.
-
|
If libinput is used, then there is no need to think in terms of devices at all, they are all abstracted away by libinput and we just handle input events, no matter where they came from - that's basically the main point of libinput. In terms of access, yes, it's basically the same, but I will not implement a shared daemon since it's much more complex, and a library should not make this decision - it must be up to application developers that use this library. The device grabbing part makes a huge difference in terms of complexity and responsibility to implement everything correctly so as not to brick users' systems. Bear in mind that my current level of Linux knowledge is limited, and I simply don't want to dedicate loads of my time to investigate how to make all this work correctly, and I definitely don't want to take this responsibility upon myself, so that's why I don't want to implement it this way. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello,
I'm wondering whether you've considered merging libuiohook evdev branch into your fork and continuing the work on evdev/uinput? I'm asking mostly because I've run into the limitations of the current Linux implementation (or more generally, X11 userland limitations): not being able to block input, and not being able to detect simulated input. A timing-based approach to differentiate simulated input from physical ones cannot be 100% accurate, and trying to block keys conditionally with XGrabKey is riddled with timing issues. And of course an added benefit of using evdev+uinput would be Wayland support...
Beta Was this translation helpful? Give feedback.
All reactions