hrvach / deskhop

Fast Desktop Switching Device
GNU General Public License v3.0
5.96k stars 166 forks source link

How deskhops mouse events are different from a usual ones #98

Closed techge closed 3 weeks ago

techge commented 3 weeks ago

At first, I really need to thank you for this wonderful project. It is exactly what I was looking for!

I am using a unusual linux system that does some specific, security related stuff with mouse and keyboard events. Having said that attaching a mouse to the system does work as intended and these things are transparent to the user, but attaching deskhop to it does not work, sadly. The keyboard part works as intended, the mouse is not recognized. Looking at xev, I get only some VisibilityNotifiy events, but not a single MotionNotify event.

So... I was wondering, what is different in deskhop that might stop it from working? I guess it has something to do with the whole "absolute coordinates" thing, but I do not know Xevents enough, to really get it. Can you point to some specifics, so that I can do some research on my own, if necessary?

As I guess you wondered, the kind of abstraction the system is doing is explained here. Maybe that already helps to see the issue.

hrvach commented 3 weeks ago

That's interesting! The issue is probably how the OS processes reports, tl;dr is this - your mouse can be either a "move left by N" or "move to position X,Y". 99% of mice fall into the former category, but sending absolute coordinates is perfectly legit. Silly question, but have you tried it on another system with the same mouse, and using a different mouse on this one?

Try going from the bottom up, start by doing something like usbhid-dump if possible and then check if qubes has some debug output. I'd guess it maybe has no support for this. I'd guess they reimplemented a lot of stuff themselves and it's hard to find the time and resources to implement things that are not used by the majority of users. It's a great project btw!

techge commented 3 weeks ago

Silly question, but have you tried it on another system with the same mouse, and using a different mouse on this one?

Ah, sure, did not mention. I tried on Arch Linux and Windows, both work fine. So the hardware should be working correctly.

Try going from the bottom up, start by doing something like usbhid-dump if possible and then check if qubes has some debug output. I'd guess it maybe has no support for this. I'd guess they reimplemented a lot of stuff themselves and it's hard to find the time and resources to implement things that are not used by the majority of users. It's a great project btw!

Thanks for the insights and the suggestions! With this slightly more knowledge I might be able to ask the qubes team a bit more specific questions. Sometimes, missing features are deliberate security decisions, sometimes it is like you said - just too much of a hassle to implement. I'll find out what it is here and what could be done about it.

Anyway, thanks a lot and yes Qubes OS has it quirks (as seen in this issue :wink: ), but really has some neat features I wouldn't want to miss anymore.

techge commented 3 weeks ago

It is funny, how sometimes immediately after finding out some new infos, you finally find the important bits and pieces. It is not like I haven't looked for clues beforehand, but only now I found this issue in the qubes project.

It seems using absolute coordinates does work within qubes as they implemented it for touchscreen HIDs. So it probably makes sense, if I somehow change the way my deskhop announces itself to the system :thinking: I am just not sure yet if it just is signaled via the interface id of the usb descriptor (hope this is the terminology) or how qubes identifies the device. I could already verify that qubes indeed does not interpret the deskhop as touchscreen yet.

I leave this info here, because maybe you already have an idea how to fix this, but I will also ask over at qubes.

techge commented 3 weeks ago

Okay, I got deskhub working, if I tell qubes to work with every mouse in a similar fashion as it would do with tablet/touchscreen devices.

Not allowing absolute mouse coordinate for a standard mouse is a security consideration in qubes. You need to explicitly allow this kind of hid devices there. Consequently, qubes is waiting for a different hid descriptor and does not activate/allow absolute coordinates for the deskhop (I circumvented that with a workaround).

That got me thinking... would it be possible to add another descriptor to deskhop to let devices consider it as a keyboard, mouse and (now added) a tablet device? I think this should have no side effects on other systems, but would help with qubes.

Where would could I add this in the code, if I would like to do it in my own build of the firmware?

techge commented 3 weeks ago

I use a udev rule now. So there is no need for code change. I still think it would not hurt, but seldom anyone will need it so...