On Thu, Apr 14, 2011 at 07:26:50PM +0200, Olaf Hering wrote:
> On Thu, Apr 14, Konrad Rzeszutek Wilk wrote:
>
> > 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
The patch rebase on top of 2.6.39-rc3 looks as so:
(and the patch is in git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/bug-fixes-rc3)
commit 876f162fe6831273fc5d678fa066f26f58be4a2c
Author: Igor Mammedov <[email protected]>
Date: Thu Apr 14 17:45:07 2011 +0200
Input: xen-kbdfront: Mouse stuck after save/restore of guest.
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
5ea5254aa0ad269cfbd2875c973ef25ab5b5e9db
("Input: xen-kbdfront - advertise either absolute or relative coordinates"
Driver on restore should ask xen for request-abs-pointer
again if it's available. So restore parts that did it
before 5ea5254.
CC: Dmitry Torokhov <[email protected]>
Acked-by: Olaf Hering <[email protected]>
Signed-off-by: Igor Mammedov <[email protected]>
[v1: Expanded the commit description]
Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
index 7077f9b..6d119d5 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;
On Thu, Apr 14, Konrad Rzeszutek Wilk wrote:
> On Thu, Apr 14, 2011 at 07:26:50PM +0200, Olaf Hering wrote:
> > On Thu, Apr 14, Konrad Rzeszutek Wilk wrote:
> >
> > > 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
Looking through my backlog, I noticed that the patch went also to
[email protected] and is now in various trees already.
So please forward this revert also to [email protected]
Olaf
> > 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
>
> Looking through my backlog, I noticed that the patch went also to
> [email protected] and is now in various trees already.
> So please forward this revert also to [email protected]
OK. The upstream git commit is c36b58e8a9112017c2bcc322cc98e71241814303.
Which stable tree did it go through? 2.6.38 only I presume?
On Tue, Apr 19, Konrad Rzeszutek Wilk wrote:
> > > 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
> >
> > Looking through my backlog, I noticed that the patch went also to
> > [email protected] and is now in various trees already.
> > So please forward this revert also to [email protected]
>
> OK. The upstream git commit is c36b58e8a9112017c2bcc322cc98e71241814303.
>
> Which stable tree did it go through? 2.6.38 only I presume?
All longterm versions, 2.6.32 and up.
Olaf
On 04/19/2011 04:55 PM, Olaf Hering wrote:
> On Tue, Apr 19, Konrad Rzeszutek Wilk wrote:
>
>>>> 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
>>> Looking through my backlog, I noticed that the patch went also to
>>> [email protected] and is now in various trees already.
>>> So please forward this revert also to [email protected]
>> OK. The upstream git commit is c36b58e8a9112017c2bcc322cc98e71241814303.
>>
>> Which stable tree did it go through? 2.6.38 only I presume?
> All longterm versions, 2.6.32 and up.
In Fedora 13 it still works (2.6.34.*)
> Olaf
>
> _______________________________________________
> Xen-devel mailing list
> [email protected]
> http://lists.xensource.com/xen-devel
> > > > 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 <[email protected]>
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 <[email protected]>
Signed-off-by: Igor Mammedov <[email protected]>
[v1: Expanded the commit description]
Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
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;
On Wed, Apr 20, Konrad Rzeszutek Wilk wrote:
> 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.
I checked which trees contain the broken commit from mainline:
broken stable trees:
2.6.38
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.38.y.git;a=commit;h=5ea5254aa0ad269cfbd2875c973ef25ab5b5e9db
2.6.37
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.37.y.git;a=commit;h=723517a796adf59f9ae628629fcb606c4cec8715
2.6.35
http://git.kernel.org/?p=linux/kernel/git/longterm/linux-2.6.35.y.git;a=commit;h=b88505e58ce6d36732cd15841cc821f97efca9bb
2.6.33
http://git.kernel.org/?p=linux/kernel/git/longterm/linux-2.6.33.y.git;a=commit;h=6997348a861d3540085bf9adf4166b86ac7a96e5
2.6.32
http://git.kernel.org/?p=linux/kernel/git/longterm/linux-2.6.32.y.git;a=commit;h=95e7148d08d0578687ea26cd3a8925aa5f7bc8fa
2.6.27
Does not have a variant of 8c3c283e6bf463ab498d6e7823aff6c4762314b6, yet.
So please apply upstream commit c36b58e8a9112017c2bcc322cc98e71241814303
to 2.6.38, 2.6.37, 2.6.35, 2.6.33 and 2.6.32 to fix the introduced
regression.
Thanks.
Olaf
On Wed, Apr 27, 2011 at 06:31:43PM +0200, Olaf Hering wrote:
> On Wed, Apr 20, Konrad Rzeszutek Wilk wrote:
>
> > 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.
>
> I checked which trees contain the broken commit from mainline:
>
> broken stable trees:
> 2.6.38
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.38.y.git;a=commit;h=5ea5254aa0ad269cfbd2875c973ef25ab5b5e9db
> 2.6.37
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.37.y.git;a=commit;h=723517a796adf59f9ae628629fcb606c4cec8715
> 2.6.35
> http://git.kernel.org/?p=linux/kernel/git/longterm/linux-2.6.35.y.git;a=commit;h=b88505e58ce6d36732cd15841cc821f97efca9bb
> 2.6.33
> http://git.kernel.org/?p=linux/kernel/git/longterm/linux-2.6.33.y.git;a=commit;h=6997348a861d3540085bf9adf4166b86ac7a96e5
> 2.6.32
> http://git.kernel.org/?p=linux/kernel/git/longterm/linux-2.6.32.y.git;a=commit;h=95e7148d08d0578687ea26cd3a8925aa5f7bc8fa
> 2.6.27
> Does not have a variant of 8c3c283e6bf463ab498d6e7823aff6c4762314b6, yet.
>
> So please apply upstream commit c36b58e8a9112017c2bcc322cc98e71241814303
> to 2.6.38, 2.6.37, 2.6.35, 2.6.33 and 2.6.32 to fix the introduced
> regression.
That commit fails to apply on the .38-stable tree, or anything else I
tried. Please provide a backported version if you wish to have it
applied.
Note that the .37-stable tree is now closed, so that doesn't matter
anymore.
thanks,
greg k-h