Pointer lock API
Nagaev Boris
I noticed that Quake3 almost works in Qubes 3.2, but has one annoying
issue: the pointer is unmanageable. It looks like the pointer has the
"memory" about its previous position: e.g. when I move it left, the
game continues moving right. I tried `openarena` tool from the Debian
template and also web version of Quake on http://www.quakejs.com/ both
have the same issue. Performance of both native and web versions is
amazing, the only problem is the mouse.
I think it works incorrectly because it tries to lock the pointer
(probably to move it to the screen center) but Qubes doesn't allow
AppVMs to manage pointer. X11 has function `XWarpPointer` that moves
the pointer. Probably the game uses this function, though I don't know
how to check this.
Can Qubes add Pointer lock support for AppVM, please?
--
Best regards,
Boris Nagaev
Alex
type. Did you try starting the VM with a different mouse input type? The
default seems to be Mouse, while Tablet may solve your problems, like it
did (even if not 100% because of inbuilt android pointer acceleration)
for my Android appVM.
The mouse input type setting cannot be configured via standard Qubes
tools, either the qubes.xml or the manager. You can try by creating a
copy of "appvmname.conf" with a name different from the original (or
Qubes will overwrite it) that you can find in dom0 at
/var/lib/qubes/appvms/appvmname/appvmname.conf.
In the copy find the "devices" element and add "<input type='tablet'
bus='usb' />" - this will override the default mouse input. Start the VM
with this conf instead of the default one with qvm-start and check.
It would be a great security concern to let single appVMs manage the
pointer, even if in good faith (misclicks can produce disasters) and
without mentioning the big development problem. The mouse "resource"
will have to be "shared" among potentially several
mouse-management-enabled appvms: who shall win if two appvms decide to
lock the mouse in two separate rectangles?
--
Alex
Leo Gaspard
In addition to using the tablet input mode, as Alex advises, you may
have luck plugging in a USB mouse and passing it through to the VM (if
you run in non-seamless mode).
HTH,
Leo
yura...@gmail.com
Sounds to me like a good suggestion, and it will more depend on the guest-OS whether it supports USB-mouse, making Qubes support irrelevant.
Having said that, it would be amazing to sometime in the near future have touch-screen support for Qubes and AppVM's.
If non-touch screens don't disappear with Virtual/Augmented reality spreading like wildfire in the coming years, then traditional mouse most certainly is going to go away eventually.
With all these new hand movement, brain-wave thought control of software, gyroscope finger sensor ring and control. It's hard to see it being a good idea not to focus development on these new technologies, which might come to market very fast, once the big mobile/laptop developers decide to unleash it.
At which point, we'll be sourly left behind this revolution, which has the potential to make software use considerably more convenient, fast and smooth.
It's a bit of a problem, few programmers seem to take anything else but keyboard/mouse seriously. Though of course, its hard to program for something that hasn't reached mainstream yet, or at best only prototypes or exotic commercial releases in the wild.
But considering how long it takes to make touch-screen work properly in the Linux community, I do fear for the future once new input methods become mainstream.
I love the Linux community. But if there is anything I dislike, it's the conservative, reactive, kind of thinking that takes president. There are so few visionaries, proactive, kind of thinkers around in the Linux community in general. Though to be fair, Qubes is quite revolutionary and visionary, but I'm not talking about Qubes, but rather the desktop environments and their lack of proper working input support.
It hardly makes sense for Qubes to implement it, if the desktop environments don't support it properly to begin with. In a sense, it makes sense Qubes developers don't work on something, which is outside their scope. The problem here, is those who are supposed to be responsible for it, the desktop environment developers, especially the conservative ones who dislike change and don't care about users who have different needs than their own.
Those are the problem, in my opinion. Albeit can't complain if I don't donate to them, but I don't want to donate unless they do a good job either, to which many desktop developers most certainly don't. It's a bad never ending circle.
Vít Šesták
There is an exiting input proxy mechanism. It was originally intended for sys-usb->dom0, but other combinations can work, too.
As far as I remember, it does not work with the standard X11 instance in AppVM. Instead, I had to run a VNC loopback session. This also required the service file in target VM to set DISPLAY environment variable.
If someone is interested, I can look for details. Maybe I have something already posted here.