On Thu, Aug 23, 2012 at 09:14:37AM -0400, Matt Whitlock wrote:
(Sorry. Sent from the wrong account. Resending...)
On Thursday, 23 August 2012, at 10:58 am, Daniel Stone wrote:
On 23 August 2012 08:40, Peter Hutterer peter.hutte...@who-t.net wrote:
On Mon, Aug 13, 2012 at 05:47:12PM
Hi Matt,
sorry about the delay, bit swamped here.
On Mon, Aug 13, 2012 at 05:47:12PM -0400, Matt Whitlock wrote:
This patch adds one configuration option, DebounceDelay, and one XInput
property, Evdev Debounce Delay. They refer to the amount of time to wait
after receiving a mouse button
Hi,
On 23 August 2012 08:40, Peter Hutterer peter.hutte...@who-t.net wrote:
On Mon, Aug 13, 2012 at 05:47:12PM -0400, Matt Whitlock wrote:
This patch adds one configuration option, DebounceDelay, and one XInput
property, Evdev Debounce Delay. They refer to the amount of time to wait
after
(Sorry. Sent from the wrong account. Resending...)
On Thursday, 23 August 2012, at 10:58 am, Daniel Stone wrote:
On 23 August 2012 08:40, Peter Hutterer peter.hutte...@who-t.net wrote:
On Mon, Aug 13, 2012 at 05:47:12PM -0400, Matt Whitlock wrote:
This patch adds one configuration option,
On 23 August 2012 15:14, Matt Whitlock freedesk...@mattwhitlock.name wrote:
I have an expensive wireless laser mouse. The battery is still in great
condition, but the buttons are wearing out due to heavy use. Why should I
buy a new mouse when I can easily correct for the hardware in
I submitted this patch a couple of weeks ago but didn't get a reply (maybe
because I omitted the evdev label from the subject line). So here it is
again, now rebased atop 5af11b6 (latest on master).
Note that Daniel Stone said on 11 March 2008: IMO this should be kernelside,
though it's
This patch adds one configuration option, DebounceDelay, and one XInput
property, Evdev Debounce Delay. They refer to the amount of time to wait
after receiving a mouse button release event from the kernel before posting
the event to the X server. If a mouse button pressed event is received before