Input: Add driver for Microchip's CAP1106
Subsystems (3)
PATCH v2 1/1 Input: Add driver for Microchip's CAP1106
This patch adds a driver for Microchips CAP1106, an I2C driven, 6-channel capacitive touch sensor.
For now, only the capacitive buttons are supported, and no specific settings that can be tweaked for individual channels, except for the device-wide sensitivity gain. The defaults seem to work just fine out of the box, so I'll leave configurable parameters for someone who's in need of them and who can actually measure the impact. All registers are prepared, however. Many of them are just not used for now.
The implementation does not make any attempt to be compatible to platform data driven boards, but fully depends on CONFIG_OF.
Power management functions are also left for volounteers with the ability to actually test them.
---
v2:
* Fix potential deadlocks pointed out by David.
.../devicetree/bindings/input/cap1106.txt | 63 ++++ drivers/input/keyboard/Kconfig | 10 + drivers/input/keyboard/Makefile | 1 + drivers/input/keyboard/cap1106.c | 378 +++++++++++++++++++++ 4 files changed, 452 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/cap1106.txt create mode 100644 drivers/input/keyboard/cap1106.c
Documentation/devicetree/bindings/input/cap1106.txt new file +63 -0
@@ -0,0 +1,63 @@ +Device tree bindings for Microchip CAP1106, 6 channel capacitive touch sensor + +The node for this driver must be a child of a I2C controller node, as the +device communication via I2C only. + +Required properties: + + compatible: Must be "microchip,cap1106" + reg: The I2C slave address of the device. + Only 0x28 is valid. + interrupt: Node describing the interrupt line the device's + ALERT#/CM_IRQ# pin is connected to. + +Optional properties: + + autorepeat: Enables the Linux input system's autorepeat + feature on the input device. + microchip,sensor-gain: Defines the gain of the sensor circuitry. This + effectively controls the sensitivity, as a + smaller delta capacitance is required to + generate the same delta count values. + Valid values are 1, 2, 4, and 8. + By default, a gain of 1 is set. + +To define details of each individual button channel, six subnodes can be +specified. Inside each of those, the following property is valid: + + linux,keycode: Specify the numeric identifier of the keycode to be + generated when this channel is activated. If this + property is omitted, KEY_A, KEY_B, etc are used as + defaults. + +Example: + +i2c_controller { + cap1106@28 { + compatible = "microchip,cap1106"; + interrupt-parent = <&gpio1>; + interrupts = <0 0>; + reg = <0x28>; + autorepeat; + microchip,sensor-gain = <2>; + + up { + linux,keycode = <103>; /* KEY_UP */ + }; + right { + linux,keycode = <106>; /* KEY_RIGHT */ + }; + down { + linux,keycode = <108>; /* KEY_DOWN */ + }; + left { + linux,keycode = <105>; /* KEY_LEFT */ + }; + pagedown { + linux,keycode = <109>; /* KEY_PAGEDOWN */ + }; + pageup { + linux,keycode = <104>; /* KEY_PAGEUP */ + }; + }; +}
drivers/input/keyboard/Kconfig +10 -0
@@ -665,4 +665,14 @@ config KEYBOARD_CROS_EC To compile this driver as a module, choose M here: the module will be called cros_ec_keyb. +config KEYBOARD_CAP1106 + tristate "Microchip CAP1106 touch sensor" + depends on OF && I2C + select REGMAP_I2C + help + Say Y here to enable the CAP1106 touch sensor driver. + + To compile this driver as a module, choose M here: the + module will be called cap1106. + endif
drivers/input/keyboard/Makefile +1 -0
@@ -11,6 +11,7 @@ obj-$(CONFIG_KEYBOARD_AMIGA) += amikbd.o obj-$(CONFIG_KEYBOARD_ATARI) += atakbd.o obj-$(CONFIG_KEYBOARD_ATKBD) += atkbd.o obj-$(CONFIG_KEYBOARD_BFIN) += bf54x-keys.o +obj-$(CONFIG_KEYBOARD_CAP1106) += cap1106.o obj-$(CONFIG_KEYBOARD_CLPS711X) += clps711x-keypad.o obj-$(CONFIG_KEYBOARD_CROS_EC) += cros_ec_keyb.o obj-$(CONFIG_KEYBOARD_DAVINCI) += davinci_keyscan.o
drivers/input/keyboard/cap1106.c new file +378 -0
378 lines not on this page · raw message
Signature · 1 line
1.9.3
Quoted 37 lines · Daniel Mack
This patch adds a driver for Microchips CAP1106, an I2C driven, 6-channel capacitive touch sensor.
For now, only the capacitive buttons are supported, and no specific settings that can be tweaked for individual channels, except for the device-wide sensitivity gain. The defaults seem to work just fine out of the box, so I'll leave configurable parameters for someone who's in need of them and who can actually measure the impact. All registers are prepared, however. Many of them are just not used for now.
The implementation does not make any attempt to be compatible to platform data driven boards, but fully depends on
CONFIG_OF.Power management functions are also left for volounteers with the ability to actually test them.
Signed-off-by Daniel Mack <[email protected]>---
v2:
* Fix potential deadlocks pointed out by David..../devicetree/bindings/input/cap1106.txt | 63 ++++ drivers/input/keyboard/Kconfig | 10 + drivers/input/keyboard/Makefile | 1 + drivers/input/keyboard/cap1106.c | 378 +++++++++++++++++++++ 4 files changed, 452 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/cap1106.txt create mode 100644 drivers/input/keyboard/cap1106.cDocumentation/devicetree/bindings/input/cap1106.txt new file +2
-0@@ -0,0 +1,63 @@ +Device tree bindings for Microchip CAP1106, 6 channel capacitive touch sensor +
Documentation/devicetree/bindings/input/cap1106.txt line 12
Quoted 10 lines
Documentation/devicetree/bindings/input/cap1106.txt new file +10
-0+The node for this driver must be a child of a I2C controller node, as the +device communication via I2C only. + +Required properties: + + compatible: Must be "microchip,cap1106" + reg: The I2C slave address of the device. + Only 0x28 is valid. + interrupt: Node describing the interrupt line the device's + ALERT#/CM_IRQ# pin is connected to.
s/interrupt/interrupts/
This is a _property_, not a node.
I take it the device only has a single interrupt line?
Documentation/devicetree/bindings/input/cap1106.txt line 23
Quoted 11 lines
Documentation/devicetree/bindings/input/cap1106.txt new file +11
-0+ +Optional properties: + + autorepeat: Enables the Linux input system's autorepeat + feature on the input device. + microchip,sensor-gain: Defines the gain of the sensor circuitry. This + effectively controls the sensitivity, as a + smaller delta capacitance is required to + generate the same delta count values. + Valid values are 1, 2, 4, and 8. + By default, a gain of 1 is set.
Does the official documentation describe this in absolute terms?
Documentation/devicetree/bindings/input/cap1106.txt line 31
Quoted 8 lines
Documentation/devicetree/bindings/input/cap1106.txt new file +8
-0+ +To define details of each individual button channel, six subnodes can be +specified. Inside each of those, the following property is valid: + + linux,keycode: Specify the numeric identifier of the keycode to be + generated when this channel is activated. If this + property is omitted, KEY_A, KEY_B, etc are used as + defaults.
What are those subnodes, and how are they told apart? Name, compatible?
I strongly recommend against relying on the order of the DT. It's very easy for that to get messed up and makes things hard to read.
Is is not possible to use linux,keymap and treat the buttons as a matrix keypad? Then you don't need subnodes at all, and you can have a sparse keymap if you want.
[...]
Documentation/devicetree/bindings/input/cap1106.txt line 37
Quoted 6 lines
Documentation/devicetree/bindings/input/cap1106.txt new file +6
-0+struct cap1106_priv { + struct regmap *regmap; + struct input_dev *idev; + struct work_struct work; + spinlock_t lock; + bool closed:1;
I don't think you're saving anything here by trying to have a bool bitfield.
[...]
Documentation/devicetree/bindings/input/cap1106.txt line 49
Quoted 12 lines
Documentation/devicetree/bindings/input/cap1106.txt new file +12
-0+ i = 0; + for_each_child_of_node(node, child) { + if (i == CAP1106_NUM_CHN) { + dev_err(dev, "Too many button nodes.\n"); + return -EINVAL; + } + + if (!of_property_read_u32(child, "linux,keycode", &tmp32)) + priv->keycodes[i] = tmp32; + + i++; + }
I don't think that it is a good idea to rely on the order of sub-nodes in the DTB.
[...]
Documentation/devicetree/bindings/input/cap1106.txt line 51
Quoted 2 lines
Documentation/devicetree/bindings/input/cap1106.txt new file +2
-0+ if (of_get_property(node, "autorepeat", NULL)) + __set_bit(EV_REP, priv->idev->evbit);
Use of_property_read_bool.
/me mutters usual grumblings about the autorepeat property.
Thanks,
Mark.
Hi Mark,
thanks a lot for your feedback! Much appreciated.
Quoted 19 lines · Mark Rutland
Quoted 4 lines · Daniel Mack
+++
b/Documentation/devicetree/bindings/input/cap1106.txtDocumentation/devicetree/bindings/input/cap1106.txt new file +2
-0@@ -0,0 +1,63 @@ +Device tree bindings for Microchip CAP1106, 6 channel capacitive touch sensor +Documentation/devicetree/bindings/input/cap1106.txt line 12
Quoted 10 lines
Documentation/devicetree/bindings/input/cap1106.txt new file +10
-0+The node for this driver must be a child of a I2C controller node, as the +device communication via I2C only. + +Required properties: + + compatible: Must be "microchip,cap1106" + reg: The I2C slave address of the device. + Only 0x28 is valid. + interrupt: Node describing the interrupt line the device's + ALERT#/CM_IRQ# pin is connected to.s/interrupt/interrupts/
Quoted 1 line
This is a _property_, not a node.
Yes, I reworded that description a couple of times. Together with interrupt-parent, it's actually a property referencing a node ;) Will fix.
Quoted 1 line
I take it the device only has a single interrupt line?
Yes.
Quoted 5 lines
Quoted 5 lines
Documentation/devicetree/bindings/input/cap1106.txt new file +5
-0+ +Optional properties: + + autorepeat: Enables the Linux input system's autorepeat + feature on the input device.
Quoted 8 lines
Documentation/devicetree/bindings/input/cap1106.txt line 23
Quoted 6 lines
Documentation/devicetree/bindings/input/cap1106.txt new file +6
-0+ microchip,sensor-gain: Defines the gain of the sensor circuitry. This + effectively controls the sensitivity, as a + smaller delta capacitance is required to + generate the same delta count values. + Valid values are 1, 2, 4, and 8. + By default, a gain of 1 is set.Does the official documentation describe this in absolute terms?
The documentation describes the gain feature as "1, 2, 4, or 8", so I kept it like this in the bindings. Internally, the register stores that value in 2 bits. The driver takes care for the translation.
Quoted 10 lines
Documentation/devicetree/bindings/input/cap1106.txt line 31
Quoted 7 lines
Documentation/devicetree/bindings/input/cap1106.txt new file +7
-0+To define details of each individual button channel, six subnodes can be +specified. Inside each of those, the following property is valid: + + linux,keycode: Specify the numeric identifier of the keycode to be + generated when this channel is activated. If this + property is omitted, KEY_A, KEY_B, etc are used as + defaults.What are those subnodes, and how are they told apart? Name, compatible?
Quoted 6 lines
I strongly recommend against relying on the order of the DT. It's very easy for that to get messed up and makes things hard to read.
Is is not possible to use linux,keymap and treat the buttons as a matrix keypad? Then you don't need subnodes at all, and you can have a sparse keymap if you want.
Hmm, I thought about that, but there are - in theory - more details that could be specified per channel. I left those functions out for the first version, as I have no good way to test them.
Hence, my idea was to have everything related to one channel nicely grouped in a subnode. I've also seen bindings that rely on the order of subnodes before, for example in regulator drivers.
But I agree with you that it makes board definitions error-prone.
linux,keycode feels a bit overkill here though, so I'd rather go for a fixed-size linux,keycodes property. The number of entries is fixed, anyway. Would you be fine with that?
Quoted 9 lines
drivers/input/keyboard/cap1106.c line 67
Quoted 6 lines
drivers/input/keyboard/cap1106.c new file +6
-0+struct cap1106_priv { +struct regmap *regmap; +struct input_dev *idev; +struct work_struct work; +spinlock_t lock; +bool closed:1 ;I don't think you're saving anything here by trying to have a bool bitfield.
That variable has been dropped in v3 already :)
Quoted 7 lines
Quoted 7 lines
drivers/input/keyboard/cap1106.c new file +7
-0+ i =0 ; +for_each_child_of_node (node, child) { +if (i ==CAP1106_NUM_CHN ) { +dev_err (dev,"Too many button nodes.\n" ); +return -EINVAL ; + } +
Quoted 8 lines
drivers/input/keyboard/cap1106.c line 295
Quoted 5 lines
drivers/input/keyboard/cap1106.c new file +5
-0+if (!of_property_read_u32 (child,"linux,keycode" , &tmp32)) + priv->keycodes[i] = tmp32; + + i++; + }I don't think that it is a good idea to rely on the order of sub-nodes in the DTB.
Jup, I agree. As mentioned above, I'd like to solve that with linux,keycode for now.
Quoted 6 lines
[...]
drivers/input/keyboard/cap1106.c line 306
Quoted 2 lines
drivers/input/keyboard/cap1106.c new file +2
-0+if (of_get_property (node,"autorepeat" ,NULL )) +__set_bit (EV_REP , priv->idev->evbit);Use
of_property_read_bool.
Will do, thanks.
Quoted 1 line
/me mutters usual grumblings about the autorepeat property.
I took that from the gpio-keys driver. Is there a better way to denote such a feature?
Thanks,
Daniel
Quoted 24 lines · Daniel Mack
Hi Mark,
thanks a lot for your feedback! Much appreciated.
Quoted 19 lines · Mark Rutland
Quoted 4 lines · Daniel Mack
+++
b/Documentation/devicetree/bindings/input/cap1106.txtDocumentation/devicetree/bindings/input/cap1106.txt new file +2
-0@@ -0,0 +1,63 @@ +Device tree bindings for Microchip CAP1106, 6 channel capacitive touch sensor +Documentation/devicetree/bindings/input/cap1106.txt line 12
Quoted 10 lines
Documentation/devicetree/bindings/input/cap1106.txt new file +10
-0+The node for this driver must be a child of a I2C controller node, as the +device communication via I2C only. + +Required properties: + + compatible: Must be "microchip,cap1106" + reg: The I2C slave address of the device. + Only 0x28 is valid. + interrupt: Node describing the interrupt line the device's + ALERT#/CM_IRQ# pin is connected to.s/interrupt/interrupts/
Quoted 8 lines
Quoted 1 line
This is a _property_, not a node.
Yes, I reworded that description a couple of times. Together with interrupt-parent, it's actually a property referencing a node ;) Will fix.
Quoted 1 line
I take it the device only has a single interrupt line?
Yes.
Ok, that sounds fine then.
Quoted 14 lines
Quoted 5 lines
Quoted 5 lines
Documentation/devicetree/bindings/input/cap1106.txt new file +5
-0+ +Optional properties: + + autorepeat: Enables the Linux input system's autorepeat + feature on the input device.Quoted 8 lines
Documentation/devicetree/bindings/input/cap1106.txt line 23
Quoted 6 lines
Documentation/devicetree/bindings/input/cap1106.txt new file +6
-0+ microchip,sensor-gain: Defines the gain of the sensor circuitry. This + effectively controls the sensitivity, as a + smaller delta capacitance is required to + generate the same delta count values. + Valid values are 1, 2, 4, and 8. + By default, a gain of 1 is set.Does the official documentation describe this in absolute terms?
Quoted 3 lines
The documentation describes the gain feature as "1, 2, 4, or 8", so I kept it like this in the bindings. Internally, the register stores that value in 2 bits. The driver takes care for the translation.
That sounds fine.
Quoted 13 lines
Quoted 13 lines
Documentation/devicetree/bindings/input/cap1106.txt line 31
Quoted 7 lines
Documentation/devicetree/bindings/input/cap1106.txt new file +7
-0+To define details of each individual button channel, six subnodes can be +specified. Inside each of those, the following property is valid: + + linux,keycode: Specify the numeric identifier of the keycode to be + generated when this channel is activated. If this + property is omitted, KEY_A, KEY_B, etc are used as + defaults.What are those subnodes, and how are they told apart? Name, compatible?
I strongly recommend against relying on the order of the DT. It's very easy for that to get messed up and makes things hard to read.
Quoted 7 lines
Quoted 3 lines
Is is not possible to use linux,keymap and treat the buttons as a matrix keypad? Then you don't need subnodes at all, and you can have a sparse keymap if you want.
Hmm, I thought about that, but there are - in theory - more details that could be specified per channel. I left those functions out for the first version, as I have no good way to test them.
Ok. Could you elaborate on what those details might be? It might make sense to have these as nodes if there are arbitrary properties to describe for each button, but I'm not familiar enough with the hardware to make a call either way.
Quoted 3 lines
Hence, my idea was to have everything related to one channel nicely grouped in a subnode. I've also seen bindings that rely on the order of subnodes before, for example in regulator drivers.
Sure. There's plenty of bad practice in DT bindings and code. There's just too much of it going on to get everything sane, and it's not always possible to fix the insane stuff if people are already using it.
Quoted 5 lines
But I agree with you that it makes board definitions error-prone.
linux,keycode feels a bit overkill here though, so I'd rather go for a fixed-size linux,keycodes property. The number of entries is fixed, anyway. Would you be fine with that?
Assuming no-one's likely to want a sparse keymap (i.e. one where some keys do nothing) then that's probably ok.
Quoted 36 lines
Quoted 9 lines
drivers/input/keyboard/cap1106.c line 67
Quoted 6 lines
drivers/input/keyboard/cap1106.c new file +6
-0+struct cap1106_priv { +struct regmap *regmap; +struct input_dev *idev; +struct work_struct work; +spinlock_t lock; +bool closed:1 ;I don't think you're saving anything here by trying to have a bool bitfield.
That variable has been dropped in v3 already :)
Quoted 7 lines
Quoted 7 lines
drivers/input/keyboard/cap1106.c new file +7
-0+ i =0 ; +for_each_child_of_node (node, child) { +if (i ==CAP1106_NUM_CHN ) { +dev_err (dev,"Too many button nodes.\n" ); +return -EINVAL ; + } +Quoted 8 lines
drivers/input/keyboard/cap1106.c line 295
Quoted 5 lines
drivers/input/keyboard/cap1106.c new file +5
-0+if (!of_property_read_u32 (child,"linux,keycode" , &tmp32)) + priv->keycodes[i] = tmp32; + + i++; + }I don't think that it is a good idea to rely on the order of sub-nodes in the DTB.
Jup, I agree. As mentioned above, I'd like to solve that with linux,keycode for now.
Quoted 5 lines
[...]
Quoted 2 lines
drivers/input/keyboard/cap1106.c new file +2
-0+if (of_get_property (node,"autorepeat" ,NULL )) +__set_bit (EV_REP , priv->idev->evbit);
Quoted 8 lines
Quoted 1 line
Use
of_property_read_bool.Will do, thanks.
Quoted 1 line
/me mutters usual grumblings about the autorepeat property.
I took that from the gpio-keys driver. Is there a better way to denote such a feature?
Unfortunately not, given current practice. My gripe is that it's a Linux detail that were describing rather than a property of the device. We can forget about that for now.
Thanks,
Mark.
Quoted 10 lines · Mark Rutland
Quoted 3 lines · Daniel Mack
Hmm, I thought about that, but there are - in theory - more details that could be specified per channel. I left those functions out for the first version, as I have no good way to test them.
Ok. Could you elaborate on what those details might be? It might make sense to have these as nodes if there are arbitrary properties to describe for each button, but I'm not familiar enough with the hardware to make a call either way.
No, there are just settings that can be made for each indvidual channel/button, such as sensitivity settings for instance. But they can of course be specified in a similar manner as the keycodes, in a fixed-size array. That's completely ok I think.
Quoted 6 lines
Quoted 3 lines
linux,keycode feels a bit overkill here though, so I'd rather go for a fixed-size linux,keycodes property. The number of entries is fixed, anyway. Would you be fine with that?
Assuming no-one's likely to want a sparse keymap (i.e. one where some keys do nothing) then that's probably ok.
If such a setup occurs, support for disabling channels could easily be added, and in such cases, the keycode is simple ignored. I don't think a sparse matrix keymap makes much sense here, especially as the buttons are not organized in rows and columns.
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
/me mutters usual grumblings about the autorepeat property.
I took that from the gpio-keys driver. Is there a better way to denote such a feature?
Unfortunately not, given current practice. My gripe is that it's a Linux detail that were describing rather than a property of the device. We can forget about that for now.
I see, so I'll leave it as it is.
I'll drop the input device unregister call as Dmitry said, and repost v5.
Thanks again!
Daniel
Quoted 34 lines · Daniel Mack
Quoted 10 lines · Mark Rutland
Quoted 3 lines · Daniel Mack
Hmm, I thought about that, but there are - in theory - more details that could be specified per channel. I left those functions out for the first version, as I have no good way to test them.
Ok. Could you elaborate on what those details might be? It might make sense to have these as nodes if there are arbitrary properties to describe for each button, but I'm not familiar enough with the hardware to make a call either way.
No, there are just settings that can be made for each indvidual channel/button, such as sensitivity settings for instance. But they can of course be specified in a similar manner as the keycodes, in a fixed-size array. That's completely ok I think.
Quoted 6 lines
Quoted 3 lines
linux,keycode feels a bit overkill here though, so I'd rather go for a fixed-size linux,keycodes property. The number of entries is fixed, anyway. Would you be fine with that?
Assuming no-one's likely to want a sparse keymap (i.e. one where some keys do nothing) then that's probably ok.
If such a setup occurs, support for disabling channels could easily be added, and in such cases, the keycode is simple ignored. I don't think a sparse matrix keymap makes much sense here, especially as the buttons are not organized in rows and columns.
Quoted 5 lines
Quoted 4 lines
Quoted 1 line
/me mutters usual grumblings about the autorepeat property.
I took that from the gpio-keys driver. Is there a better way to denote such a feature?
Quoted 7 lines
Quoted 3 lines
Unfortunately not, given current practice. My gripe is that it's a Linux detail that were describing rather than a property of the device. We can forget about that for now.
I see, so I'll leave it as it is.
I'll drop the input device unregister call as Dmitry said, and repost v5.
Sure, that all sounds fine.
Cheers,
Mark.
Dmitry Torokhov
maintainerHi Mark,
Quoted 8 lines · Mark Rutland
Quoted 4 lines · Daniel Mack
linux,keycode feels a bit overkill here though, so I'd rather go for a fixed-size linux,keycodes property. The number of entries is fixed, anyway. Would you be fine with that?
Assuming no-one's likely to want a sparse keymap (i.e. one where some keys do nothing) then that's probably ok.
For such a small keymap, if one does not want to use some of the buttons, setting corresponding entries to KEY_RESERVED should work well.
Quoted 7 lines
Quoted 3 lines
I took that from the gpio-keys driver. Is there a better way to denote such a feature?
Unfortunately not, given current practice. My gripe is that it's a Linux detail that were describing rather than a property of the device. We can forget about that for now.
I prefer looking at it as user expressing the desired behavior of the driver; it is up to OS to deliver such behavior ;)
Thanks.
Signature · 1 line
Dmitry
Quoted 9 lines · Dmitry Torokhov
Hi Mark,
Quoted 6 lines · Mark Rutland
Quoted 4 lines · Daniel Mack
linux,keycode feels a bit overkill here though, so I'd rather go for a fixed-size linux,keycodes property. The number of entries is fixed, anyway. Would you be fine with that?
Quoted 6 lines
Quoted 2 lines
Assuming no-one's likely to want a sparse keymap (i.e. one where some keys do nothing) then that's probably ok.
For such a small keymap, if one does not want to use some of the buttons, setting corresponding entries to
KEY_RESERVEDshould work well.
Ah, I was not aware of KEY_RESERVED. That sounds perfect then.
Quoted 10 lines
Quoted 7 lines
Quoted 3 lines
I took that from the gpio-keys driver. Is there a better way to denote such a feature?
Unfortunately not, given current practice. My gripe is that it's a Linux detail that were describing rather than a property of the device. We can forget about that for now.
I prefer looking at it as user expressing the desired behavior of the driver; it is up to OS to deliver such behavior ;)
Sure, but the user and DTB author are not the same, and may have different preferences. Additionally autorepeat as a property only tells half the story; I might prefer a 1ms delay while my neighbour Joe might like a 3 billion year delay (he's a bit like that, Joe is). He also only wants the esc key to repeat and can't figure out how to express that in this DTB thing he's never heard of.
We can just leave this with me grumbling if you prefer ;)
Thanks,
Mark.