* 35022: hid-magicmouse broken @ 2011-05-17 12:40 Chase Douglas 2011-05-17 12:56 ` Jiri Kosina 0 siblings, 1 reply; 12+ messages in thread From: Chase Douglas @ 2011-05-17 12:40 UTC (permalink / raw) To: Jiri Kosina; +Cc: linux-input, Michael Poole, Dmitry Torokhov Hi Jiri, I've received a few emails about the magicmouse driver being broken on 2.6.39: https://bugzilla.kernel.org/show_bug.cgi?id=35022 It seems hid_output_raw_report() is returning a different (incorrect?) value than in the past. Do you know what might be going on? Thanks! -- Chase ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 35022: hid-magicmouse broken 2011-05-17 12:40 35022: hid-magicmouse broken Chase Douglas @ 2011-05-17 12:56 ` Jiri Kosina 2011-05-17 19:14 ` Chase Douglas 0 siblings, 1 reply; 12+ messages in thread From: Jiri Kosina @ 2011-05-17 12:56 UTC (permalink / raw) To: Chase Douglas; +Cc: linux-input, Michael Poole, Dmitry Torokhov, Alan Ott On Tue, 17 May 2011, Chase Douglas wrote: > Hi Jiri, > > I've received a few emails about the magicmouse driver being broken on > 2.6.39: > > https://bugzilla.kernel.org/show_bug.cgi?id=35022 > > It seems hid_output_raw_report() is returning a different (incorrect?) > value than in the past. Do you know what might be going on? So we are getting EIO from the transport-level _raw callback. Hmm, commit 0825411ade seems like a suspect here. Might be possible that magicmouse doesn't send ACK back, right? Could you please try reverting that commit and re-test? Adding Alan to CC. -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 35022: hid-magicmouse broken 2011-05-17 12:56 ` Jiri Kosina @ 2011-05-17 19:14 ` Chase Douglas 2011-05-19 11:59 ` Jiri Kosina 0 siblings, 1 reply; 12+ messages in thread From: Chase Douglas @ 2011-05-17 19:14 UTC (permalink / raw) To: Jiri Kosina; +Cc: linux-input, Michael Poole, Dmitry Torokhov, Alan Ott On 05/17/2011 08:56 AM, Jiri Kosina wrote: > On Tue, 17 May 2011, Chase Douglas wrote: > >> Hi Jiri, >> >> I've received a few emails about the magicmouse driver being broken on >> 2.6.39: >> >> https://bugzilla.kernel.org/show_bug.cgi?id=35022 >> >> It seems hid_output_raw_report() is returning a different (incorrect?) >> value than in the past. Do you know what might be going on? > > So we are getting EIO from the transport-level _raw callback. > > Hmm, commit 0825411ade seems like a suspect here. Might be possible that > magicmouse doesn't send ACK back, right? > > Could you please try reverting that commit and re-test? Yes, reverting that commit makes it work. I'm just speculating here, based on commit message names and what you've said, that the magicmouse is not protocol compliant because it is not sending an ACK back? What do you think we should do in the driver? Should we ignore the return, or should we look specifically for EIO? (neither sounds very good to me, so I'm hoping you have a better solution :). Thanks! -- Chase ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 35022: hid-magicmouse broken 2011-05-17 19:14 ` Chase Douglas @ 2011-05-19 11:59 ` Jiri Kosina 2011-05-19 13:13 ` Chase Douglas 0 siblings, 1 reply; 12+ messages in thread From: Jiri Kosina @ 2011-05-19 11:59 UTC (permalink / raw) To: Chase Douglas; +Cc: linux-input, Michael Poole, Dmitry Torokhov, Alan Ott On Tue, 17 May 2011, Chase Douglas wrote: > >> It seems hid_output_raw_report() is returning a different (incorrect?) > >> value than in the past. Do you know what might be going on? > > > > So we are getting EIO from the transport-level _raw callback. > > > > Hmm, commit 0825411ade seems like a suspect here. Might be possible that > > magicmouse doesn't send ACK back, right? > > > > Could you please try reverting that commit and re-test? > > Yes, reverting that commit makes it work. > > I'm just speculating here, based on commit message names and what you've > said, that the magicmouse is not protocol compliant because it is not > sending an ACK back? Yes, I believe that's what is happening. Could you please report what is the dmesg output with the patch below, just to make sure that we understand the situation precisely? > What do you think we should do in the driver? Should we ignore the > return, or should we look specifically for EIO? (neither sounds very > good to me, so I'm hoping you have a better solution :). Well if the device indeed doesn't send the ACK and it should (I will have to check the specs first), we'll have to put a quirk into the driver. Otherwise if the ACK is not mandatory, we'll have to revert that commit (or at least make it non-fatal failure). But I'll have to check the specs first. net/bluetooth/hidp/core.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c index 5ec1297..21025ed 100644 --- a/net/bluetooth/hidp/core.c +++ b/net/bluetooth/hidp/core.c @@ -403,6 +403,7 @@ static int hidp_output_raw_report(struct hid_device *hid, unsigned char *data, s struct hidp_session *session = hid->driver_data; int ret; + printk(KERN_DEBUG "hidp_output_raw_report, report_type: %d\n", report_type); switch (report_type) { case HID_FEATURE_REPORT: report_type = HIDP_TRANS_SET_REPORT | HIDP_DATA_RTYPE_FEATURE; @@ -434,6 +435,7 @@ static int hidp_output_raw_report(struct hid_device *hid, unsigned char *data, s 10*HZ); if (res == 0) { /* timeout */ + printk(KERN_DEBUG "hidp: returning -EIO because of timeout\n"); ret = -EIO; goto err; } @@ -445,6 +447,7 @@ static int hidp_output_raw_report(struct hid_device *hid, unsigned char *data, s } if (!session->output_report_success) { + printk(KERN_DEBUG "hidp: returnign -EIO because of !output_report_success\n"); ret = -EIO; goto err; } @@ -480,7 +483,7 @@ static inline void hidp_del_timer(struct hidp_session *session) static void hidp_process_handshake(struct hidp_session *session, unsigned char param) { - BT_DBG("session %p param 0x%02x", session, param); + printk(KERN_DEBUG "session %p param 0x%02x", session, param); session->output_report_success = 0; /* default condition */ switch (param) { -- Jiri Kosina SUSE Labs ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: 35022: hid-magicmouse broken 2011-05-19 11:59 ` Jiri Kosina @ 2011-05-19 13:13 ` Chase Douglas 2011-05-19 14:54 ` Jiri Kosina 0 siblings, 1 reply; 12+ messages in thread From: Chase Douglas @ 2011-05-19 13:13 UTC (permalink / raw) To: Jiri Kosina; +Cc: linux-input, Michael Poole, Dmitry Torokhov, Alan Ott On 05/19/2011 07:59 AM, Jiri Kosina wrote: > On Tue, 17 May 2011, Chase Douglas wrote: > >>>> It seems hid_output_raw_report() is returning a different (incorrect?) >>>> value than in the past. Do you know what might be going on? >>> >>> So we are getting EIO from the transport-level _raw callback. >>> >>> Hmm, commit 0825411ade seems like a suspect here. Might be possible that >>> magicmouse doesn't send ACK back, right? >>> >>> Could you please try reverting that commit and re-test? >> >> Yes, reverting that commit makes it work. >> >> I'm just speculating here, based on commit message names and what you've >> said, that the magicmouse is not protocol compliant because it is not >> sending an ACK back? > > Yes, I believe that's what is happening. Could you please report what is > the dmesg output with the patch below, just to make sure that we > understand the situation precisely? Here's the output in dmesg: [ 195.491735] Bluetooth: HIDP (Human Interface Emulation) ver 1.2 [ 222.693947] input: cndougla’s trackpad as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3.3/1-1.3.3:1.0/bluetooth/hci0/hci0:12/input16 [ 222.694119] magicmouse 0005:05AC:030E.0005: input,hidraw3: BLUETOOTH HID v1.60 Mouse [cndougla’s trackpad] on 50:63:13:90:AF:A4 [ 222.694128] hidp_output_raw_report, report_type: 2 [ 222.808111] session ffff88012d9b1200 param 0x02 [ 222.808198] hidp: returnign -EIO because of !output_report_success [ 222.808209] magicmouse 0005:05AC:030E.0005: unable to request touch data (-5) [ 222.809358] session ffff88012d9b1200 param 0x02 [ 222.810606] session ffff88012d9b1200 param 0x02 [ 222.813113] session ffff88012d9b1200 param 0x00 [ 223.045363] magicmouse: probe of 0005:05AC:030E.0005 failed with error -5 >> What do you think we should do in the driver? Should we ignore the >> return, or should we look specifically for EIO? (neither sounds very >> good to me, so I'm hoping you have a better solution :). > > Well if the device indeed doesn't send the ACK and it should (I will have > to check the specs first), we'll have to put a quirk into the driver. > Otherwise if the ACK is not mandatory, we'll have to revert that commit > (or at least make it non-fatal failure). > > But I'll have to check the specs first. Sounds good to me :). Thanks! -- Chase -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 35022: hid-magicmouse broken 2011-05-19 13:13 ` Chase Douglas @ 2011-05-19 14:54 ` Jiri Kosina 2011-05-19 15:40 ` Chase Douglas 0 siblings, 1 reply; 12+ messages in thread From: Jiri Kosina @ 2011-05-19 14:54 UTC (permalink / raw) To: Chase Douglas; +Cc: linux-input, Michael Poole, Dmitry Torokhov, Alan Ott On Thu, 19 May 2011, Chase Douglas wrote: > Here's the output in dmesg: > > [ 195.491735] Bluetooth: HIDP (Human Interface Emulation) ver 1.2 > [ 222.693947] input: cndougla’s trackpad as > /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3.3/1-1.3.3:1.0/bluetooth/hci0/hci0:12/input16 > [ 222.694119] magicmouse 0005:05AC:030E.0005: input,hidraw3: BLUETOOTH > HID v1.60 Mouse [cndougla’s trackpad] on 50:63:13:90:AF:A4 > [ 222.694128] hidp_output_raw_report, report_type: 2 > [ 222.808111] session ffff88012d9b1200 param 0x02 > [ 222.808198] hidp: returnign -EIO because of !output_report_success > [ 222.808209] magicmouse 0005:05AC:030E.0005: unable to request touch > data (-5) > [ 222.809358] session ffff88012d9b1200 param 0x02 > [ 222.810606] session ffff88012d9b1200 param 0x02 > [ 222.813113] session ffff88012d9b1200 param 0x00 > [ 223.045363] magicmouse: probe of 0005:05AC:030E.0005 failed with error -5 Ok, so what is happening here is that magicmouse_probe() sends the { 0xd7, 0x01 } feature report to the device, and it responds with HIDP_HSHK_ERR_INVALID_REPORT_ID. That's why the _raw callback (correctly) returns error. So the question to the driver authors is -- what is the point behind the { 0xd7, 0x01 } report? Clearly the device doesn't like it during probe because of invalid report ID. And it never did, we just silently ignored the error with the older kernels. Michael? -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 35022: hid-magicmouse broken 2011-05-19 14:54 ` Jiri Kosina @ 2011-05-19 15:40 ` Chase Douglas 2011-05-19 16:03 ` Jiri Kosina 0 siblings, 1 reply; 12+ messages in thread From: Chase Douglas @ 2011-05-19 15:40 UTC (permalink / raw) To: Jiri Kosina; +Cc: linux-input, Michael Poole, Dmitry Torokhov, Alan Ott On 05/19/2011 10:54 AM, Jiri Kosina wrote: > On Thu, 19 May 2011, Chase Douglas wrote: > >> Here's the output in dmesg: >> >> [ 195.491735] Bluetooth: HIDP (Human Interface Emulation) ver 1.2 >> [ 222.693947] input: cndougla’s trackpad as >> /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3.3/1-1.3.3:1.0/bluetooth/hci0/hci0:12/input16 >> [ 222.694119] magicmouse 0005:05AC:030E.0005: input,hidraw3: BLUETOOTH >> HID v1.60 Mouse [cndougla’s trackpad] on 50:63:13:90:AF:A4 >> [ 222.694128] hidp_output_raw_report, report_type: 2 >> [ 222.808111] session ffff88012d9b1200 param 0x02 >> [ 222.808198] hidp: returnign -EIO because of !output_report_success >> [ 222.808209] magicmouse 0005:05AC:030E.0005: unable to request touch >> data (-5) >> [ 222.809358] session ffff88012d9b1200 param 0x02 >> [ 222.810606] session ffff88012d9b1200 param 0x02 >> [ 222.813113] session ffff88012d9b1200 param 0x00 >> [ 223.045363] magicmouse: probe of 0005:05AC:030E.0005 failed with error -5 > > Ok, so what is happening here is that magicmouse_probe() sends the { 0xd7, > 0x01 } feature report to the device, and it responds with > HIDP_HSHK_ERR_INVALID_REPORT_ID. > > That's why the _raw callback (correctly) returns error. > > So the question to the driver authors is -- what is the point behind the { > 0xd7, 0x01 } report? Clearly the device doesn't like it during probe > because of invalid report ID. > And it never did, we just silently ignored the error with the older > kernels. The feature report is what flips the devices (magic mouse, magic trackpad) into multitouch mode. Without the report, the mouse will not emit the location of any touches on its surface, and the trackpad will only emit single touch data. What do you think we should do? We can't get rid of the report. Should we silently ignore the error? Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 35022: hid-magicmouse broken 2011-05-19 15:40 ` Chase Douglas @ 2011-05-19 16:03 ` Jiri Kosina 2011-05-19 18:03 ` Chase Douglas 0 siblings, 1 reply; 12+ messages in thread From: Jiri Kosina @ 2011-05-19 16:03 UTC (permalink / raw) To: Chase Douglas; +Cc: linux-input, Michael Poole, Dmitry Torokhov, Alan Ott On Thu, 19 May 2011, Chase Douglas wrote: > >> [ 195.491735] Bluetooth: HIDP (Human Interface Emulation) ver 1.2 > >> [ 222.693947] input: cndougla’s trackpad as > >> /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3.3/1-1.3.3:1.0/bluetooth/hci0/hci0:12/input16 > >> [ 222.694119] magicmouse 0005:05AC:030E.0005: input,hidraw3: BLUETOOTH > >> HID v1.60 Mouse [cndougla’s trackpad] on 50:63:13:90:AF:A4 > >> [ 222.694128] hidp_output_raw_report, report_type: 2 > >> [ 222.808111] session ffff88012d9b1200 param 0x02 > >> [ 222.808198] hidp: returnign -EIO because of !output_report_success > >> [ 222.808209] magicmouse 0005:05AC:030E.0005: unable to request touch > >> data (-5) > >> [ 222.809358] session ffff88012d9b1200 param 0x02 > >> [ 222.810606] session ffff88012d9b1200 param 0x02 > >> [ 222.813113] session ffff88012d9b1200 param 0x00 > >> [ 223.045363] magicmouse: probe of 0005:05AC:030E.0005 failed with error -5 > > > > Ok, so what is happening here is that magicmouse_probe() sends the { 0xd7, > > 0x01 } feature report to the device, and it responds with > > HIDP_HSHK_ERR_INVALID_REPORT_ID. > > > > That's why the _raw callback (correctly) returns error. > > > > So the question to the driver authors is -- what is the point behind the { > > 0xd7, 0x01 } report? Clearly the device doesn't like it during probe > > because of invalid report ID. > > And it never did, we just silently ignored the error with the older > > kernels. > > The feature report is what flips the devices (magic mouse, magic > trackpad) into multitouch mode. Without the report, the mouse will not > emit the location of any touches on its surface, and the trackpad will > only emit single touch data. > > What do you think we should do? We can't get rid of the report. Should > we silently ignore the error? Hmm, I am afraid that it's the only option (apart from thowing the whole 'waiting for ack' infrastructure away, which would be sad, as it's a good thing in principle). So how about the patch below? :/ Could you please verify that it makes hid-magicmouse work again? Thanks. From: Jiri Kosina <jkosina@suse.cz> Subject: [PATCH] HID: magicmouse: ignore 'ivalid report id' while switching modes The device reponds with 'invalid report id' when feature report switching it into multitouch mode is sent to it. This has been silently ignored before 0825411ade ("HID: bt: Wait for ACK on Sent Reports"), but since this commit, it propagates -EIO from the _raw callback . So let the driver ignore -EIO as response to 0xd7,0x01 report, as that's how the device reacts in normal mode. Sad, but following reality. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=35022 Signed-off-by: Jiri Kosina <jkosina@suse.cz> --- drivers/hid/hid-magicmouse.c | 10 +++++++++- 1 files changed, 9 insertions(+), 1 deletions(-) diff --git a/drivers/hid/hid-magicmouse.c b/drivers/hid/hid-magicmouse.c index 0ec91c1..a5eda4c 100644 --- a/drivers/hid/hid-magicmouse.c +++ b/drivers/hid/hid-magicmouse.c @@ -501,9 +501,17 @@ static int magicmouse_probe(struct hid_device *hdev, } report->size = 6; + /* + * The device reponds with 'invalid report id' when feature + * report switching it into multitouch mode is sent to it. + * + * This results in -EIO from the _raw low-level transport callback, + * but there seems to be no other way of switching the mode. + * Thus the super-ugly hacky success check below. + */ ret = hdev->hid_output_raw_report(hdev, feature, sizeof(feature), HID_FEATURE_REPORT); - if (ret != sizeof(feature)) { + if (ret != -EIO) { hid_err(hdev, "unable to request touch data (%d)\n", ret); goto err_stop_hw; } -- 1.7.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: 35022: hid-magicmouse broken 2011-05-19 16:03 ` Jiri Kosina @ 2011-05-19 18:03 ` Chase Douglas 2011-05-20 8:28 ` Jiri Kosina 0 siblings, 1 reply; 12+ messages in thread From: Chase Douglas @ 2011-05-19 18:03 UTC (permalink / raw) To: Jiri Kosina; +Cc: linux-input, Michael Poole, Dmitry Torokhov, Alan Ott On 05/19/2011 12:03 PM, Jiri Kosina wrote: > On Thu, 19 May 2011, Chase Douglas wrote: > >>>> [ 195.491735] Bluetooth: HIDP (Human Interface Emulation) ver 1.2 >>>> [ 222.693947] input: cndougla’s trackpad as >>>> /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3.3/1-1.3.3:1.0/bluetooth/hci0/hci0:12/input16 >>>> [ 222.694119] magicmouse 0005:05AC:030E.0005: input,hidraw3: BLUETOOTH >>>> HID v1.60 Mouse [cndougla’s trackpad] on 50:63:13:90:AF:A4 >>>> [ 222.694128] hidp_output_raw_report, report_type: 2 >>>> [ 222.808111] session ffff88012d9b1200 param 0x02 >>>> [ 222.808198] hidp: returnign -EIO because of !output_report_success >>>> [ 222.808209] magicmouse 0005:05AC:030E.0005: unable to request touch >>>> data (-5) >>>> [ 222.809358] session ffff88012d9b1200 param 0x02 >>>> [ 222.810606] session ffff88012d9b1200 param 0x02 >>>> [ 222.813113] session ffff88012d9b1200 param 0x00 >>>> [ 223.045363] magicmouse: probe of 0005:05AC:030E.0005 failed with error -5 >>> >>> Ok, so what is happening here is that magicmouse_probe() sends the { 0xd7, >>> 0x01 } feature report to the device, and it responds with >>> HIDP_HSHK_ERR_INVALID_REPORT_ID. >>> >>> That's why the _raw callback (correctly) returns error. >>> >>> So the question to the driver authors is -- what is the point behind the { >>> 0xd7, 0x01 } report? Clearly the device doesn't like it during probe >>> because of invalid report ID. >>> And it never did, we just silently ignored the error with the older >>> kernels. >> >> The feature report is what flips the devices (magic mouse, magic >> trackpad) into multitouch mode. Without the report, the mouse will not >> emit the location of any touches on its surface, and the trackpad will >> only emit single touch data. >> >> What do you think we should do? We can't get rid of the report. Should >> we silently ignore the error? > > Hmm, I am afraid that it's the only option (apart from thowing the whole > 'waiting for ack' infrastructure away, which would be sad, as it's a good > thing in principle). > > So how about the patch below? :/ Could you please verify that it makes > hid-magicmouse work again? Thanks. > > > > From: Jiri Kosina <jkosina@suse.cz> > Subject: [PATCH] HID: magicmouse: ignore 'ivalid report id' while switching modes > > The device reponds with 'invalid report id' when feature report switching it > into multitouch mode is sent to it. > > This has been silently ignored before 0825411ade ("HID: bt: Wait for ACK > on Sent Reports"), but since this commit, it propagates -EIO from the _raw > callback . > > So let the driver ignore -EIO as response to 0xd7,0x01 report, as that's > how the device reacts in normal mode. > > Sad, but following reality. > > This fixes https://bugzilla.kernel.org/show_bug.cgi?id=35022 > > Signed-off-by: Jiri Kosina <jkosina@suse.cz> > --- > drivers/hid/hid-magicmouse.c | 10 +++++++++- > 1 files changed, 9 insertions(+), 1 deletions(-) > > diff --git a/drivers/hid/hid-magicmouse.c b/drivers/hid/hid-magicmouse.c > index 0ec91c1..a5eda4c 100644 > --- a/drivers/hid/hid-magicmouse.c > +++ b/drivers/hid/hid-magicmouse.c > @@ -501,9 +501,17 @@ static int magicmouse_probe(struct hid_device *hdev, > } > report->size = 6; > > + /* > + * The device reponds with 'invalid report id' when feature > + * report switching it into multitouch mode is sent to it. > + * > + * This results in -EIO from the _raw low-level transport callback, > + * but there seems to be no other way of switching the mode. > + * Thus the super-ugly hacky success check below. > + */ > ret = hdev->hid_output_raw_report(hdev, feature, sizeof(feature), > HID_FEATURE_REPORT); > - if (ret != sizeof(feature)) { > + if (ret != -EIO) { > hid_err(hdev, "unable to request touch data (%d)\n", ret); > goto err_stop_hw; > } Seems to work for me :). Reviewed-by: Chase Douglas <chase.douglas@canonical.com> Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 35022: hid-magicmouse broken 2011-05-19 18:03 ` Chase Douglas @ 2011-05-20 8:28 ` Jiri Kosina 2011-05-20 13:04 ` Chase Douglas 0 siblings, 1 reply; 12+ messages in thread From: Jiri Kosina @ 2011-05-20 8:28 UTC (permalink / raw) To: Chase Douglas; +Cc: linux-input, Michael Poole, Dmitry Torokhov, Alan Ott On Thu, 19 May 2011, Chase Douglas wrote: > Seems to work for me :). I have applied the patch with your Tested-by. Thanks, -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 35022: hid-magicmouse broken 2011-05-20 8:28 ` Jiri Kosina @ 2011-05-20 13:04 ` Chase Douglas 2011-05-23 9:04 ` Jiri Kosina 0 siblings, 1 reply; 12+ messages in thread From: Chase Douglas @ 2011-05-20 13:04 UTC (permalink / raw) To: Jiri Kosina; +Cc: linux-input, Michael Poole, Dmitry Torokhov, Alan Ott On 05/20/2011 04:28 AM, Jiri Kosina wrote: > On Thu, 19 May 2011, Chase Douglas wrote: > >> Seems to work for me :). > > I have applied the patch with your Tested-by. Thanks, Thanks Jiri! Could you add 'Cc: stable@kernel.org' if it hasn't been merged yet? It looks like .39 was just released without this patch... ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 35022: hid-magicmouse broken 2011-05-20 13:04 ` Chase Douglas @ 2011-05-23 9:04 ` Jiri Kosina 0 siblings, 0 replies; 12+ messages in thread From: Jiri Kosina @ 2011-05-23 9:04 UTC (permalink / raw) To: Chase Douglas; +Cc: linux-input, Michael Poole, Dmitry Torokhov, Alan Ott On Fri, 20 May 2011, Chase Douglas wrote: > >> Seems to work for me :). > > > > I have applied the patch with your Tested-by. Thanks, > > Thanks Jiri! > > Could you add 'Cc: stable@kernel.org' if it hasn't been merged yet? It > looks like .39 was just released without this patch... I will be sending this patch to stable once it's in Linus tree (I will be sending pull request likely today). -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2011-05-23 9:04 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-05-17 12:40 35022: hid-magicmouse broken Chase Douglas 2011-05-17 12:56 ` Jiri Kosina 2011-05-17 19:14 ` Chase Douglas 2011-05-19 11:59 ` Jiri Kosina 2011-05-19 13:13 ` Chase Douglas 2011-05-19 14:54 ` Jiri Kosina 2011-05-19 15:40 ` Chase Douglas 2011-05-19 16:03 ` Jiri Kosina 2011-05-19 18:03 ` Chase Douglas 2011-05-20 8:28 ` Jiri Kosina 2011-05-20 13:04 ` Chase Douglas 2011-05-23 9:04 ` Jiri Kosina
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.