macros Macro Keyboard

[leyton1210]

Hi, i am currently trying out Tarans 87 Macro Keyboard idea, and it is working pretty well - apart from the 10 device limit on Intercept.exe

Has anyone else tried this yet? Please let me know how you did it, how you are doing, are you still using it and attach a picture if possible

 

- Leyton

[NicholeMattera]

I do not have enough keyboards to test, but I have recompiled the interception drivers and replaced them in the "library" folder of the installer. Please give this a shot: https://github.com/StevenMattera/Interception/releases/tag/v1.0.1.1

 

I had it working with Intercept with 3 different keyboards: Razer Blackwidow Ultimate, Logitech G710+, and Logitech K830. All keyboards worked with intercept.exe and was able to output "test1", "test2", and "test3" when I hit a button on each of the keyboards. Also though I only had 3 keyboards connected I had 17 HID devices in my device manager.

 

Edit: The more I'm looking at this I'm wonder if the drivers are not what is limiting the number of devices, but the library that communicates with the drivers. Thus Intercept.exe needs to be recompiled with the new libraries I made. I will have a new copy of intercept.exe for you here shortly.

[leyton1210]

Could you send a picture of all of them

 

[NicholeMattera]

After going through the Intercept code a bit and changing the code to pull from 10 keyboard and 10 mice to 100 keyboard and 0 mice. I'm running into an error when it calls "DeviceIoControl" at index 20. The error is "The handle is invalid.". Now If I were to assume what is going on here. The drivers are limited to 20 (10 Keyboards and 10 Mice) and the library is also limited to 20 (10 keyboards and 10 mice). Just changing the library isn't enough as the second you try to query for "\\.\interception20" that device doesn't exists. ("\\.\interception00" - "\\.\interception19" all exists and makes up the original 20.) Because only the library is open-source and not the drivers I'm currently stuck.

[evilC]

Hi all, new user here, this appears to be about the only forum I can find on the net where this is being discussed, and I have some newsworthy items, so I thought I would post here.  

To clear some stuff up

• Editing the Interception API (The code on GitHub) is not going to fix this issue - that is straight from the dev's mouth. The 10 device limit is hard-coded into the driver source, which is not on GitHub, and even if it were, you would need a driver signing cert to be able to properly use it ($$$).
• I have been unable to properly repro the "Devices stopping working when you have >10 keyboards" issue that I have heard reported, but I just do not have enough keyboards handy at the moment (All of mine only report 1 or 2 each and I only have 5)  
  However, what I *did* do is alter the API and change max to 2, and limited my polling loop to devices 1 and 2, whilst keeping the default "Predicate" in the API (Which tells it which keyboards to filter). Now this is linked in to MAX_DEVICES, but still stuff that would have got IDs 3+ seem to get blocked. I suspect that the driver is totally unaware of the API's MAX_DEVICES setting. I suspect that what is happening when you exceed MAX_DEVICES is that the "extra" devices still match the filter predicate, but the processing loop never processes those devices, so none of the keystrokes ever get forwarded on - net result: the device "stops working".
• I have tried and tried to get the dev to sort this out, but it seems like this is not going to happen, so on to plan B...
  I spoke to Nefarius (Author of the ViGEm driver and SCPToolkit) and we are seriously entertaining the idea of buying a license and Nefarius fixing these problems.
  Nefarius has a driver signing cert, so no problems there.
  We have no plans to charge for this driver

So, with the last point in mind, should this be a goer, the plan would be to start a paypal pool or something and crowdfund the cost of the license. In this instance, trying to get the word out via LTT seems like a good idea.

 

Thoughts?

 

As a side note, and not meaning to hijack the thread here, I have written a new Interception wrapper for AHK called AutoHotInterception that lets you make AHK hotkeys and hotstrings work on a per-device basis. This uses a technique similar to the Intercept library, but instead of wrapping your keystrokes in other keystrokes, it wraps your keystrokes in function calls (Much less hacky).  

I also have another new library called TapHoldManager which lets you map multiple things to one key via a combination of taps and holds.  

Any number of taps and holds are supported, but in practicality only really 3 are feasible, but that still gives you 6 combinations per key.

TapHoldManager can be combined with AutoHotInterception to have multi-tap hotkeys on a 2nd keyboard, whilst not affecting the main keyboard.