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