Re: [Xen-devel] [PATCH] [PV Xen] Mouse stuck after save/restore of guest. - stable tree candidate.

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

[-- Attachment #1: Type: text/plain, Size: 3645 bytes --]

> > > > On Thu, Apr 14, 2011 at 05:45:07PM +0200, Igor Mammedov wrote:
> > > > >     Mouse stuck after restore of PV guest but buttons are
> > > > >     in working condition.
> > > > >     If driver has been configured for ABS coordinates at
> > > > >     start it will get XENKBD_TYPE_POS events and then
> > > > >     suddenly after restore it'll start getting
> > > > >     XENKBD_TYPE_MOTION events, that will be dropped later
> > > > >     and they won't get into user-space.
> > > > > 
> > > > >     Regression was introduced by hunk 5 and 6 of 5ea5254
> > > > >     in upstream.
> > > > > 
> > > > >     Driver on restore should ask xen for request-abs-pointer
> > > > >     again if it's available. So restore parts that did it 
> > > > >     before 5ea5254.
> > > > 
> > > > Olaf?
> > > 
> > > This change is correct. Thanks for spotting, Igor.
> > 
> > Dmitry,
> > 
> > Was wondering if you are OK pushing this for 2.6.39-rc3 or whether you are OK
> > with me doing. It fixes a regression introduced by the last hunk of 
> > 5ea5254aa0ad269cfbd2875c973ef25ab5b5e9db

Hello stable-tree maintainers.

Please apply the upstream git commit c36b58e8a9112017c2bcc322cc98e71241814303
(Input: xen-kbdfront - fix mouse getting stuck after save/restore)
which fixes a regression introduced by 8c3c283e6bf463ab498d6e7823aff6c4762314b6
(Input: xen-kbdfront - advertise either absolute or relative coordinates)

The 2.6.38 and 2.6.37 tree both contain the regression.

For convience, attached and inline is the patch for stable tree submission.

commit c36b58e8a9112017c2bcc322cc98e71241814303
Author: Igor Mammedov <imammedo@redhat.com>
Date:   Mon Apr 18 10:17:17 2011 -0700

    Input: xen-kbdfront - fix mouse getting stuck after save/restore
    
    Mouse gets "stuck" after restore of PV guest but buttons are in working
    condition.
    
    If driver has been configured for ABS coordinates at start it will get
    XENKBD_TYPE_POS events and then suddenly after restore it'll start getting
    XENKBD_TYPE_MOTION events, that will be dropped later and they won't get
    into user-space.
    
    Regression was introduced by hunk 5 and 6 of
    5ea5254aa0ad269cfbd2875c973ef25ab5b5e9db
    ("Input: xen-kbdfront - advertise either absolute or relative
    coordinates").
    
    Driver on restore should ask xen for request-abs-pointer again if it is
    available. So restore parts that did it before 5ea5254.
    
    Acked-by: Olaf Hering <olaf@aepfle.de>
    Signed-off-by: Igor Mammedov <imammedo@redhat.com>
    [v1: Expanded the commit description]
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Dmitry Torokhov <dtor@mail.ru>

diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
index 7077f9b..62bae99 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -303,7 +303,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 val;
+	int ret, val;
 
 	switch (backend_state) {
 	case XenbusStateInitialising:
@@ -316,6 +316,17 @@ 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("xenkbd: can't request abs-pointer");
+		}
+
 		xenbus_switch_state(dev, XenbusStateConnected);
 		break;
 

[-- Attachment #2: c36b58e8a9112017c2bcc322cc98e71241814303.patch --]
[-- Type: text/x-diff, Size: 2102 bytes --]

commit c36b58e8a9112017c2bcc322cc98e71241814303
Author: Igor Mammedov <imammedo@redhat.com>
Date:   Mon Apr 18 10:17:17 2011 -0700

    Input: xen-kbdfront - fix mouse getting stuck after save/restore
    
    Mouse gets "stuck" after restore of PV guest but buttons are in working
    condition.
    
    If driver has been configured for ABS coordinates at start it will get
    XENKBD_TYPE_POS events and then suddenly after restore it'll start getting
    XENKBD_TYPE_MOTION events, that will be dropped later and they won't get
    into user-space.
    
    Regression was introduced by hunk 5 and 6 of
    5ea5254aa0ad269cfbd2875c973ef25ab5b5e9db
    ("Input: xen-kbdfront - advertise either absolute or relative
    coordinates").
    
    Driver on restore should ask xen for request-abs-pointer again if it is
    available. So restore parts that did it before 5ea5254.
    
    Acked-by: Olaf Hering <olaf@aepfle.de>
    Signed-off-by: Igor Mammedov <imammedo@redhat.com>
    [v1: Expanded the commit description]
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Dmitry Torokhov <dtor@mail.ru>

diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
index 7077f9b..62bae99 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -303,7 +303,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 val;
+	int ret, val;
 
 	switch (backend_state) {
 	case XenbusStateInitialising:
@@ -316,6 +316,17 @@ 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("xenkbd: can't request abs-pointer");
+		}
+
 		xenbus_switch_state(dev, XenbusStateConnected);
 		break;