[Feature request] Specifying pauses in macros #359 #437
Conversation
… time in microseconds.
| @@ -247,7 +248,7 @@ typedef struct { | |||
| // Color dithering in use | |||
| char dither; | |||
| // Flag to check, if large macros should be sent delayed | |||
| char delay; | |||
| uint delay; | |||
There was a problem hiding this comment.
This var is used by the GUI element "Settings -> More Settings -> Use delay for very long macros.
Have you checked what happens with this Element if you change the type?
There was a problem hiding this comment.
Yes, on two accounts, the other changes use this as a uint, and the syntax the GUI uses works with the these changes.
There was a problem hiding this comment.
OK, thanks.
I have done some testing today. First I merged your d6aa207 and my macrotime0.1.
Then I created a new G-macro (typing very, very slowly):
+lshift,+d=26161,-d=37140,-lshift=142738,+a=89017,-a=144970,+s=92969,-s=50021,+space=1996,-space,+w=82943,-w=49985,+i=95034,-i=78998,+r=61994,-r=91999,+d=81007,-d=51698,+space,-space,+e=100986,-e=35010,+i=86196,-i=53792,+n=15992,-n=46003,+space=3206,-space=2798,+lshift=76004,+t=9013,-t=3990,-lshift=32303,+e=61019,-e=6009,+x=86265,-x=49755,+t=1956,-t=4440,+space=97006,-space=3994,+m=97974,+i=19981,-m=6008,-i=1998,+t=630,-t=7036,+space=8959,-space=65303,+lshift=7099,+d,-lshift,-d,+e,-e,+l,+a,-l=31996,+z=56249,-a=58814,-z=58948,+enter=69214,-enter
That gives a string "Das wird ein Text mit Delay", which means "That gets a text with delay". Trying this macro runs well.
But if I repeat pressing that G-key (10, 20 times) while the macro is just running, I get sometimes a disconnect of the KB. The daemon is killed and restartet from init.
The logging says something about usb disconnected (there is an unformmated file at the end of this post):
22.08.2016 20:14:59 Mainfrix kernel [20612.403540] input: ckb1: Corsair K95 RGB Gaming Keyboard as /devices/virtual/input/input117 22.08.2016 20:16:42 Mainfrix kernel [20715.383813] usb 1-3: USB disconnect, device number 46 22.08.2016 20:16:42 Mainfrix kernel [20715.657524] usb 1-3: new full-speed USB device number 47 using xhci_hcd 22.08.2016 20:16:44 Mainfrix acpid input device has been disconnected, fd 17 22.08.2016 20:16:44 Mainfrix acpid input device has been disconnected, fd 25 22.08.2016 20:16:47 Mainfrix kernel [20720.793068] usb 1-3: unable to read config index 0 descriptor/all 22.08.2016 20:16:47 Mainfrix kernel [20720.793073] usb 1-3: can't read configurations, error -110 22.08.2016 20:16:47 Mainfrix kernel [20720.905202] usb 1-3: new full-speed USB device number 48 using xhci_hcd 22.08.2016 20:16:48 Mainfrix kernel [20721.034919] usb 1-3: New USB device found, idVendor=1b1c, idProduct=1b11 22.08.2016 20:16:48 Mainfrix kernel [20721.034923] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 22.08.2016 20:16:48 Mainfrix kernel [20721.034925] usb 1-3: Product: Corsair K95 RGB Gaming Keyboard 22.08.2016 20:16:48 Mainfrix kernel [20721.034926] usb 1-3: Manufacturer: Corsair 22.08.2016 20:16:48 Mainfrix kernel [20721.034928] usb 1-3: SerialNumber: 0F022014AE3B9406537275B6F5001945 22.08.2016 20:16:48 Mainfrix kernel [20721.036220] input: Corsair Corsair K95 RGB Gaming Keyboard as /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/0003:1B1C:1B11.0051/input/input118 22.08.2016 20:16:48 Mainfrix kernel [20721.089793] hid-generic 0003:1B1C:1B11.0051: input,hidraw2: USB HID v1.11 Keyboard [Corsair Corsair K95 RGB Gaming Keyboard ] on usb-0000:00:14.0-3/input0 22.08.2016 20:16:48 Mainfrix kernel [20721.090869] input: Corsair Corsair K95 RGB Gaming Keyboard as /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.1/0003:1B1C:1B11.0052/input/input119 22.08.2016 20:16:48 Mainfrix kernel [20721.145683] hid-generic 0003:1B1C:1B11.0052: input,hidraw3: USB HID v1.11 Keyboard [Corsair Corsair K95 RGB Gaming Keyboard ] on usb-0000:00:14.0-3/input1 22.08.2016 20:16:48 Mainfrix kernel [20721.146367] hid-generic 0003:1B1C:1B11.0053: hiddev0,hidraw4: USB HID v1.11 Device [Corsair Corsair K95 RGB Gaming Keyboard ] on usb-0000:00:14.0-3/input2 22.08.2016 20:16:48 Mainfrix kernel [20721.147014] hid-generic 0003:1B1C:1B11.0054: hiddev0,hidraw5: USB HID v1.11 Device [Corsair Corsair K95 RGB Gaming Keyboard ] on usb-0000:00:14.0-3/input3 22.08.2016 20:16:48 Mainfrix mtp-probe checking bus 1, device 48: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3" 22.08.2016 20:16:48 Mainfrix mtp-probe bus: 1, device: 48 was not an MTP device 22.08.2016 20:16:48 Mainfrix acpid input device has been disconnected, fd 17 22.08.2016 20:16:48 Mainfrix acpid input device has been disconnected, fd 25 22.08.2016 20:16:48 Mainfrix kernel [20721.427641] input: ckb1: Corsair K95 RGB Gaming Keyboard as /devices/virtual/input/input120 22.08.2016 20:16:48 Mainfrix kernel [20721.427859] input: ckb1: Corsair K95 RGB Gaming Keyboard as /devices/virtual/input/input121
Running the ckb-daemon with gdb brings following output:
`(gdb) run
Starting program: /home/lutz/Projekte/ckb/bin/ckb-daemon
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
ckb: Corsair RGB driver beta-v0.2.6+t04
[I] Root controller ready at /dev/input/ckb0
[New Thread 0x7ffff6b5b700 (LWP 30508)]
[I] Connecting Corsair K95 RGB Gaming Keyboard at /dev/input/ckb1
[New Thread 0x7ffff635a700 (LWP 30511)]
[I] Starting input thread for /dev/input/ckb1
[New Thread 0x7ffff5b59700 (LWP 30512)]
[I] Setup finished for /dev/input/ckb1
Here is the crash:
# [E] os_usbsend (via led_keyboard.c:131): No such device
[I] Attempting reset...
[E] os_resetusb (via usb.c:169): resetusb failed: No such device
[E] usb_tryreset (usb.c:177): Reset failed. Disconnecting.
[I] Stopping input thread for /dev/input/ckb1
[I] Disconnecting /dev/input/ckb1
[Thread 0x7ffff635a700 (LWP 30511) exited]
[I] Removed device path /dev/input/ckb1
[Thread 0x7ffff5b59700 (LWP 30512) exited]
[Thread 0x7ffff6b5b700 (LWP 30508) exited]
[New Thread 0x7ffff5b59700 (LWP 2684)]
[I] Connecting Corsair K95 RGB Gaming Keyboard at /dev/input/ckb1
[New Thread 0x7ffff635a700 (LWP 2702)]
[I] Starting input thread for /dev/input/ckb1
[New Thread 0x7ffff5154700 (LWP 2703)]
[I] Setup finished for /dev/input/ckb1
`
Do you have the same effect?
You can take my 6f9331a (is called macrotime.0.2) to check this behaviour.
BTW: In my environment UINT_MAX was undefined, so I needed to include a headerfile.
Here you can find a more detailed output:
protocol_ckb.txt
cu. Lutz
There was a problem hiding this comment.
I'm on a Mac, using Xcode's gcc to compile, UINT_MAX was 4-billion something.
I did try recording a delayed macro, on my version, not yours, and hitting the key a few times. There was a long delay but the macro played back and the keys afterwards were queued and played. The macro was not as long as yours, and I think I hit it maybe 3 to 4 times, not 10 to 20.
I suspect the key buffer is getting overflowed causing the disconnect. Perhaps there should be a limit to the delay time? I think this would only make the problem harder to reproduce rather than fixing it though.
The question is, what to do when this happens? Queue up more macro keys (make the queue larger), drop some of them (at the start or end of the queue), limit the queue size, or ignore it and pretend it doesn't happen, pretend it doesn't crash.
- Making the queue larger might actually make the keyboard seem broken to people. If a really long macro is playing back and they hit keys, they won't see anything happening, their keys will be delayed until earlier ones finish playing.
- Dropping keys seems tricky. First, which keystrokes to drop? Ones at the start or end of the queue? I could see making the case for either and for both of them being the wrong choice.
- Limiting the queue size would be the same as dropping the most recent keys struck.
- Ignoring the problem is kind of what happens now. Not sure that's the right thing to do.
I'm leaning towards limiting the queue size as being the right answer here (4). Figuring out when the queue is full and ignoring new input. Maybe there should there be command that cancels macro playback? One you could bind to another key or in a sequence.
This is getting tricky.
There was a problem hiding this comment.
The macro-killing key should flush (empty) out the keyboard buffer and ignore any to-be sent keys as well as cancelling any macro playback.
#including limits.h worked fine in my environment.
There was a problem hiding this comment.
Maybe there is another possible reason for the crashes: the Firmware in the KB itself.
The reason why I implemented the original delay was the overflow of the buffer in the unix User-device-driver in the direction from ckb-daemon to user-input. When I had longer macros, some of the keys were dropped - independent of the keystroke-frequency.
When I tested this, there was only 1 keystroke type ahead. With a long macro (I tested with hundreds and some thousand chars) and pressing the G-Key 3 times, the macro string appeared 2 times.
If I pressed G-key 2 times and a 3rd time when the 2nd macro was executing, a third macro string appeared and so on.
IMHO this is a behaviour of the USB user-driver in linux, but I didn't check it in the code. But if I'm right, there might be no response to the KB via USB. Maybe there is the reason for the failure. So if we can assure that the USB protocol isn't affected by our delays, we come a step further: We get your choice No 4.
On the other hand: Who needs repeatedly sending of very, very slow macros?
I'm not curious, but it's killing me, if I do not know something...
My suggestion: Let's implement the rest of the UI, bring it to the testing stage and wait for comments. Maybe this is a problem only on debian / ubuntu based systems with older kernels and with mint18 the effect is gone - who knows...
There was a problem hiding this comment.
I sort of agree, option 4. Perhaps add a warning somewhere in the README about really long delays and keyboard overflows.
I have not yet tested your branch on my Mac. Keyboard is on a different machine than I've been at since last week. Hope to just double check and see if there's a crash or just a really long playback.
|
Approve changes |
Introduces a global and local delay for macro playback leveraging the on/off long-macro-delay work that appears in-progress. These changes use the
delaycommand for a global delay factor when playing back macro actions as well as allows individual action delays in themacrocommand.Resolves issue '[Feature request] Specifying pauses in macros #359'