Yes
Both
Host
kloak/unknown,now 0:0.2.45-1 amd64 [installed]
VM
kloak/unknown,now 0:0.2.39-1 amd64 [installed,automatic]
1 Like
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.
1 Like
Does kloak now work on QubesOS Whonix? Looks like there has been great development! How can it be enabled?
Happy to do testing
For now probably not. Probably too much to explain. Once there’s a call for testers it will be clearly identifiable as one.
1 Like
Merged from upstream vmonaco.
Uploaded to testers repository.
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.
In a commit shortly before the version you’re running, when multi-device support was added and in it the way keyboards and mice are detected was changed (Merge pull request #38 from vmonaco/dev · Whonix/kloak@d343f5e · GitHub).
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.
2 Likes
Hi. The only relevant device is this one. I guess unfortunately we’ve reached a dead end as per your comment about having one device as being unexplainable :
I: Bus=0011 Vendor=0002 Product=0007 Version=01b1
N: Name="SynPS/2 Synaptics TouchPad"
P: Phys=isa0060/serio1/input0
S: Sysfs=/devices/platform/i8042/serio1/input/input6
U: Uniq=
H: Handlers=mouse0 event5
B: PROP=1
B: EV=b
B: KEY=e520 30000 0 0 0 0
B: ABS=660800011000003
EDIT:
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?
1 Like
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.
1 Like
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.
1 Like
Commented here: Add support for new devices attached after kloak starts by skyzzuu · Pull Request #67 · vmonaco/kloak · GitHub
(I am using the forums as a progress report tool to account for my activities.)
Didn’t work unfortunately
1 Like
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.
This must be reported upstream.
Kloak for Qubes again unfortunately seems stalled.
A test page that I don’t know anything about it other than it was added to the wiki a while ago by unknown.
1 Like