Project

General

Profile

Feature #9425

Enable Spice with an absolute pointing device in the test suite guest

Added by anonym over 4 years ago. Updated about 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Test suite
Target version:
Start date:
05/18/2015
Due date:
% Done:

100%

Feature Branch:
test/9425-enable-spice-and-asbolute-pointing-device
Type of work:
Code
Blueprint:
Starter:
Affected tool:

Description

Initial results suggest that this greatly increase robustness when running the test suite in a nested VM setup (e.g. on lizard) or when using the snapshot improvements of #8008/#6094. Presumably the absolute pointer results in higher accuracy, and fewer lost (or "messed up") mouse events.

Associated revisions

Revision b81076a1 (diff)
Added by anonym over 4 years ago

Enable Spice in the guest.

This seems to help with the issues we have with lost mouse events, in
particular in combination with an absolute pointing device, like the
'tablet' we already have.

There are some interesting bits about this mentioned in the Spice
manual:

https://elmarco.fedorapeople.org/manual.html

So currently we use mouse mode='client' which "is appropriate for
... a loaded server, since cursor has smooth motion and
responsiveness", which we have some data suggestion have been
affecting us (see discussion on #8928). However, it also says "the
cursor might lose synchronization (position and shape) for a while"
but it's not mentioned what may cause this (when there's high
load?). It could be interesting to test mouse mode='server' too, just
for comparison.

Will-fix: #9425

Revision 2dd9895c (diff)
Added by anonym over 4 years ago

Blacklist the psmouse kernel module.

At least when two "relative" pointing devices are present at the same
time, like a ps2 mouse and usb mouse, I've seen major breakage caused
by host mouse events being used for each such device in virt-viewer,
effectively doubling all mouse events inside the guest (i.e. one click
=> double click, mouse movements are doubled, etc). Hence it feels
safer to disable the ps2 mouse and only rely on the ("absolute")
tablet device (which has further improvements via Spice).

Unfortunately it seems impossible to remove the ps2 mouse since it's
part of all QEMU machine templates, including the one we use,
presumably with the exception of 'none', which should be an empty
machine. However, I've so far not been able to come up with a config
that works based on 'none' (generally I get alias errors with the PCI
controller). So we also have to blacklist the module.

Will-fix: #9425

Revision ade7bbad
Added by intrigeri over 4 years ago

Merge remote-tracking branch 'origin/test/9425-enable-spice-and-asbolute-pointing-device' into stable

Fix-committed: #9425

History

#2 Updated by anonym over 4 years ago

  • Status changed from Confirmed to In Progress

#3 Updated by anonym over 4 years ago

#4 Updated by anonym over 4 years ago

  • Assignee changed from anonym to kytv
  • % Done changed from 0 to 50
  • QA Check set to Ready for QA
  • Feature Branch set to test/9425-enable-spice-and-asbolute-pointing-device

I already asked you to test Spice over IRC, and IIRC you didn't have such good results. However, now with the blacklisting of the psmouse module you hopefully will get better results.

#5 Updated by kytv over 4 years ago

  • Assignee changed from kytv to intrigeri

I'm happy with the changes and I think it does make things better.

I still have the problem in feature/jessie:'s encryption.feature, causing me to need to double-click the key window in the key selection step and only there.

#6 Updated by intrigeri over 4 years ago

  • Assignee changed from intrigeri to anonym
  • QA Check changed from Ready for QA to Info Needed

I don't understand why 2dd9895 is at the same time removing <input type='mouse' bus='ps2'/>, and stating that "it seems impossible to remove the ps2 mouse". If the end result is that we'll have the ps2 mouse anyway, what's the value of removing it from the domain config? I find this misleading, as it may lead someone to believe (reading the domain config) that the system under test won't have any ps2 mouse, which is wrong. What do you think?

Once done with that, please reassing to kytv, so that he can make it clear what exactly you tested (without local hacks) on a Tails/Wheezy ISO, with that branch merged in (I could not find this info above).

#7 Updated by anonym over 4 years ago

  • Assignee changed from anonym to kytv

intrigeri wrote:

I don't understand why 2dd9895 is at the same time removing <input type='mouse' bus='ps2'/>, and stating that "it seems impossible to remove the ps2 mouse". If the end result is that we'll have the ps2 mouse anyway, what's the value of removing it from the domain config? I find this misleading, as it may lead someone to believe (reading the domain config) that the system under test won't have any ps2 mouse, which is wrong. What do you think?

My take is rather that since we're basing our virtual hardware setup on a machine template, the domain specification itself isn't enough to look at. For instance, no keyboard device is listed either, but we still get the default (PS/2) keyboard from the template machine. Good enough?

Once done with that, please reassing to kytv, so that he can make it clear what exactly you tested (without local hacks) on a Tails/Wheezy ISO, with that branch merged in (I could not find this info above).

The ball is back to you, kytv!

#8 Updated by intrigeri over 4 years ago

anonym wrote:

Good enough?

Yes.

#9 Updated by kytv over 4 years ago

intrigeri wrote:

Once done with that, please reassing to kytv, so that he can make it clear what exactly you tested (without local hacks) on a Tails/Wheezy ISO, with that branch merged in (I could not find this info above).

I had run with this merged into stable and without any local "hacks".

I'm re-running all scenarios in stable with this branch merged in. Once this run is done I'll send it back to intrigeri for merging if he's happy with it.

#10 Updated by kytv over 4 years ago

  • Assignee changed from kytv to intrigeri
  • QA Check changed from Info Needed to Ready for QA

As far as Tails/Wheezy is concerned, I'm still happy with the changes. (All features were run without any "local hacks")

#11 Updated by intrigeri over 4 years ago

  • Status changed from In Progress to Fix committed
  • % Done changed from 50 to 100

#12 Updated by intrigeri over 4 years ago

  • Assignee deleted (intrigeri)
  • QA Check changed from Ready for QA to Pass

Yay!

#13 Updated by intrigeri about 4 years ago

  • Status changed from Fix committed to Resolved

Also available in: Atom PDF