Does it break tap-to-click only when running it in the host OS, or does it also break it when running in the whonix workstation VM?
Also, do you have kloak running in both the host OS as well as the whonix workstation VM, or only the host OS?
Would you mind running apt list --installed kloak in both the host OS as well as the whonix workstation VM to find the current versions you have and sending that as well please?
I don’t notice anything unusual yet in the logs, all of the events seem to be getting released and in the same order they were buffered. The order of events in the logs also seems to match what I get when running kloak in my host OS.
Upgraded kloak on the VM to the same (latest) version as the host and tap o clock works normally when it is disabled on the host. This isn’t meaningful though since input events are emulated and injected into VMs so it is only broken when interacting with physical hardware for some reason.
Sorry for the late reply. This is a tough one, but I have a theory on what broke the tap emulation. I tested out kloak on 2 different laptops in 2 different host OSs (fedora and debian) and although I wasn’t able to reproduce it, I noticed they both had 2 different devices detected for the touchpad, and in your logs there’s only 1.
I’m not entirely sure why it would cause an issue, but I’m wondering if you have 2 different device files for your touchpad and when 1 is grabbed by kloak and the other isn’t, it’s causing issues.
Specifically on my device, there’s one with the name vendor info Touchpad and one with the name vendor info Mouse.
Would you mind running cat /proc/bus/input/devices when you have an opportunity and sending the output?
If your device does actually only have 1 device file for the touchpad, then I’m at a loss and not sure what the issue is, as no events appear to be lost based on the logs and they appear to be getting released in the same order they are buffered.
EDIT: Also, if you don’t want to send information for all of the entries in /proc/bus/input/devices , I really only need information from the touchpad and mouse devices, so you can trim the output if you don’t want to send all of it.
On second thought when examining the log above, I see
Reading from : /dev/input/event0 /dev/input/event5
where the first symbolizes the keyboard and the second the touchpad, however there is a second handler of mouse0 for the second device that is never referenced. Is there anyway to hardcode for it so it can capture and the mouse feature separately?
Also note that touchpad tapping settings have a certain threshold in ms to detect such events (at least on KDE) perhaps the delays overrun this?
That’s a really good point about the delay between events, that might be it. When you press down and hold down the left mouse button on a touchpad, it still sends a left click regardless of how long you hold it down for, but if you do a tap-and-hold, it won’t send a click anymore because it thinks you may be moving the cursor as opposed to sending a click.
You can test if this is causing the issue by adding the -d 0 option to kloak to completely turn off the delay. If that option fixes it, then that’s definitely the issue.
If that does fix it, I could add in an option with a name like --taptoclick that turns off the delay on events with the BTN_TOUCH or BTN_TOOL_FINGER event codes, while still adding delay to other events.
Regarding the mouse0 handler, kloak can’t read from those. I think those device files send events in a different format than the event[0-9] files.
Those look like very good additions. Also, we modified different sections of main.c, so there’s very unlikely to be a merge conflict between our PRs.
One thing to note with my PR, to get the functionality of new devices being picked up, the previous kloak.service file will need to be deleted when the deb file is installed. I’m not very familiar with creating deb packages, so I’m not sure if it will automatically add that in there since the previous kloak.service was deleted.
If it’s not deleted, it doesn’t cause any issues, but the previous kloak service will grab the devices and cause the services started by udev to fail. Input events will still go through normally and have delay added by the previous kloak service, but new devices won’t be covered.
I would like to mention that the option to invert touchpad scroll direction (natural scrolling) does not work when kloak is running. If this is something that can be worked around that would be nice in my opinion.