The patch 46249ea60fbb61a72ee6929b831b1f3e6865f024 was obviously done
without testing on a Geyser 1, and I'm a very annoyed that it was
applied. It causes appletouch to continuously printk:
drivers/input/mouse/appletouch.c: Could not do mode read request from device
(Geyser 3 mode)
because the Geyser 1 doesn't respond to that. The patch description also
states:
> if we see 10 empty packets the touchpad needs to be reset; good
> touchpads should not send empty packets anyway.
which is *TOTALLY* bogus since Geyser 1 touchpads have no notion of
empty packets, the simply continuously send measurements. One look at
the specification would have confirmed that.
This reverts the clueless commit.
Signed-off-by: Johannes Berg <[EMAIL PROTECTED]>
---
--- linux-2.6.orig/drivers/input/mouse/appletouch.c 2007-10-24
12:37:39.140210069 +0200
+++ linux-2.6/drivers/input/mouse/appletouch.c 2007-10-24 12:37:50.000215820
+0200
@@ -504,22 +504,25 @@ static void atp_complete(struct urb* urb
memset(dev->xy_acc, 0, sizeof(dev->xy_acc));
}
- input_report_key(dev->input, BTN_LEFT, key);
- input_sync(dev->input);
-
- /* Many Geysers will continue to send packets continually after
+ /* Geyser 3 will continue to send packets continually after
the first touch unless reinitialised. Do so if it's been
idle for a while in order to avoid waking the kernel up
several hundred times a second */
- if (!x && !y && !key) {
- dev->idlecount++;
- if (dev->idlecount == 10) {
- dev->valid = 0;
- schedule_work(&dev->work);
+ if (atp_is_geyser_3(dev)) {
+ if (!x && !y && !key) {
+ dev->idlecount++;
+ if (dev->idlecount == 10) {
+ dev->valid = 0;
+ schedule_work(&dev->work);
+ }
}
- } else
- dev->idlecount = 0;
+ else
+ dev->idlecount = 0;
+ }
+
+ input_report_key(dev->input, BTN_LEFT, key);
+ input_sync(dev->input);
exit:
retval = usb_submit_urb(dev->urb, GFP_ATOMIC);
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
