Closed fmagin closed 3 years ago
I think this is a dupe of this issue https://github.com/talonvoice/beta/issues/87
I believe the (0,0) assumption was true on Mac (where eye_mouse.py was created) but not Linux, and eye_mouse.py predates the entire Talon API as well as Talon being cross platform.
As mentioned in beta/87, the problem will go away once the Tracker object is screen aware (almost ready, coming as part of multimonitor tracking).
Unrelated: please don't rely on monkey patching objects in Talon's stdlib, that's likely to break.
You can already screen.rect.pos + screen.rect.size * pt
I think.
I am aware that those patches are highly unstable, this script is currently in no way intended to be productive and stable and every time I update Talon I am fully aware that this will mean investigating if everything still works. I think those hacks predate .pos
and .size
properties on Rect
, and I didn't think of using them for this after they were added. Good idea, thanks for that!
fixed in next beta
I have a monitor configuration like this, where the left monitor is the one with the eye tracker
The position of DP-1 in this case is (0, 840). Control Mouse and the debug overlay are both 840 pixels too high because of some assumption that is violated, potentially that the main screen is supposed to be located at
(0,0)
.With my own plugin and the gaze callback this is not an issue because I translate the relative position in the GazeFrame into the proper coordinates via some helpers:
So far this seems to work without issues and makes writing eye tracking plugins quite comfortable, so adding helpers like this seems generally useful and might allow to easily fix this issue with Control Mouse.
In case this is relevant I am using i3 on Arch Linux (i.e. Xorg)