Re: [Xen-devel] [PATCH v1 1/2] libxl: introduce new backend type VINPUT

From: Oleksandr Grytsov <al1img@gmail.com>
To: Ian Jackson <ian.jackson@citrix.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Oleksandr Grytsov <oleksandr_grytsov@epam.com>,
	"wl@xen.org" <wl@xen.org>
Subject: Re: [Xen-devel] [PATCH v1 1/2] libxl: introduce new backend type VINPUT
Date: Fri, 11 Oct 2019 18:57:42 +0300	[thread overview]
Message-ID: <CACvf2oV6iFM6x1bs8JPT28Eqny0gARh8MtSTedbgAP-m9CTP=w@mail.gmail.com> (raw)
In-Reply-To: <23968.39034.34800.276030@mariner.uk.xensource.com>

On Fri, Oct 11, 2019 at 5:58 PM Ian Jackson <ian.jackson@citrix.com> wrote:
>
> Oleksandr Grytsov writes ("[PATCH v1 1/2] libxl: introduce new backend type VINPUT"):
> > From: Oleksandr Grytsov <oleksandr_grytsov@epam.com>
> >
> > There are two kind of VKBD devices: with QEMU backend and user space
> > backend. In current implementation they can't be distinguished as both use
> > VKBD backend type. As result, user space KBD backend is started and
> > stopped as QEMU backend. This commit adds new device kind VINPUT to be
> > used as backend type for user space KBD backend.
>
> I find this confusing.  I'm not sure this change is right.  But I'm
> afraid the original patches in this area passed me by so I don't know
> much about it.
>
> I think it was a48e00f14a2d "libxl: add backend type and id to vkb"
> which introduced what you are calling "user space" backends.  It
> appears that the vkb backend type enum was introduced there
> specifically to distinguish between these two situations.  For reasons
>
> Am I wrong ?  If not, why is this not working or not suitable ?

You are right. It is not working in some cases due to QEMU_BACKEND macro.
QEMU_BACKEND treats both backends as QEMU. As result xl performs device
hotplug on add/remove device. Which is not expected in case "user
space" backend.

In this patch I propose solution similar to VUSB device. Where VUSB
used for frontend
and depends on backend (kernel or QEMU) either VUSB or QUSB used for backend
device type e.g. use different backend device type for different
backends. It would be
more clear if, for example, QEMU backend has QKBD name and all other
VKBD. But it
would require changes on QEMU side too. That's why I've chosen VINPUT name.

Introducing new backend device type for VKBD also allows to have both backends
(QEMU and non QEMU) run in same domain. Not sure if it is useful
scenario but with
this proposal it is possible from technical point of view.

>
> I also don't understand why the "user space" kbd backend seems to be
> "linux" in the enum.

I agree this is not so good name. But I don't know how to call
backends which are not running
inside QEMU in general.

> Where is the implementation of this user space
> backend ?

We have extended kbd interface (kbdif.h) to support multi-touch events
as well. And we have
implemented own kbd backend https://github.com/xen-troops/displ_be/
It is integrated with display backend as both use wayland API.

> Is it be controlled entirely through xenstore ?

Yes it is controlled entirely through xenstore: lib xl creates
frontend/backend entries with
initial states and configuration.

> Ian.

-- 
Best Regards,
Oleksandr Grytsov.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel