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

Re: [Xen-devel] [PATCH] Input: xen-kbdfront - allow better run-time configuration



On 04/26/2018 10:16 PM, Dmitry Torokhov wrote:
On Tue, Apr 24, 2018 at 08:55:19AM +0300, Oleksandr Andrushchenko wrote:
On 04/23/2018 09:53 PM, Dmitry Torokhov wrote:
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@xxxxxxxx>

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).
Ok, but in order to preserve the default behavior, e.g.
pointer and keyboard devices are always created now, I'll have
to have reverse features in the protocol:
  - feature-no-pointer
  - feature-no-keyboard
The above may be set as a part of frontend's configuration and
if missed are considered to be set to false.
I think you can have them as "feature-pointer" and "feature-keyboard"
(no negation), but assume not present considered enabled. I.e.

        kbd = xenbus_read_unsigned(..., XENKBD_FIELD_FEAT_KEYBOARD, 1);
        if (kbd) {
                ...
Thank you for your comments,
could you please take a look at the patch [1] where I am trying
to change the corresponding Xen protocol to fit the requirements?
As we agreed I have to change the protocol first, so this patch is no longer valid
        }

Thanks.
Thank you,
Oleksandr
[1] https://www.spinics.net/lists/linux-input/msg56094.html

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.