Missing mouse pointer in 'untrusted' - but mouse works

Hi. New to Qubes and VMs, not to linux. Running 4.1.1 on thinkPad t480. Wobbly installation, a few things working soso, let’s start w the mystery of the missing mouse pointer.

Running a logitech wireless over unify, connect USB to appVM (untrusted). The mouse works, scroll direction can be changed through System Tools > Mouse and Touchpad, the mouse pointer hotspot is there and can click on things but there is no graphical representation. As soon as the touchpad is used the hotspot moves there and everything is hunky dory.

Is there somewhere in the fedora template I can connect a graphical representation of a mouse pointer to the actual hotspot?


Now I have dug a little more into it finding non-Qubes specific solutions by tweaking /etc/X11/xorg.conf
TL:DR It is still not solved - help anyone?

There were two approaches
1 - Under the Section “Device”, right before EndSection
1.1 - add the Option “SWCursor” “true”
1.2 - add the Option “HWCursor” “off”
2 - Under the Section "Display, right before EndSection
2.1 - add the Option “HWCursor” “off”
2.2 - and just for the heck of it i tried to add the Option “SWCursor” “true”

The options was altered one by one in /etc/X11/xorg-qubes.conf.template in the debian-11 template. I started the template, added the option, saved, checked that it was saved, restarted the template, checked the template that the option was still there, started a debian AppVM, checked the AppVM that the option was there, added the USB mouse (Logitech Anywhere MX 2) to the AppVM, opened https://privacyheroes.io/ in the browser of the AppVM, with the touch pad I moved the (mouse) cursor over a panel to see it was registered, moved away, now tried with the mouse, shut down the AppVM, removed the option from the template, checked that it was saved, shut down the template and started the process over.

On all the 4 alterations the mouse pointer worked but the cursor did not. With the touch pad the pointer and the cursor worked. The behaviour is the same outside of the browser as well.

All together, I have not solved the issue. Will keep digging when there is time for it.

Hi Monki
This is a strange one.
I haven’t some across it before.
I assume you are using standard Xfce?

I would step back a few paces, and try to remove a number of Qubes
elements. It will also speed your trouble shooting.
Try creating a standalone qube based directly on the debian-11 stock
template. (You’ll find the option in the Qube Menu).
Attach the USB controller directly to that new qube if you
This will remove any issues around USB proxying etc.

Remember too that you need to may need to make some changes in dom0, as
that is where the GUI elements are drawn.

I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.

Hi Unman. Thank you for taking of your time.

Yes, I use std xfce. Created debian-11 standalone qube, attached the usb controller. It is the same outcome, the mouse works flawless except for the missing cursor.

I have no experience fidgeting with dom0, tried to do the ‘xorg.conf-trick’ but there was no existing file.

Anyhow, what I now realise might be connected some how is that I get a dialogue when the sys-usb initiates at every startup. It tries to connect the mouse with dom0 and I cancel it of course, every time.

When I check Q-menu > System tools > Mouse and touchpad, it isn’t there, so that’s a good sign (I guess?) What I notice now though is that changing scroll direction in mouse and touchpad -settings for the device “Synaptics yadayada” does not affect the mouse like it did when I wrote the first post. Since then I have unpaired and paired the mouse with help of Solaar in the feeble hope that it might change something.

Any details you need, any ideas you have, just name them and I will try sort it out stat.

Appreciate your effort.

What does that dialogue say?

[Dom0] Operation execution
Do you want to allow the following operation?
Select the target domain an confirm with ‘OK’
Source: sys-usb
Operation: qubes.InputMouse
Target: dom0
Cancel OK

Now, there is no choice for any other target.

NB. Since I tried to ‘re-register’ the mouse w Solaar, this dialogue above popped up. Before that it was instead 6-7 (yes I counted them) similar dialogues except the operation was “qubes.InputKeyboard”, or something very close to that, can’t remember exactly the name of the operation.

EDIT: now I also noted that a notification popped up during startup stating that “qubes.InputKeyboard” was denied

Since you want to use the mouse you should say “Yes” to this dialog.
I’m puzzled as to why the mouse would work at all if you said No to
I’m guessing that the use of unify is presenting as numerous
mouse/keyboard inputs.

To be clear-
Do you have a sys-usb, and the device is attached there?
Is that qube named sys-usb?
Why are you doing this - “connect USB to appVM (untrusted)”

If I connect a wireless (even though encrypted) mouse to dom0 I guess security dives? That is what I gathered so far.

I have a sys-usb, it was created “by the installation process”, i.e. I have not created it manually. The logi dongle is registered there in the drop down from the tray, together with other units like the camera par example(I think, can’t remember exactly at the moment). If I attach the logi dongle to a machine the mouse works. Except lack of cursor.

I am connecting the mouse to the untrusted AppVM in order to not expose dom0 or other more critic VMs to wirelessness and USB so to speak (security reasons) . I don’t mind the keyboard being connected (it works, also logi over same dongle) to a VM where I read the news, surf for best doughnuts in Portland or play point-and-click adventures. With the machine handling for example banking I only use the laptop keyboard and touch pad and that is fine, not many minutes a month. But generic surfing and Monkey Island would benefit from a mouse. (and I am always curious how to get things to work, that’s how I learned most I know about Linux : )

IF the problem is solved by connecting it to dom0 it is done. But if security is compromised that would be suboptimal. Now, I might have missunderstood the “do not attach to dom0, bad for security” and then I have cost my self - and you - lots of time :confused: :slight_smile:

I have been thinking about a clean Qubes install. Rationale being that things happened when I fiddled with Solaar, instead of having to manually deny the keyboard 7 times I now have to deny the mouse, but only one time. This together with the installation being wobbly (see first post) and the screen flickering quite a lot intermittently maybe it would be worth a try. I have the feeling this could all be hard ware related (some components was replaced a couple of months back when a USB C port stopped working with USB 3.0 units, not 2.0!) Then again, when I had Windows installed everything was hunky dory. What do you think?

I think that there’s some confusion here.
If you have a sys-usb, and the USB device is attached there then you
dont need to worry about connecting a mouse to dom0 or to some other
The mouse device will be attached to sys-usb and the mouse movements
will be proxied from sys-usb in to dom0, as that is where the GUI is
controlled. This is automatically set-up for you, if you select the
sys-usb option.
It’s about as secure as it can be.

If you attach the mouse from sys-usb to a specific qube then the mouse
will work there, but not in dom0. This may be what you want but I
doubt it.