intel-microcode is closely related to kernel behavior, and so wouldn't surprise me if it's involved - like I mentioned earlier invariably input device + power management bugs are something kernel related.
However, looking at the diff for the intel-microcode upgrade the changes are highly processor specific, and affects a small handful: http://launchpadlibrarian.net/424908874/intel- microcode_3.20190514.0ubuntu0.19.04.1_3.20190514.0ubuntu0.19.04.3.diff.gz I'm guessing for a qemu environment these aren't even relevant, but if one of the lines matches your host cpu then perhaps this would be worth more investigation. Otherwise, probably another red herring. There is more you could try though. I suggested some ideas in my previous comment. You could also run xlsclients before and after reproducing the error, and see if there are any new X clients running that might have a grab on the cursor, and then kill them until the touchpad comes back. (See http://who-t.blogspot.com/2010/11/high-level-overview-of-grabs.html) I hate to mention this as a possibility, but like I mentioned earlier, sometimes these bugs can reproduce very non-reliably. I've seen cases where, for instance, the root cause always existed but it was some change in usage or other random things, that caused the input behavior to suddenly start happening, only to disappear again - quite mysteriously - after some other system change. The way input devices work, at least in context of this particular bug, is that each movement or click generates an "event", that gets communicated up through the system through various layers until an application consumes it. You can read about this in more extensive detail at https://www.x.org/wiki/Development/Documentation/InputEventProcessing/ That leads us to two questions for this case: A) Is the event getting generated at all? and B) If it is, then is something unexpectedly consuming it? So a good first step would be to eliminate one or the other of these. You've made some progress towards ruling out B. For testing if the event is getting generated, the tool 'xev' is one of the easiest and handiest places to start from. Have you had a chance to give that a test? Run it from the command line when you've got the non- responsive touchpad, and use the touchpad and see if anything prints in the xev window. You can do some googling to get some tips and tricks for filtering xev output and to understand what its output means. 'xdotool' can also be useful; it's intended for automation but it lets you manhandle mouse events, such as force a click or mouse up/down. Longshot but at least is easy / low risk to try. My guess though is the event isn't even getting generated. In that case i'd proceed with the standard troubleshooting techniques to see if something's wrong with the device itself, and go from there. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1834113 Title: QEMU touchpad input erratic after wakeup from sleep Status in QEMU: New Status in libvirt package in Ubuntu: New Status in qemu package in Ubuntu: Incomplete Bug description: Using Ubuntu host and guest. Normally the touchpad works great. Within the last few days, suddenly, apparently after a wake from sleep, the touchpad will behave erratically. For example, it will take two clicks to select something, and when moving the cursor it will act as though it is dragging even with the button not clicked. A reboot fixes the issue temporarily. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: qemu 1:3.1+dfsg-2ubuntu3.1 Uname: Linux 5.1.14-050114-generic x86_64 ApportVersion: 2.20.10-0ubuntu27 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Mon Jun 24 20:55:44 2019 Dependencies: EcryptfsInUse: Yes InstallationDate: Installed on 2019-02-20 (124 days ago) InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 20180608-09:38 Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 002: ID 8087:0025 Intel Corp. Bus 001 Device 003: ID 0c45:671d Microdia Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: Dell Inc. Precision 5530 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR=<set> LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.1.14-050114-generic root=UUID=18e8777c-1764-41e4-a19f-62476055de23 ro mem_sleep_default=deep mem_sleep_default=deep acpi_rev_override=1 scsi_mod.use_blk_mq=1 nouveau.modeset=0 nouveau.runpm=0 nouveau.blacklist=1 acpi_backlight=none acpi_osi=Linux acpi_osi=! SourcePackage: qemu UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/26/2019 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.10.1 dmi.board.name: 0FP2W2 dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.10.1:bd04/26/2019:svnDellInc.:pnPrecision5530:pvr:rvnDellInc.:rn0FP2W2:rvrA00:cvnDellInc.:ct10:cvr: dmi.product.family: Precision dmi.product.name: Precision 5530 dmi.product.sku: 087D dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1834113/+subscriptions
