Hi On Wed, Mar 8, 2023 at 5:55 PM Markus Armbruster <arm...@redhat.com> wrote:
> marcandre.lur...@redhat.com writes: > > > From: Marc-André Lureau <marcandre.lur...@redhat.com> > > > > This allows for a more pleasant user experience. > > > > Before: > > $ ./qemu-system-x86_64 -display egl-headless,gl= > > qemu-system-x86_64: -display egl-headless,gl=: Parameter 'gl' does not > accept value '' > > > > After: > > $ ./qemu-system-x86_64 -display egl-headless,gl= > > qemu-system-x86_64: -display egl-headless,gl=: Parameter 'gl' does not > accept value '' > > Acceptable values are 'off', 'on', 'core', 'es' > > > > Signed-off-by: Marc-André Lureau <marcandre.lur...@redhat.com> > > Nice improvement here. > > Slightly ugly: > > $ qemu-system-x86_64 -nic bad > upstream-qemu: -nic bad: Parameter 'type' does not accept value 'bad' > Acceptable values are 'none', 'nic', 'user', 'tap', 'l2tpv3', > 'socket', 'stream', 'dgram', 'vde', 'bridge', 'hubport', 'netmap', > 'vhost-user', 'vhost-vdpa' > > Outright annoying: > > $ upstream-qemu -object bad > upstream-qemu: -object bad: Parameter 'qom-type' does not accept value > 'bad' > Acceptable values are 'authz-list', 'authz-listfile', 'authz-pam', > 'authz-simple', 'can-bus', 'can-host-socketcan', 'colo-compare', > 'cryptodev-backend', 'cryptodev-backend-builtin', 'cryptodev-backend-lkcf', > 'dbus-vmstate', 'filter-buffer', 'filter-dump', 'filter-mirror', > 'filter-redirector', 'filter-replay', 'filter-rewriter', 'input-barrier', > 'input-linux', 'iothread', 'main-loop', 'memory-backend-epc', > 'memory-backend-file', 'memory-backend-memfd', 'memory-backend-ram', > 'pef-guest', 'pr-manager-helper', 'qtest', 'rng-builtin', 'rng-egd', > 'rng-random', 'secret', 'secret_keyring', 'sev-guest', 'thread-context', > 's390-pv-guest', 'throttle-group', 'tls-creds-anon', 'tls-creds-psk', > 'tls-creds-x509', 'tls-cipher-suites', 'x-remote-object', > 'x-vfio-user-server' > > Note we already let users ask for this information with -object help or > -object qom-type=help. Sadly, we can't hint at that here, because it's > implemented much further up the call chain, and other call chains don't. > > If HMP command sendkey didn't bypass the input visitor, the 26 screen > lines of hint for QKeyCode would likely scroll the error message off the > screen. > > Should we suppress this hint when it's too long to be useful? > I don't have strong opinions.. perhaps stop after first 5 with "..." ? (Ideally, we would have shell completion scripts that would be able to help us, but hey that's another level! :)
