The Corsair User Forums  

Go Back   The Corsair User Forums > Corsair Product Discussion > Corsair Utility Engine (CUE) > CUE SDK

Reply
 
Thread Tools Rate Thread Display Modes
  #16  
Old 02-11-2018, 04:48 AM
Darth Affe's Avatar
Darth Affe Darth Affe is offline
//TODO add user title
Darth Affe's PC Specs
 
Join Date: Sep 2015
Location: UTC+1
Posts: 117
POST ID # = 940082
Darth Affe Reputation: 15
Default

Quote:
Can I use the CUE SDK to assign different profiles to different keyboards?
No. The SDK has absolutely nothing to do with profiles. You can control the leds, and you can hook the G-keys. That's it.

Have you tried http://www.oblita.com/interception.html? I don't see any reason why this should have a device-limit.
Reply With Quote
  #17  
Old 02-11-2018, 04:59 AM
TaranVH TaranVH is offline
Registered User
 
Join Date: Feb 2018
Posts: 10
POST ID # = 940084
TaranVH Reputation: 10
Woah!

Quote:
Originally Posted by Darth Affe View Post
No. The SDK has absolutely nothing to do with profiles. You can control the leds, and you can hook the G-keys. That's it.

Have you tried http://www.oblita.com/interception.html? I don't see any reason why this should have a device-limit.
Yes. I've been using Interception for over a year now.
To get past the 10-device limit, you must pay $2200. Drivers (the best solution for multiple keyboards) must be licensed from Microsoft, and are not cheap.

https://github.com/oblitum/Intercept...ment-308619787

That's why I'm here. Since Corsair CUE is able to tell the difference between one of its own keyboards, and another manufacturer's keyboard, I thought it'd be able to tell the difference between two different Corsair keyboards.
Reply With Quote
  #18  
Old 02-11-2018, 09:27 PM
hastegag hastegag is offline
Registered User
hastegag's PC Specs
 
Join Date: Dec 2016
Location: Northeast US
Posts: 327
POST ID # = 940185
hastegag Reputation: 10
Default

@Taran I may be missing something, I get that you need to block the input from the multiply registered keyboards, and that Inception does the job up to ten, but it is based on the number of hid devices attached not keyboards, but I seem to think that Autohotkey could individually block each key's output prefixing the hotkey with ~, and I have not tested, but that should block regardless of where it came from?

Then inside of that blocking hotkey, first either readfile some state from a text file, or also check for the existence of a depressed off keyboard key (some arbitrary "modifier/meta/bucky/super" whatever you want to call it state).

The code I linked to above, if modified slightly could write to, or have some additional key depressed at the same time as each keyboard event and be executing specific code based on what keyboard handle the event came from.

Then autohotkey does the rest of the magic. I think that could work? I didn't get my 2nd k95 yet, busy day, but tomorrow, I am hopeful to get after it, but it should work and be nearly limitless in quantity? The only question would be if AHK blocks it quickly enough and reliably enough and implementing each specific handle dynamically and some other nuances.
Reply With Quote
  #19  
Old 02-13-2018, 03:06 PM
TaranVH TaranVH is offline
Registered User
 
Join Date: Feb 2018
Posts: 10
POST ID # = 940391
TaranVH Reputation: 10
Default

Quote:
Originally Posted by hastegag View Post
@Taran I may be missing something, I get that you need to block the input from the multiply registered keyboards, and that Inception does the job up to ten, but it is based on the number of hid devices attached not keyboards, but I seem to think that Autohotkey could individually block each key's output prefixing the hotkey with ~, and I have not tested, but that should block regardless of where it came from?
The ~ prefix actually allows a key's normal function to pass through. It deliberately does NOT block the keypress.

In extreme cases, you can block ALL non-physical keyboard events if you really want to, but this has major drawbacks: https://autohotkey.com/board/topic/3...hid-functions/

I'm 99% sure that this solution would not work for me. Especially since I have like 200+ AHK functions, many of which are running continuously.
Reply With Quote
  #20  
Old 02-13-2018, 03:13 PM
TaranVH TaranVH is offline
Registered User
 
Join Date: Feb 2018
Posts: 10
POST ID # = 940394
TaranVH Reputation: 10
Default

Quote:
Originally Posted by hastegag View Post

Adjusting the code should get what you'd need at least as far as a proof of concept (and I'm not saying there are not easier ways, but this noticed the difference between two separate keyboards):

https://www.codeproject.com/Articles...tiple-keyboard

the above compiles right out of the box beautifully without a hiccup.
I had that linked to from part 3 of my video series.

but I also had a link to this:
https://www.codeproject.com/Articles...elective#Chap5

Take a look at the serious problems that can arise from this solution...:
-Delay/desync between hook and rawinput messages
-Missing raw input messages
-Missing hook messages
-"Senseless" hook messages
-Multiplied hook messages
-The "altgr" problem

For these reasons, I've been pursuing a driver-based solution for quite some time now. Can we not just use the existing Corsair drivers.... somehow?
Reply With Quote
Reply

Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -4. The time now is 10:09 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2018, vBulletin Solutions, Inc.