Return to Level1Techs.com

Mouse goes crazy in 1080p Looking Glass – anything I can do about it?

Software & Operating Systems Looking Glass
, ,
#1

Hello guys!

This might be a known bug or related to the bug (https://github.com/gnif/LookingGlass/issues/27) or similar but I am not sure if this exact behaviour has been reported yet.

Waiting for a Dummy HDMI Plug I now hooked up a 1080p monitor.
As soon as I boot the VM with it I get a completely unusable mouse (the mouse just feaks out all over the place).

I believe I removed the Tablet that people refered to with similar issues but I can’t be sure. The virtual PS/2 mouse in virt-manager can not be removed apparently.

What am I doing wrong?

Greetings,

goldsteal

#2

Please show the console output of the LG client.

#3

Do I need to run LG with a verbose or something? My console / Terminal only says the following so far:

looking-glass-client

37016799126 [I]               main.c:1675 | main                           | Looking Glass (B2-rc4-10-g7d2b39058c+1)
     37016799150 [I]               main.c:1676 | main                           | Locking Method: Atomic
     37016877157 [I]            ivshmem.c:180  | ivshmemOpenDev                 | KVMFR Device     : /dev/shm/looking-glass
     37016985268 [I]                egl.c:188  | egl_initialize                 | Double buffering is off
     37017009233 [I]                egl.c:202  | egl_initialize                 | Multisampling enabled, max samples: 4
     37017009251 [I]               main.c:1101 | try_renderer                   | Using Renderer: EGL
     37017105423 [I]               main.c:1428 | lg_run                         | Using Clipboard: X11
     37017115251 [I]                egl.c:405  | egl_render_startup             | Supported extensions: EGL_EXT_platform_base EGL_EXT_device_base EGL_EXT_device_enumeration EGL_EXT_device_query EGL_KHR_client_get_all_proc_addresses EGL_EXT_client_extensions EGL_KHR_debug EGL_KHR_platform_x11 EGL_EXT_platform_x11 EGL_EXT_platform_device EGL_KHR_platform_wayland EGL_EXT_platform_wayland EGL_MESA_platform_gbm EGL_KHR_platform_gbm EGL_MESA_platform_surfaceless
     37017115275 [I]                egl.c:411  | egl_render_startup             | use native: false
     37017125000 [I]                egl.c:500  | egl_render_startup             | Vendor  : AMD
     37017125021 [I]                egl.c:501  | egl_render_startup             | Renderer: AMD Radeon (TM) R9 380 Series (TONGA, DRM 3.39.0, 5.9.0-050900rc8-generic, LLVM 10.0.1)
     37017125030 [I]                egl.c:502  | egl_render_startup             | Version : OpenGL ES 3.2 Mesa 20.3.0-devel (git-2b977ad 2020-10-06 focal-oibaf-ppa)
     37017339356 [I]               main.c:1559 | lg_run                         | Host ready, reported version: B2-rc4-11-g8692e9af80
     37017339372 [I]               main.c:1560 | lg_run                         | Starting session

And this with Fullscreen (-F)

looking-glass-client -F

37280905161 [I]               main.c:1675 | main                           | Looking Glass (B2-rc4-10-g7d2b39058c+1)
     37280905180 [I]               main.c:1676 | main                           | Locking Method: Atomic
     37280981961 [I]            ivshmem.c:180  | ivshmemOpenDev                 | KVMFR Device     : /dev/shm/looking-glass
     37281034163 [I]                egl.c:188  | egl_initialize                 | Double buffering is off
     37281058561 [I]                egl.c:202  | egl_initialize                 | Multisampling enabled, max samples: 4
     37281058573 [I]               main.c:1101 | try_renderer                   | Using Renderer: EGL
     37281165872 [I]               main.c:1428 | lg_run                         | Using Clipboard: X11
     37281174999 [I]                egl.c:405  | egl_render_startup             | Supported extensions: EGL_EXT_platform_base EGL_EXT_device_base EGL_EXT_device_enumeration EGL_EXT_device_query EGL_KHR_client_get_all_proc_addresses EGL_EXT_client_extensions EGL_KHR_debug EGL_KHR_platform_x11 EGL_EXT_platform_x11 EGL_EXT_platform_device EGL_KHR_platform_wayland EGL_EXT_platform_wayland EGL_MESA_platform_gbm EGL_KHR_platform_gbm EGL_MESA_platform_surfaceless
     37281175024 [I]                egl.c:411  | egl_render_startup             | use native: false
     37281187226 [I]                egl.c:500  | egl_render_startup             | Vendor  : AMD
     37281187236 [I]                egl.c:501  | egl_render_startup             | Renderer: AMD Radeon (TM) R9 380 Series (TONGA, DRM 3.39.0, 5.9.0-050900rc8-generic, LLVM 10.0.1)
     37281187238 [I]                egl.c:502  | egl_render_startup             | Version : OpenGL ES 3.2 Mesa 20.3.0-devel (git-2b977ad 2020-10-06 focal-oibaf-ppa)
     37281400512 [I]               main.c:1559 | lg_run                         | Host ready, reported version: B2-rc4-11-g8692e9af80
     37281400529 [I]               main.c:1560 | lg_run                         | Starting session
VM crashes host system when booting up after qemu upgrade
#4

Thanks, I simply wanted it to confirm your versioning and hardware :).

Are you using wayland? It’s known to have some odd issues and is not supported.

If not, what version of Qemu do you have installed? The PS/2 mouse device in older versions was bugged.

You can not remove the PS/2 device as it’s part of the i440 and q35 PC standard, without it you do not have a valid PC. Normally I suggest people add the VirtIO mouse device and install the drivers from the RedHat ISO for it. When it’s added it takes priority over the PS/2 device even though both are added.

#5

I doubt that I am using Wayland already since I am on an Ubuntu-based Linux Mint 20 (with the newest RC kernel – as of yesterday – 5.9.0-050900rc8-generic).

Also

env | grep -i wayland

does not yield any output which suggests that I am indeed not running on Wayland (even in 2020 :flushed:… But yeah year 2222 will probably be the Year of GNU Hurd and Wayland :wink: )

If that was a common bug that might be it…
Let’s see the Qemu version via

dpkg -s qemu-kvm | grep Version

puts out:

Version: 1:4.2-3ubuntu6.6

Maybe too old?
Do I need to compile a newer one – since there doesn’t seem to be anything newer in my repos, or do you know of a PPA?

As for the VirtIO mouse device… Do you mean the Virtio Tablet Device which is the one Virt-Manager let’s me add? In which case I would need a pointer to the driver you are speaking of, if not I fear I have no idea were to start looking for that one :smiley:

Thank you SO MUCH for the quick answers by the way. Makes this process so much more enjoyable. I like to tinker with things but sometimes I seem to just get lost on my own :slight_smile: :wink:

#6

Great, just getting the easy issues out of the way.

4.2-3ubuntu6.6

That is quite old, not sure if the PS/2 fix was in that release, but most of use are now on QEMU 5 or later.

I am sorry, I do not use Ubuntu.

No, this device causes all manner of issues due to the way Windows prioritizes input devices. If you’re using libvirt, it might be called vfio mouse, IDR which sorry as I use QEMU directly on the command line.

No problem at all, however, I have to step out for a bit, but your questions have fallen during the day time in my Timezone (Sydney AU), and I like to keep an eye on the LG topic here since it’s my project :slight_smile: .

#7

All right, I will try to get a newer qemu running before we try anything else :slight_smile:

1 Like
#8

Let me know if you get a newer version of qemu working successfully. I’m on Linux Mint 20 as well. I used a combination of the qemu build instructions and Mathias Hueber’s guide to use 5.1.50., but after doing so, my guest wouldn’t boot.

edit Got it working. I accidentally ended up with some incorrectly symlinked files in /usr/local/share/qemu, but it worked fine after I wiped and recopied.

1 Like
#9

Hi there,
my mouse is freaking out as well as long as I do not have scroll lock enabled. However I am on up-to-date Manjaro with qemu 5.1.0-1 and libvirt 6.5.0-2. I am using Looking Glass version B2.
I have only the generic PS2 mouse, the generic PS2 keyboard an the virtio keyboard attached as input devices.

Is the cause of this problem already known or can I somehow help to identify the problem by providing logs or anything?

#10

Cause already known, just waiting for some time on my part to fix it

2 Likes
#11

Small update for the record: Updating Qemu did infact help with my issue as long as I lock Keyboard and Mouse in the VM they appear to behave themselves as I need them to do.

#12

Please test the latest bleeding-edge, a change went in yesterday that might have fixed this.