[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2] usb: Remove legacy -usbdevice option

From: Thomas Huth
Subject: Re: [Qemu-devel] [PATCH v2] usb: Remove legacy -usbdevice option
Date: Mon, 8 Jan 2018 08:43:29 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0

On 04.01.2018 18:57, Paolo Bonzini wrote:
> On 04/01/2018 18:45, Samuel Thibault wrote:
>> Paolo Bonzini, on jeu. 04 janv. 2018 18:11:00 +0100, wrote:
>>> On 04/01/2018 16:56, Samuel Thibault wrote:
>>>>> However, adding magic to "-device usb-braille" that creates both a
>>>>> front-end and a back-end is completely the opposite of sane...
>>>> Well, this is also what happens with -device usb-mouse, usb-kbd etc.:
>>>> they also plug with keyboard & mouse pipes of the qemu graphical
>>>> frontend. braille is just the same vein for the user.
>>> No, they don't create a new UI object magically that wasn't there
>>> before.  They just let you add a device, e.g. a USB tablet, that listens
>>> on an _existing_ UI (GTK+ or SDL or similar).
>> Technically for the qemu developper, yes.
>> But for the user, no.
> That's not true.   With or without "-usbdevice tablet", you use the same
> mouse or keyboard device as the input source.

But from a users point of view: Why are the mouse and keyboard input
sources available out of the box, while braille has to be specified
manually? I think Samuel has a point here...

So just another idea: Instead of adding the magic sugar code to the
usb-braille device, we could also add some code to vl.c or somewhere
else that checks whether a braille guest device is available and then
wires it up automatically with a braille host device (unless
-no-defaults has been specified, or the user already set chardev=...
there). Would that make more sense in your eyes than to put this code
into the usb-braille device directly?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]