On Wed, 2020-11-18 at 16:12 -0800, melanie witt wrote:
On 11/16/20 02:41, Stephen Finucane wrote:
On Thu, 2020-11-12 at 17:09 -0800, melanie witt wrote:
Needless to say, I don't like this idea and prefer we took another
tack
and kept 'hw_input_bus' but didn't build on 'hw_pointer_model' and
instead "deprecated" it. We can't really ever remove the an image
metadata property, since that would be a breaking upgrade, which
means
we'll eventually be left with effectively dead code to maintain
forever. However, I don't think that's a big deal.
'hw_pointer_model=usbtablet' is already on a path to obsolescence as
the Q35 machine type slowly becomes the default on x86 hosts and the
use of non-x86 hosts grows since neither support PS2 and must use a
USB-based input device. In addition, I think the extrapolation of
'virtiotablet' to mean also virtio-based keyboard is unclear and
leaves
a gaping hole w.r.t. requesting USB-based keyboards on non-AArch64
hosts (where it's currently added by default), since we don't
currently
do this extrapolation and introducing it would be breaking change on
x86 hosts (instances would suddenly switch from PS2-based keyboards
to
USB-based ones).
For some reason your email didn't quote my inline replies when you
replied back, so I'm going to label them for clarity.
Looks like Evolution has broken plain text editing :( Apologies.
melwitt:
If I understand correctly, we do choose the "best fit" keyboard based
on architecture, independent of the requested hw_pointer_model, today.
stephenfin:
Not quite. libvirt on x86 will automatically add a PS2 mouse and
keyboard (even if you request something else) because that's what QEMU
does. On all other platforms (to the best of my knowledge, based on
Kashyap quizzing a handful of multi-arch libvirt devs), this must be
done manually. We currently only do this for AArch64, through the non-
configurable addition of a USB keyboard [1]. There is currently no way
to request e.g. a USB or virtio keyboard on any architecture.
Hm, OK, apologies for my lack of familiarity here. So there are really
three things here: tablet, mouse, and keyboard. And the user today can
choose hw_pointer_model as None (leave it to default behavior) or
usbtablet which sets the input.type=tablet and the input.bus=usb. And
then the mouse and keyboard are set to whatever they have to be given
the architecture.
Sort of. As above, you'll get the PS2 keyboard for free on x86. You'll get a USB keyboard on AArch64. You won't get anything on any other arch.
melwitt:
It feels like it would be simpler to continue doing that and add a
virtio choice to hw_pointer_model and let the driver pick the "best"
keyboard to go along with that. Is it your view that having the
driver choose a virtio keyboard if hw_pointer_model=virtiotablet is
inconsistent with the existing "best fit" keyboard selection
behavior?
stephenfin:
My concerns are twofold. Firstly, having the value of
'hw_pointer_model' influence the keyboard bus is poor UX, since this
"feature" is not at all apparent from the property name. Secondly,
'hw_pointer_model' is a poorly designed property, given it configured
the bus as well as the model, munging the two.
To be clear, I agree that having different buses for keyboard and
pointer makes no sense. There's no reason they shouldn't be the same.
I'm just saying that configuring the bus for input devices via an
appropriately named 'hw_input_bus' image metadata property makes much
more sense that maybe getting one configured magically based on the
"pointer model" in use.
OK, so the introduction of virtio would be the first time that we would
be able to set all of tablet, mouse, and keyboard to the same bus. What
if they don't want all three input devices, could it cause any
undesirable behavior for them?
You don't have any choice: if you have a graphical console, you need a pointer (mouse or tablet) and you need a keyboard for it to be usable. Conversely, if you don't have a graphical console, then we've no need to add either. If a user didn't want a mouse and keyboard then they can and should disable graphical consoles.
And then if they set hw_input_bus=usb for libvirt on x86 they'd get a
USB tablet, a PS2 mouse, and a PS2 keyboard and on AArch64 they'd get a
USB tablet, ? mouse, and USB keyboard.
No, on x86 you'd get a USB tablet and keyboard, and a PS2 mouse PS2 keyboard. This is because there isn't currently a way to disable the PS2 devices in libvirt/QEMU. However, this is not an issue since the guest OS will default to using the USB-based devices (or so danpb tells me). Also note that this is very similar to how things currently work with 'hw_pointer_model=usbtablet': setting this means you'll get a USB tablet (but not keyboard), and a PS2 mouse and keyboard.
On AArch64 and any other non-x86 host, they'd get simply a USB tablet and a USB keyboard because libvirt doesn't have that QEMU quirk to work with.
I dunno, it's all pretty confusing IMHO. My point in my last reply was
that for the libvirt on x86 case, if the user sets hw_input_bus=usb, how
would they know they're really only specifying the tablet? Today they
use hw_pointer_model=usbtablet which makes it clear what they have
control over. I acknowledge that for hw_input_bus=virtio, things all
line up nicely, but for everything else, it doesn't necessarily.
As above, they're not. hw_input_bus means USB keyboard and tablet on any host. The only arch that will do something weird is x86, where we have those pesky PS2 remnants that we can't get rid of.
This makes me think it would be clearest and least confusing (IMHO) to
add a new option like dansmith mentioned, hw_pointer_model=virtio. That
way it's not talking only about a tablet but generically just 'virtio'
and then all of tablet, mouse, and keyboard get added with bus=virtio.
melwitt:
From what I understand, the pointer is the only user selection we can guarantee and the keyboard is architecture dependent.
stephenfin:
Again, not really. There isn't an analog for pointer vs. mouse when it
comes to keyboards. The keyboard isn't architecture dependent. What is
architecture dependent is whether you get a keyboard and mouse by
default (yes on x86, in the form of a PS2 mouse and keyboard, and no
for everyone else).
melwitt:
If we "deprecated" hw_pointer_model and introduced hw_input_bus, how does
the user know which thing (pointer or keyboard) they are specifying?
If users can't actually choose the keyboard and can only choose the pointer,
wouldn't presenting a selection of a generic "hw_input_bus" be more confusing
than hw_pointer_model?
stephenfin:
They can choose the _bus_ that the keyboard uses. There's an assumption
here that if you request a graphics device (VNC, SPICE, ...) then you
will get a keyboard and tablet input devices, because that graphics
device is unusable otherwise. There is also an assumption (based on
dansmith's comments about mouse being only used for legacy compat
reasons) that the user will never want to explicitly request a 'mouse'
pointer model and should therefore get 'tablet' by default. Based on
these two assumptions, the only thing remaining is to decide how the
keyboard and tablet devices will be attached to the guest...achieved
via a sensibly named 'hw_input_bus' image metadata property. That seems
reasonable to me.
I hope I'm not woefully wrong here again, but IIUC they can't choose the
bus the mouse and keyboard uses for libvirt on x86, they get PS2
regardless. This is why I feel like hw_input_bus as a replacement for
hw_pointer_model is not clear. It's only guaranteed to be used for the
tablet bus.
I'm sorry I'm not seeing how hw_pointer_model=virtio isn't the clearest,
least confusing way to add virtio. (Or maybe
hw_pointer_model=virtiotabletmousekeyboard ?!)
Thanks for taking the time to explain the technical details around this
area of the code. I think I now understand your point of view since the
name of hw_pointer_model doesn't nicely convey the tablet+mouse+keyboard
setting when it comes to virtio. On the flip side of that, I feel like
hw_input_bus=usb when it's only going to be honored for the tablet for
libvirt on x86 seems even less nice.
Given the above, do you still have the same concerns around using hw_input_bus?
Cheers,
Stephen
This is all just MHO. If most other people think that hw_input_bus is
the clearer and more user-friendly way to present this config, then I
will of course accept the consensus.
Cheers,
-melanie
We need to decide what approach to go for before I rework this. If
anyone has input, particularly operators that think they'd use this
feature, I'd love to hear it so that I can t̶e̶l̶l̶ ̶d̶a̶n̶s̶m̶i̶t̶h̶
̶t̶o̶ ̶s̶h̶o̶v̶e̶ ̶i̶t̶ come to the best possible solution ;-) Feel
free to either reply here or on the review [1].
Cheers,
Stephen