Skip to contentSkip to conversation

converting appletouch to usb autosuspend...

PATCH In review Soeren Sonnenburg 7 participants 16 messages May 12, 2007 – May 16, 2007

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

Dear all,

I've realized using the great powertop ( http://www.linuxpowertop.org/ ) that loading the appletouch driver (and touching it once) makes consumes about 0.3 W even when not touching the pad. As rmmod'ing appletouch fixes this I wonder why the driver does not do this alone. So my question is what does one have to do to convert a driver (such as appletouch) to make use of usb autosuspend except for

.supports_autosuspend = 1

...

While we are at it usb related powerhogs on this macbook pro are uhci_hcd (usb keyboard) and usb_hcd_poll_rh_status (rh_timer_func) too...

Soeren.

Signature · 2 lines
Sometimes, there's a moment as you're waking, when you become aware of
the real world around you, but you're still dreaming.
#1 lore raw
Quoted 10 lines · Soeren Sonnenburg

Dear all,

I've realized using the great powertop ( http://www.linuxpowertop.org/ ) that loading the appletouch driver (and touching it once) makes consumes about 0.3 W even when not touching the pad. As rmmod'ing appletouch fixes this I wonder why the driver does not do this alone. So my question is what does one have to do to convert a driver (such as appletouch) to make use of usb autosuspend except for

.supports_autosuspend = 1

One has to add appropriate calls to usb_autopm_get_interface() and usb_autopm_put_interface(), or equally well, to usb_autopm_enable() and usb_autopm_disable(). One might also need to set intf->needs_remote_wakeup to 1 in the probe routine.

Quoted 3 lines

While we are at it usb related powerhogs on this macbook pro are uhci_hcd (usb keyboard) and usb_hcd_poll_rh_status (rh_timer_func) too...

They would use less power if the UHCI host controller were suspended. But obviously it cannot be suspended while devices attached to it (such as the USB keyboard and the appletouch device) remain active.

Alan Stern

#2 lore raw
Quoted 6 lines · Alan Stern
Quoted 3 lines

While we are at it usb related powerhogs on this macbook pro are uhci_hcd (usb keyboard) and usb_hcd_poll_rh_status (rh_timer_func) too...

They would use less power if the UHCI host controller were suspended. But obviously it cannot be suspended while devices attached to it (such as the USB keyboard and the appletouch device) remain active.

A sidenote for completness, when this has been mentioned: Oliver has been working on autosuspend support for HID devices, he sent me some (yet incomplete) patches some time ago. So autosuspending of USB keyboards/mice/etc. is being worked on.

Oliver, do you have any update please?

Thanks,

Signature · 1 line
Jiri Kosina
#4 lore raw
In reply to Soeren Sonnenburg
Quoted 9 lines · On Saturday 12 May 2007 19:51:26 Soeren Sonnenburg wrote:

Dear all,

I've realized using the great powertop ( http://www.linuxpowertop.org/ ) that loading the appletouch driver (and touching it once) makes consumes about 0.3 W even when not touching the pad. As rmmod'ing appletouch fixes this I wonder why the driver does not do this alone. So my question is what does one have to do to convert a driver (such as appletouch) to make use of usb autosuspend except for

Quoted 7 lines

.supports_autosuspend = 1

...

While we are at it usb related powerhogs on this macbook pro are uhci_hcd (usb keyboard) and usb_hcd_poll_rh_status (rh_timer_func) too...

I've found that hci_usb also hogs power on the Macbook; blacklisting this module cuts down HZ considerably. I also found appletouch consumed ticks, just as you did.

uhci_hcd then drops to noise; my Macbook's sitting on 10W with the backlight on minimum, which is about what it can manage in OS X on maximum life settings.

Signature · 5 lines
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
#9 lore raw

PATCH 1/1 Make appletouch shut up when it has nothing to say

In reply to Soeren Sonnenburg

The appletouch devices found in the Intel Macs (and possibly some later PPC ones?) send a constant stream of packets after the first touch. This results in the kernel waking up around once every couple of milliseconds to process them, making it almost impossible to spend any significant period of time in C3 state on a dynamic HZ kernel. Sending the mode initialisation code makes the device shut up until it's touched again. This patch does so after receiving 10 packets with no interesting content.

drivers/input/mouse/appletouch.c +61 -1
index e321526..7931a76 100644
@@ -155,8 +155,12 @@ struct atp {
 	int			xy_acc[ATP_XSENSORS + ATP_YSENSORS];
 	int			overflowwarn;	/* overflow warning printed? */
 	int			datalen;	/* size of an USB urb transfer */
+	int                     idlecount;      /* number of empty packets */
+	struct work_struct      work;
 };
 
+static struct workqueue_struct *appletouch_wq;
+
 #define dbg_dump(msg, tab) \
 	if (debug > 1) {						\
 		int i;							\
@@ -208,6 +212,46 @@ static inline int atp_is_geyser_3(struct atp *dev)
 		(productId == GEYSER4_JIS_PRODUCT_ID);
 }
 
+/* Reinitialise the device if it's a geyser 3 */
+static void atp_reinit(struct work_struct *work)
+{
+	struct atp *dev = container_of(work, struct atp, work);
+	struct usb_device *udev = dev->udev;
+	char data[8];
+	int size;
+
+	if (!atp_is_geyser_3(dev))
+		return;
+
+	size = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
+			       ATP_GEYSER3_MODE_READ_REQUEST_ID,
+			       USB_DIR_IN | USB_TYPE_CLASS | USB_RECIP_INTERFACE,
+			       ATP_GEYSER3_MODE_REQUEST_VALUE,
+			       ATP_GEYSER3_MODE_REQUEST_INDEX, &data, 8, 5000);
+  
+	if (size != 8) {
+		err("Could not do mode read request from device"
+		    " (Geyser 3 mode)");
+		return;
+	}
+
+	/* Apply the mode switch */
+	data[0] = ATP_GEYSER3_MODE_VENDOR_VALUE;
+  
+	size = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
+			       ATP_GEYSER3_MODE_WRITE_REQUEST_ID,
+			       USB_DIR_OUT | USB_TYPE_CLASS | 
+			       USB_RECIP_INTERFACE,
+			       ATP_GEYSER3_MODE_REQUEST_VALUE,
+			       ATP_GEYSER3_MODE_REQUEST_INDEX, &data, 8, 5000);
+	
+	if (size != 8) {
+		err("Could not do mode write request to device"
+		    " (Geyser 3 mode)");
+		return;
+	}
+}
+
 static int atp_calculate_abs(int *xy_sensors, int nb_sensors, int fact,
 			     int *z, int *fingers)
 {
@@ -419,6 +463,7 @@ static void atp_complete(struct urb* urb)
 			      ATP_YFACT, &y_z, &y_f);
 
 	if (x && y) {
+		dev->idlecount = 0;
 		if (dev->x_old != -1) {
 			x = (dev->x_old * 3 + x) >> 2;
 			y = (dev->y_old * 3 + y) >> 2;
@@ -441,7 +486,7 @@ static void atp_complete(struct urb* urb)
 		dev->y_old = y;
 	}
 	else if (!x && !y) {
-
+		dev->idlecount++;
 		dev->x_old = dev->y_old = -1;
 		input_report_key(dev->input, BTN_TOUCH, 0);
 		input_report_abs(dev->input, ABS_PRESSURE, 0);
@@ -449,6 +494,13 @@ static void atp_complete(struct urb* urb)
 
 		/* reset the accumulator on release */
 		memset(dev->xy_acc, 0, sizeof(dev->xy_acc));
+
+		/* 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 (dev->idlecount >= 10)
+			queue_work (appletouch_wq, &dev->work);
 	}
 
 	input_report_key(dev->input, BTN_LEFT,
@@ -636,6 +688,8 @@ static int atp_probe(struct usb_interface *iface, const struct usb_device_id *id
 	/* save our data pointer in this interface device */
 	usb_set_intfdata(iface, dev);
 
+        INIT_WORK(&dev->work, atp_reinit);
+
 	return 0;
 
  err_free_buffer:
@@ -694,12 +748,18 @@ static struct usb_driver atp_driver = {
 
 static int __init atp_init(void)
 {
+	appletouch_wq = create_singlethread_workqueue("kappletouch");
+	if (!appletouch_wq) {
+		printk(KERN_ERR "appletouch: failed to create workqueue\n");
+		return -ENOMEM;
+	}
 	return usb_register(&atp_driver);
 }
 
 static void __exit atp_exit(void)
 {
 	usb_deregister(&atp_driver);
+	destroy_workqueue(appletouch_wq);
 }
 
 module_init(atp_init);
Signature · 1 line
Matthew Garrett | [email protected]
#10 lore raw

Re: [PATCH] Make appletouch shut up when it has nothing to say

drivers/input/mouse/appletouch.c static inline int atp_is_geyser_3(struct atp *dev) · line 230

Quoted 8 lines · Matthew Garrett
drivers/input/mouse/appletouch.c +8 -0
+static void atp_reinit(struct work_struct *work)
+{
+	char data[8];
+	size = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
+			       ATP_GEYSER3_MODE_READ_REQUEST_ID,
+			       USB_DIR_IN | USB_TYPE_CLASS | USB_RECIP_INTERFACE,
+			       ATP_GEYSER3_MODE_REQUEST_VALUE,
+			       ATP_GEYSER3_MODE_REQUEST_INDEX, &data, 8, 5000);

Generally speaking, DMA-ing from stack is not allowed. Maybe you want to add a comment saying "buffer on stack because this is Mac-only driver". I would not ask for kmalloc here which is entirely pointless.

drivers/input/mouse/appletouch.c static void atp_complete(struct urb* urb) · line 503

Quoted 7 lines
drivers/input/mouse/appletouch.c +7 -0
+
+		/* 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 (dev->idlecount >= 10)
+			queue_work (appletouch_wq, &dev->work);

So, why don't you check for Geyser 3 or whatnot here instead of doing it inside the work function? Why poking workqueue on other systems?

drivers/input/mouse/appletouch.c static struct usb_driver atp_driver = { · line 756

Quoted 6 lines
drivers/input/mouse/appletouch.c +5 -0
+	appletouch_wq = create_singlethread_workqueue("kappletouch");
+	if (!appletouch_wq) {
+		printk(KERN_ERR "appletouch: failed to create workqueue\n");
+		return -ENOMEM;
+	}
 	return usb_register(&atp_driver);

I'm wondering about the wisdom of this too. Why won't the stock workqueue work? We have way too many daemons already. Plus, making one more unconditionally regardless of hardware present seems like stepping over the line to me.

Overall this seems like a good patch to me, only needs to be less intrusive for owners of other hardware.

-- Pete

#11 lore raw

Re: [PATCH] Make appletouch shut up when it has nothing to say

Ok, I've tidied this up a little. I've separated the actual mode init code into a separate function in order to avoid code duplication, and no longer creating a new workqueue. The only other change is something that I /think/ is actually a bug in the driver to begin with, but I'd like some more feedback on that first - the first packet sent after the mode change has 0x20 in the final byte. This seems to be interpreted as a left mouse button press. As a result, moving the touchpad sends a false press after every reinitialisation, or (approximately) every time the pointer is moved. As far as I can tell this also happens with the existing code, but is probably not noticable there because it won't appear again after the first touch on the pad. Just skipping that case seems to work fine.

drivers/input/mouse/appletouch.c +63 -30
index e321526..f126de8 100644
@@ -155,6 +155,8 @@ struct atp {
 	int			xy_acc[ATP_XSENSORS + ATP_YSENSORS];
 	int			overflowwarn;	/* overflow warning printed? */
 	int			datalen;	/* size of an USB urb transfer */
+	int                     idlecount;      /* number of empty packets */
+	struct work_struct      work;
 };
 
 #define dbg_dump(msg, tab) \
@@ -208,6 +210,51 @@ static inline int atp_is_geyser_3(struct atp *dev)
 		(productId == GEYSER4_JIS_PRODUCT_ID);
 }
 
+static int atp_geyser3_init(struct usb_device *udev)
+{
+	char data[8];
+	int size;
+
+	size = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
+			       ATP_GEYSER3_MODE_READ_REQUEST_ID,
+			       USB_DIR_IN | USB_TYPE_CLASS | USB_RECIP_INTERFACE,
+			       ATP_GEYSER3_MODE_REQUEST_VALUE,
+			       ATP_GEYSER3_MODE_REQUEST_INDEX, &data, 8, 5000);
+  
+	if (size != 8) {
+		err("Could not do mode read request from device"
+		    " (Geyser 3 mode)");
+		return -EIO;
+	}
+
+	/* Apply the mode switch */
+	data[0] = ATP_GEYSER3_MODE_VENDOR_VALUE;
+  
+	size = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
+			       ATP_GEYSER3_MODE_WRITE_REQUEST_ID,
+			       USB_DIR_OUT | USB_TYPE_CLASS | 
+			       USB_RECIP_INTERFACE,
+			       ATP_GEYSER3_MODE_REQUEST_VALUE,
+			       ATP_GEYSER3_MODE_REQUEST_INDEX, &data, 8, 5000);
+	
+	if (size != 8) {
+		err("Could not do mode write request to device"
+		    " (Geyser 3 mode)");
+		return -EIO;
+	}
+	return 0;
+}
+
+/* Reinitialise the device if it's a geyser 3 */
+static void atp_reinit(struct work_struct *work)
+{
+	struct atp *dev = container_of(work, struct atp, work);
+	struct usb_device *udev = dev->udev;
+
+	dev->idlecount = 0;
+	atp_geyser3_init(udev);
+}
+
 static int atp_calculate_abs(int *xy_sensors, int nb_sensors, int fact,
 			     int *z, int *fingers)
 {
@@ -441,7 +488,6 @@ static void atp_complete(struct urb* urb)
 		dev->y_old = y;
 	}
 	else if (!x && !y) {
-
 		dev->x_old = dev->y_old = -1;
 		input_report_key(dev->input, BTN_TOUCH, 0);
 		input_report_abs(dev->input, ABS_PRESSURE, 0);
@@ -449,10 +495,21 @@ static void atp_complete(struct urb* urb)
 
 		/* reset the accumulator on release */
 		memset(dev->xy_acc, 0, sizeof(dev->xy_acc));
+
+		/* 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 (atp_is_geyser_3(dev)) {
+			dev->idlecount++;
+			if (dev->idlecount == 10)
+				schedule_work (&dev->work);
+		}
 	}
 
-	input_report_key(dev->input, BTN_LEFT,
-			 !!dev->data[dev->datalen - 1]);
+	if (dev->data[dev->datalen-1] != 20) 
+		input_report_key(dev->input, BTN_LEFT,
+				 !!dev->data[dev->datalen - 1]);
 
 	input_sync(dev->input);
 
@@ -533,35 +590,9 @@ static int atp_probe(struct usb_interface *iface, const struct usb_device_id *id
 		 * packets (Report ID 2). This code changes device mode, so it
 		 * sends raw sensor reports (Report ID 5).
 		 */
-		char data[8];
-		int size;
-
-		size = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
-			ATP_GEYSER3_MODE_READ_REQUEST_ID,
-			USB_DIR_IN | USB_TYPE_CLASS | USB_RECIP_INTERFACE,
-			ATP_GEYSER3_MODE_REQUEST_VALUE,
-			ATP_GEYSER3_MODE_REQUEST_INDEX, &data, 8, 5000);
-
-		if (size != 8) {
-			err("Could not do mode read request from device"
-							" (Geyser 3 mode)");
+		if (atp_geyser3_init(udev))
 			goto err_free_devs;
-		}
 
-		/* Apply the mode switch */
-		data[0] = ATP_GEYSER3_MODE_VENDOR_VALUE;
-
-		size = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
-			ATP_GEYSER3_MODE_WRITE_REQUEST_ID,
-			USB_DIR_OUT | USB_TYPE_CLASS | USB_RECIP_INTERFACE,
-			ATP_GEYSER3_MODE_REQUEST_VALUE,
-			ATP_GEYSER3_MODE_REQUEST_INDEX, &data, 8, 5000);
-
-		if (size != 8) {
-			err("Could not do mode write request to device"
-							" (Geyser 3 mode)");
-			goto err_free_devs;
-		}
 		printk("appletouch Geyser 3 inited.\n");
 	}
 
@@ -636,6 +667,8 @@ static int atp_probe(struct usb_interface *iface, const struct usb_device_id *id
 	/* save our data pointer in this interface device */
 	usb_set_intfdata(iface, dev);
 
+        INIT_WORK(&dev->work, atp_reinit);
+
 	return 0;
 
  err_free_buffer:
Signature · 1 line
Matthew Garrett | [email protected]
#12 lore raw

Re: [PATCH] Make appletouch shut up when it has nothing to say

Quoted 4 lines · Matthew Garrett

Ok, I've tidied this up a little. I've separated the actual mode init code into a separate function in order to avoid code duplication, and no longer creating a new workqueue. The only other change is something that I /think/ is actually a bug in the driver to begin with, but I'd like

Quoted 8 lines

some more feedback on that first - the first packet sent after the mode change has 0x20 in the final byte. This seems to be interpreted as a left mouse button press. As a result, moving the touchpad sends a false press after every reinitialisation, or (approximately) every time the pointer is moved. As far as I can tell this also happens with the existing code, but is probably not noticable there because it won't appear again after the first touch on the pad. Just skipping that case seems to work fine.

This patch indeed fixes the problem and I have yet to observe problems with it... However I don't know whether a re-init is the intended way of dealing with it...

Soeren

Signature · 2 lines
Sometimes, there's a moment as you're waking, when you become aware of
the real world around you, but you're still dreaming.
#5 lore raw
In reply to Alistair John Strachan
Quoted 2 lines · Alistair John Strachan
Quoted 1 line · On Saturday 12 May 2007 19:51:26 Soeren Sonnenburg wrote:

Dear all,

[...]

Quoted 6 lines
Quoted 3 lines

While we are at it usb related powerhogs on this macbook pro are uhci_hcd (usb keyboard) and usb_hcd_poll_rh_status (rh_timer_func) too...

I've found that hci_usb also hogs power on the Macbook; blacklisting this module cuts down HZ considerably. I also found appletouch consumed ticks,

I guess without loading appletouch ? Then there really is something in there that needs to be fixed..

Quoted 1 line

just as you did.

What did you use instead of hci_usb then ? usbkbd ? This won't give you the special keys etc...

Quoted 3 lines

uhci_hcd then drops to noise; my Macbook's sitting on 10W with the backlight on minimum, which is about what it can manage in OS X on maximum life settings.

Thats quite some improvement...

Soeren.

Signature · 2 lines
Sometimes, there's a moment as you're waking, when you become aware of
the real world around you, but you're still dreaming.
#6 lore raw
Quoted 13 lines · On Monday 14 May 2007 01:46:10 Soeren Sonnenburg wrote:
Quoted 2 lines · Alistair John Strachan
Quoted 1 line · On Saturday 12 May 2007 19:51:26 Soeren Sonnenburg wrote:

Dear all,

[...]

Quoted 6 lines
Quoted 3 lines

While we are at it usb related powerhogs on this macbook pro are uhci_hcd (usb keyboard) and usb_hcd_poll_rh_status (rh_timer_func) too...

I've found that hci_usb also hogs power on the Macbook; blacklisting this module cuts down HZ considerably. I also found appletouch consumed ticks,

Quoted 7 lines

I guess without loading appletouch ? Then there really is something in there that needs to be fixed..

Quoted 1 line

just as you did.

What did you use instead of hci_usb then ? usbkbd ? This won't give you the special keys etc...

Sorry, I wasn't clear. hci_usb is actually part of the BlueZ stack, it's got nothing to do with the keyboard. I unloaded both appletouch AND hci_usb.

Quoted 5 lines
Quoted 3 lines

uhci_hcd then drops to noise; my Macbook's sitting on 10W with the backlight on minimum, which is about what it can manage in OS X on maximum life settings.

Thats quite some improvement...

Yes indeed. The only thing left to improve, as I understand it, is enabling the C4/C4e power states available on the Core 2 Duo, which don't currently seem to be utilised by Linux. I notice, however, that the screenshot on the Intel Powertop page does seem to have these states available?

Signature · 5 lines
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
#13 lore raw

Re: [PATCH] Make appletouch shut up when it has nothing to say

In reply to Matthew Garrett
Quoted 1 line · Matthew Garrett

Ok, I've tidied this up a little. [...]

Looks fine here... well, almost. Did you try rmmod (I don't even know if it's applicable, sorry)? Usually, when schedule_work is involved, you want to make sure that a scheduled work won't be run when the module is gone. More often, a device removal is the issue, but as I take it, such is not possible for a built-in device :-) . In most cases, all it takes is a strategically placed flush_scheduled_work().

-- Pete

#7 lore raw
In reply to Alistair John Strachan

Am Montag, 14. Mai 2007 02:53 schrieb Alistair John Strachan:

Quoted 5 lines
Quoted 2 lines

What did you use instead of hci_usb then ? usbkbd ? This won't give you the special keys etc...

Sorry, I wasn't clear. hci_usb is actually part of the BlueZ stack, it's got nothing to do with the keyboard. I unloaded both appletouch AND hci_usb.

If you want large power savings from USB autosuspend, all loaded drivers must support autosuspend. The HCD can suspend only if all connected devices are suspended.
Are you willing to test patches for HID & the new last_busy based usb core infrastructure?

Regards
Oliver

#3 lore raw
In reply to Jiri Kosina

Am Samstag, 12. Mai 2007 23:40 schrieb Jiri Kosina:

Quoted 1 line

Oliver, do you have any update please?

Not yet. You can have them tomorrow.

Regards
Oliver

#8 lore raw
In reply to Oliver Neukum
Quoted 8 lines · On Monday 14 May 2007 06:50:39 Oliver Neukum wrote:

Am Montag, 14. Mai 2007 02:53 schrieb Alistair John Strachan:

Quoted 6 lines
Quoted 2 lines

What did you use instead of hci_usb then ? usbkbd ? This won't give you the special keys etc...

Sorry, I wasn't clear. hci_usb is actually part of the BlueZ stack, it's got nothing to do with the keyboard. I unloaded both appletouch AND hci_usb.

Quoted 5 lines

If you want large power savings from USB autosuspend, all loaded drivers must support autosuspend. The HCD can suspend only if all connected devices are suspended.
Are you willing to test patches for HID & the new last_busy based usb core infrastructure?

Of course.

Signature · 5 lines
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
#14 lore raw

Re: [PATCH] Make appletouch shut up when it has nothing to say

In reply to Pete Zaitcev
Quoted 10 lines · Pete Zaitcev
Quoted 1 line · Matthew Garrett

Ok, I've tidied this up a little. [...]

Looks fine here... well, almost. Did you try rmmod (I don't even know if it's applicable, sorry)? Usually, when schedule_work is involved, you want to make sure that a scheduled work won't be run when the module is gone. More often, a device removal is the issue, but as I take it, such is not possible for a built-in device :-) . In most cases, all it takes is a strategically placed flush_scheduled_work().

I was using this patch for some days now and I realized that - from time to time - the touchpad runs amok, i.e. I more or less unable to control the mouse when that happens.

Then a rmmod appletouch (+ reload) fixes this, as well as a sleep/resume cycle.

As I had to rmmod appletouch a lot and did not see crashes I think it works... though this problem persists...

Soeren

Signature · 2 lines
Sometimes, there's a moment as you're waking, when you become aware of
the real world around you, but you're still dreaming.
#15 lore raw

Re: [PATCH] Make appletouch shut up when it has nothing to say

Quoted 3 lines · Soeren Sonnenburg

I was using this patch for some days now and I realized that - from time to time - the touchpad runs amok, i.e. I more or less unable to control the mouse when that happens.

Hmm. Just seen this. I'll see if I can work around that.

Signature · 1 line
Matthew Garrett | [email protected]