[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180423185325.GB66646@dtor-ws>
Date: Mon, 23 Apr 2018 11:53:25 -0700
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: Oleksandr Andrushchenko <andr2000@...il.com>
Cc: Juergen Gross <jgross@...e.com>, xen-devel@...ts.xenproject.org,
linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
lyan@...e.com, boris.ostrovsky@...cle.com,
andrii_chepurnyi@...m.com,
Oleksandr Andrushchenko <oleksandr_andrushchenko@...m.com>
Subject: Re: [PATCH] Input: xen-kbdfront - allow better run-time configuration
On Thu, Apr 19, 2018 at 02:44:19PM +0300, Oleksandr Andrushchenko wrote:
> On 04/19/2018 02:25 PM, Juergen Gross wrote:
> > On 18/04/18 17:04, Oleksandr Andrushchenko wrote:
> > > From: Oleksandr Andrushchenko <oleksandr_andrushchenko@...m.com>
> > >
> > > It is now only possible to control if multi-touch virtual device
> > > is created or not (via the corresponding XenStore entries),
> > > but keyboard and pointer devices are always created.
> > Why don't you want to go that route for keyboard and mouse, too?
> > Or does this really make no sense?
> Well, I would prefer not to touch anything outside Linux and
> this driver. And these settings seem to be implementation specific.
> So, this is why introduce Linux module parameters and don't extend
> the kbdif protocol.
Why do you consider this implementation specific? How other guests
decide to forego creation of relative pointer device or keyboard-like
device?
You already have "features" for absolute pointing device and multitouch,
so please extend the protocol properly so you indeed do not code
something implementation-specific (i.e. module parameters).
Thanks.
--
Dmitry
Powered by blists - more mailing lists