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

[Xen-devel] Re: [PATCH] input/xen-fbfront: advertise either absolute or relative coordinates



On Mon, Mar 14, 2011 at 11:01:44AM +0100, Olaf Hering wrote:
> On Sat, Mar 12, Dmitry Torokhov wrote:
> 
> > Hi Stefano,
> > 
> > On Fri, Mar 11, 2011 at 11:30:10AM +0000, Stefano Stabellini wrote:
> > > From: Olaf Hering <olaf@xxxxxxxxx>
> > > 
> > > A virtualized display device is usually viewed with the vncviewer
> > > application, either by 'xm vnc domU' or with vncviewer localhost:port.
> > > vncviewer and the RFB protocol provides absolute coordinates to the
> > > virtual display. These coordinates are either passed through to a PV
> > > guest or converted to relative coordinates for a HVM guest.
> > > 
> > > A PV guest receives these coordinates and passes them to the kernels
> > > evdev driver. There it can be picked up by applications such as the
> > > xorg-input drivers. Using absolute coordinates avoids issues such as
> > > guest mouse pointer not tracking host mouse pointer due to wrong mouse
> > > acceleration settings in the guests X display.
> > > 
> > > Advertise either absolute or relative coordinates to the input system
> > > and the evdev driver, depending on what dom0 provides. The xorg-input
> > > driver prefers relative coordinates even if a devices provides both.
> > 
> > So if I am reading this correctly the original version handled changes
> > in backend capabilities and could switch between delivering either
> > relative or absolute coordinates. The new version selects the
> > capabilities at boot time and sticks with them. Was it really the
> > intended behavior?
> 
> Yes, as mentioned in the description above, using absolute coordinates in
> the guests X11 is prefered because it avoids that the guest mouse
> pointer gets out of sync with the host/desktop mouse pointer.
> Very old Xen versions did not send absolute coordinates, but recent
> versions do.
> 

OK, as long as we have understanding that there is no concern with
migrating to a version of hypervisor that does not support absolute
coordinates reporting.

BTW, I believe the code should be rearranged a bit, like in the patch
below (this way we do not set up abs params if device works in relative
mode).

Thanks.

-- 
Dmitry

Input: xen-kbdfront - advertise either absolute or relative coordinates

From: Olaf Hering <olaf@xxxxxxxxx>

A virtualized display device is usually viewed with the vncviewer
application, either by 'xm vnc domU' or with vncviewer localhost:port.
vncviewer and the RFB protocol provides absolute coordinates to the
virtual display. These coordinates are either passed through to a PV
guest or converted to relative coordinates for a HVM guest.

A PV guest receives these coordinates and passes them to the kernels
evdev driver. There it can be picked up by applications such as the
xorg-input drivers. Using absolute coordinates avoids issues such as
guest mouse pointer not tracking host mouse pointer due to wrong mouse
acceleration settings in the guests X display.

Advertise either absolute or relative coordinates to the input system
and the evdev driver, depending on what dom0 provides. The xorg-input
driver prefers relative coordinates even if a devices provides both.

Signed-off-by: Olaf Hering <olaf@xxxxxxxxx>
Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Signed-off-by: Dmitry Torokhov <dtor@xxxxxxx>
---

 drivers/input/xen-kbdfront.c |   44 +++++++++++++++++++++++-------------------
 1 files changed, 24 insertions(+), 20 deletions(-)


diff --git a/drivers/input/xen-kbdfront.c b/drivers/input/xen-kbdfront.c
index 7f85a86..53e6273 100644
--- a/drivers/input/xen-kbdfront.c
+++ b/drivers/input/xen-kbdfront.c
@@ -110,7 +110,7 @@ static irqreturn_t input_handler(int rq, void *dev_id)
 static int __devinit xenkbd_probe(struct xenbus_device *dev,
                                  const struct xenbus_device_id *id)
 {
-       int ret, i;
+       int ret, i, abs;
        struct xenkbd_info *info;
        struct input_dev *kbd, *ptr;
 
@@ -128,6 +128,11 @@ static int __devinit xenkbd_probe(struct xenbus_device 
*dev,
        if (!info->page)
                goto error_nomem;
 
+       if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-abs-pointer", "%d", 
&abs) < 0)
+               abs = 0;
+       if (abs)
+               xenbus_printf(XBT_NIL, dev->nodename, "request-abs-pointer", 
"1");
+
        /* keyboard */
        kbd = input_allocate_device();
        if (!kbd)
@@ -137,11 +142,12 @@ static int __devinit xenkbd_probe(struct xenbus_device 
*dev,
        kbd->id.bustype = BUS_PCI;
        kbd->id.vendor = 0x5853;
        kbd->id.product = 0xffff;
-       kbd->evbit[0] = BIT(EV_KEY);
+
+       __set_bit(EV_KEY, kbd->evbit);
        for (i = KEY_ESC; i < KEY_UNKNOWN; i++)
-               set_bit(i, kbd->keybit);
+               __set_bit(i, kbd->keybit);
        for (i = KEY_OK; i < KEY_MAX; i++)
-               set_bit(i, kbd->keybit);
+               __set_bit(i, kbd->keybit);
 
        ret = input_register_device(kbd);
        if (ret) {
@@ -160,12 +166,20 @@ static int __devinit xenkbd_probe(struct xenbus_device 
*dev,
        ptr->id.bustype = BUS_PCI;
        ptr->id.vendor = 0x5853;
        ptr->id.product = 0xfffe;
-       ptr->evbit[0] = BIT(EV_KEY) | BIT(EV_REL) | BIT(EV_ABS);
+
+       if (abs) {
+               __set_bit(EV_ABS, ptr->evbit);
+               input_set_abs_params(ptr, ABS_X, 0, XENFB_WIDTH, 0, 0);
+               input_set_abs_params(ptr, ABS_Y, 0, XENFB_HEIGHT, 0, 0);
+       } else {
+               input_set_capability(ptr, EV_REL, REL_X);
+               input_set_capability(ptr, EV_REL, REL_Y);
+       }
+       input_set_capability(ptr, EV_REL, REL_WHEEL);
+
+       __set_bit(EV_KEY, ptr->evbit);
        for (i = BTN_LEFT; i <= BTN_TASK; i++)
-               set_bit(i, ptr->keybit);
-       ptr->relbit[0] = BIT(REL_X) | BIT(REL_Y) | BIT(REL_WHEEL);
-       input_set_abs_params(ptr, ABS_X, 0, XENFB_WIDTH, 0, 0);
-       input_set_abs_params(ptr, ABS_Y, 0, XENFB_HEIGHT, 0, 0);
+               __set_bit(i, ptr->keybit);
 
        ret = input_register_device(ptr);
        if (ret) {
@@ -272,7 +286,7 @@ static void xenkbd_backend_changed(struct xenbus_device 
*dev,
                                   enum xenbus_state backend_state)
 {
        struct xenkbd_info *info = dev_get_drvdata(&dev->dev);
-       int ret, val;
+       int val;
 
        switch (backend_state) {
        case XenbusStateInitialising:
@@ -285,16 +299,6 @@ static void xenkbd_backend_changed(struct xenbus_device 
*dev,
 
        case XenbusStateInitWait:
 InitWait:
-               ret = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
-                                  "feature-abs-pointer", "%d", &val);
-               if (ret < 0)
-                       val = 0;
-               if (val) {
-                       ret = xenbus_printf(XBT_NIL, info->xbdev->nodename,
-                                           "request-abs-pointer", "1");
-                       if (ret)
-                               pr_warning("can't request abs-pointer\n");
-               }
                xenbus_switch_state(dev, XenbusStateConnected);
                break;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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