On 11/20/20 10:14, Stephen Finucane wrote:
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: 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.
Ack, understood.
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.
OK, this was something I didn't previously get. So, your proposal is that if you were to add hw_input_bus=usb you would also add the USB keyboard and USB mouse for x86. So you end up with USB tablet and keyboard and mouse on x86. You just also happen to have PS2 keyboard and mouse as well and they will not be defaulted. And then AArch64 would get USB tablet and keyboard and mouse with hw_input_bus=usb. I had been previously thinking the hw_input_bus addition would be a change in name only and not a change (additive change) of behavior as well.
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?
Now that I understand that the user's bus choice via hw_input_bus would indeed be honored for all of tablet, keyboard, and mouse for all architectures, I can acknowledge that hw_input_bus could be an improved name over hw_pointer_model. I still think the main, important user selectable bit is the pointer, so I don't think the hw_pointer_model name is so terrible. The remaining concern would be around the work users and operators would have to do to adopt the new name. Are you thinking that existing images just stay as-is and if users want virtio or all USB they can only get it via hw_input_bus=virtio or hw_input_bus=usb and that will facilitate use of the new image property? So the summary would be: * hw_pointer_model=usbtablet you still get a USB tablet and the rest is unselectable * hw_input_bus=usb you get USB everything * hw_input_bus=virtio you get virtio everything If this is the case, then I would say I'm no longer actively opposed to adding hw_input_bus image property to get virtio, but I'm still not sure whether it's worth the amount of change and new image property users need to learn, given that pointer is the main thing users care about and we already have the pointer property. I'll defer to others to decide whether it's worth it, as I'm ambivalent :) Cheers, -melanie
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
[1] https://review.opendev.org/#/c/756552/ <https://review.opendev.org/#/c/756552/>