xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Oleksandr Andrushchenko <andr2000@gmail.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: lars.kurth@citrix.com, vlad.babchuk@gmail.com,
	dario.faggioli@citrix.com, julien.grall@arm.com,
	andrii.anisov@gmail.com, olekstysh@gmail.com, al1img@gmail.com,
	JBeulich@suse.com, xen-devel@lists.xenproject.org,
	joculator@gmail.com
Subject: Re: [PATCH 2/2] xen/kbdif: add multi-touch support
Date: Wed, 11 Jan 2017 11:32:39 +0200	[thread overview]
Message-ID: <8da968a0-bfde-57eb-27cc-ea5a8b6445ed@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1701101622320.8205@sstabellini-ThinkPad-X260>

On 01/11/2017 02:29 AM, Stefano Stabellini wrote:
> On Tue, 10 Jan 2017, Oleksandr Andrushchenko wrote:
>> On 01/07/2017 12:37 AM, Stefano Stabellini wrote:
>>> On Fri, 6 Jan 2017, Oleksandr Andrushchenko wrote:
>>>> From: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@epam.com>
>>>>
>>>> Signed-off-by: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@epam.com>
>>>> ---
>>>>    xen/include/public/io/kbdif.h | 228
>>>> ++++++++++++++++++++++++++++++++++++++++++
>>>>    1 file changed, 228 insertions(+)
>>>>
>>>> diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h
>>>> index 0e19a40..1b446f9 100644
>>>> --- a/xen/include/public/io/kbdif.h
>>>> +++ b/xen/include/public/io/kbdif.h
>>>> @@ -57,6 +57,12 @@
>>>>     *      Backends, which support reporting of absolute coordinates for
>>>> pointer
>>>>     *      device should set this to 1.
>>>>     *
>>>> + * feature-multi-touch
>>>> + *      Values:         <uint>
>>>> + *
>>>> + *      Backends, which support reporting of multi-touch events
>>>> + *      should set this to 1.
>>>> + *
>>>>     *------------------------- Pointer Device Parameters
>>>> ------------------------
>>>>     *
>>>>     * width
>>>> @@ -87,6 +93,11 @@
>>>>     *      Request from backend to report absolute pointer coordinates
>>>>     *      (XENKBD_TYPE_POS) instead of relative ones (XENKBD_TYPE_MOTION).
>>>>     *
>>>> + * request-multi-touch
>>>> + *      Values:         <uint>
>>>> + *
>>>> + *      Request from backend to report multi-touch events.
>>> I think in English should be "request backend to report multi-touch
>>> events". Same above.
>> Done
>>>> + *
>>>>     *----------------------- Request Transport Parameters
>>>> -----------------------
>>>>     *
>>>>     * event-channel
>>>> @@ -107,6 +118,43 @@
>>>>     *      OBSOLETE, not recommended for use.
>>>>     *      A unique (within the guest domain given) value identifying event
>>>>     *      channel and page reference pair.
>>>> + *
>>>> + *----------------------- Multi-touch Device Parameters
>>>> -----------------------
>>>> + *
>>>> + * Every multi-touch input device uses a dedicated event ring and is
>>> For clarity I would say "Every multi-touch input device uses a dedicated
>>> frontend/backend connection". That includes a ring, an event channel,
>>> and xenstore entries.
>>>
>> Done
>>>> + * configured via XenStore properties under XENKBD_PATH_MTOUCH folder.
>>> I don't understand why we need a new xenstore folder. Why do we need
>>> XENKBD_PATH_MTOUCH?
>> This is just another (IMO, cleaner) approach to define
>> properties in XenStore for multiple instances.
>> Let's see what vif does on my PC:
>> /local/domain/11/device/vif/0/queue-0/tx-ring-ref = "2304"
>> ...
>> /local/domain/11/device/vif/0/queue-1/tx-ring-ref = "2306"
>> ...
>> /local/domain/11/device/vif/0/queue-2/tx-ring-ref = "2308"
>> ...
>> /local/domain/11/device/vif/0/queue-3/tx-ring-ref = "2310"
>> ...
>> /local/domain/11/device/vif/0/request-rx-copy = "1"
>>
>> We have folders "queue-%d" per queue which in my case are
>>
>> under XENKBD_PATH_MTOUCH.
>>
>> /local/domain/11/device/vkbd/0/mtouch/0/width = "3200"
>> /local/domain/11/device/vkbd/0/mtouch/0/height = "3200"
>> /local/domain/11/device/vkbd/0/mtouch/0/num-contacts = "5"
>> /local/domain/11/device/vkbd/0/mtouch/1/width = "6400"
>> /local/domain/11/device/vkbd/0/mtouch/1/height = "6400"
>> /local/domain/11/device/vkbd/0/mtouch/1/num-contacts = "10"
>>
>> Namely, instead of "mtouch-%d" I use "mtouch/%d/.
>> This is just like using "/local/domain/%d" but not
>> "/local/domain-%d", so "mtouch/%d" seem to be more
>> consistent.
> I agree that mtouch/%d is better than mtouch-%d, but it's only necessary
> if we have more than one mtouch per vkbd. I would configure it so that
> one can only have one mtouch per vkbd:
>
>    /local/domain/11/device/vkbd/0/mtouch/width = "3200"
>    /local/domain/11/device/vkbd/0/mtouch/height = "3200"
>    /local/domain/11/device/vkbd/1/mtouch/width = "6400"
>    /local/domain/11/device/vkbd/1/mtouch/height = "6400"
correct me if I'm wrong, but this notation implies
multiple drivers support, not a single driver with
multiple devices.
If so, *DISCLAIMER* *Linux* I see no simple solution to
do that in the front driver.
Could you please clarify?
> This is also what I was referring to when I wrote:
>
>> It is useful to distinguish mouse events from keyboard events, from
>> multitouch events more easily, but I don't think we should support
>> multiple keyboards or multiple mice on the same xenkbd ring. If we need
>> two mice, we can setup two xenkdb rings.
> The same applies to multitouch devices, I think.
>
> But maybe you have good reasons for supporting multiple multitouch
> devices on a single vkbd connection? How many do you expect to have on a
> single VM?
well, let me put the whole tree from xenstore:

/local/domain/0/backend/vkbd/2/0/frontend-id = "2"
/local/domain/0/backend/vkbd/2/0/frontend = "/local/domain/2/device/vkbd/0"
/local/domain/0/backend/vkbd/2/0/dev_id = "0"
/local/domain/0/backend/vkbd/2/0/state = "6"
/local/domain/0/backend/vkbd/2/0/feature-abs-pointer = "1"
/local/domain/0/backend/vkbd/2/0/width = "2048"
/local/domain/0/backend/vkbd/2/0/height = "2048"
/local/domain/0/backend/vkbd/2/0/feature-multi-touch = "1"

/local/domain/2/device/vkbd/0/backend-id = "0"
/local/domain/2/device/vkbd/0/backend = "/local/domain/0/backend/vkbd/2/0"
/local/domain/2/device/vkbd/0/state = "6"
/local/domain/2/device/vkbd/0/request-abs-pointer = "1"
/local/domain/2/device/vkbd/0/page-ref = "1248025"
/local/domain/2/device/vkbd/0/page-gref = "336"
/local/domain/2/device/vkbd/0/event-channel = "43"

/local/domain/2/device/vkbd/0/request-multi-touch = "1"

/local/domain/2/device/vkbd/0/mtouch/0/width = "3200"
/local/domain/2/device/vkbd/0/mtouch/0/height = "3200"
/local/domain/2/device/vkbd/0/mtouch/0/num-contacts = "5"
/local/domain/2/device/vkbd/0/mtouch/0/page-ref = "1252386"
/local/domain/2/device/vkbd/0/mtouch/0/page-gref = "335"
/local/domain/2/device/vkbd/0/mtouch/0/event-channel = "44"

/local/domain/2/device/vkbd/0/mtouch/1/width = "6400"
/local/domain/2/device/vkbd/0/mtouch/1/height = "6400"
/local/domain/2/device/vkbd/0/mtouch/1/num-contacts = "10"
/local/domain/2/device/vkbd/0/mtouch/1/page-ref = "2376038"
/local/domain/2/device/vkbd/0/mtouch/1/page-gref = "337"
/local/domain/2/device/vkbd/0/mtouch/1/event-channel = "45"

 From the above:
1. No change to the existing kbd+ptr:
1.1. They still share a dedicated (single) connection
channel as they did before multi-touch.
1.2. No multi-touch events via that connection
1.3. Old backends/frontends will see no difference
2. Each multi-touch device has its own:
2.1. Configuration (width x height, num-contacts)
2.2. Own connection channel (page-ref, event-channel)

So, for the example above: 1 kbd + 1 ptr + 2 mt devices
within a single driver, 3 connections

Note: this doesn't allow multiple kbd and ptr devices.

Hope this answers your questions,
Oleksandr

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

  reply	other threads:[~2017-01-11  9:32 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-06  9:32 [PATCH 0/2] xen/kbdif: add multi-touch support Oleksandr Andrushchenko
2017-01-06  9:32 ` [PATCH 1/2] xen/kbdif: update protocol documentation Oleksandr Andrushchenko
2017-01-06 22:20   ` Stefano Stabellini
2017-01-10  7:21     ` Oleksandr Andrushchenko
2017-01-11 17:35       ` Dario Faggioli
2017-01-11 18:40         ` Oleksandr Andrushchenko
2017-01-11 22:50           ` Dario Faggioli
2017-01-12  6:36             ` Oleksandr Andrushchenko
2017-01-18 19:41               ` Oleksandr Andrushchenko
2017-01-18 20:28                 ` Stefano Stabellini
2017-01-06  9:32 ` [PATCH 2/2] xen/kbdif: add multi-touch support Oleksandr Andrushchenko
2017-01-06 22:37   ` Stefano Stabellini
2017-01-10  7:53     ` Oleksandr Andrushchenko
2017-01-11  0:29       ` Stefano Stabellini
2017-01-11  9:32         ` Oleksandr Andrushchenko [this message]
2017-01-19 22:10           ` Stefano Stabellini
2017-01-11  8:01 ` [PATCH 0/2] " Oleksandr Andrushchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8da968a0-bfde-57eb-27cc-ea5a8b6445ed@gmail.com \
    --to=andr2000@gmail.com \
    --cc=JBeulich@suse.com \
    --cc=al1img@gmail.com \
    --cc=andrii.anisov@gmail.com \
    --cc=dario.faggioli@citrix.com \
    --cc=joculator@gmail.com \
    --cc=julien.grall@arm.com \
    --cc=lars.kurth@citrix.com \
    --cc=olekstysh@gmail.com \
    --cc=sstabellini@kernel.org \
    --cc=vlad.babchuk@gmail.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).