Comet 1626864951

You may wish to go to Device Manager and configure the power settings of your USB hubs to never power off. Also, do ensure that your active CUE profiles define the side buttons.

There are free USB protocol analyzers. YMMV. Universal Serial Bus (USB) HID [Human Interface Devices] Usage Tables Version 1.12 of 28 October 2004 documents the media keys, so I don't expect this to be some custom Corsair communication; I would expect the keyboard would send the standard signals so that your computer system would know how to handle it even if CUE were not running.

You should find the file inside of the ZIP you downloaded in step 1. http://www.corsair.com/~/media/Corsair/download-files/drivers/keyboards/K40-setup-1_0_0_4_120313.zip 12/12/2013 03:27 PM 26,160,704 K40 setup 1.0.0.4 120313.exe 12/12/2013 03:26 PM 1,101,728 K40FwUpdate 1.00 sw-1.4.exe

Holding down the side buttons on the Scimitar Pro RGB does seem to work for me. Examples include REMAP KEY actions for: M01. Left Button M02. Middle Button M03. Right Button M08. Back M09. Forward In all these cases, a mouse button press event is sent to my application when I press the G key, and a mouse button release event is sent to my application when I release the G key. So there is no need to "imitate" a hold; the act of holding the G key down delays the button release event until I let go of the G key.

This is doable in CUE. Define the keys to switch profiles from default to Caps, Num, Scroll, CapsNum, NumScroll, ScrollCaps, CapsNumScroll profiles, where the profile switch retains original key output to maintain state and also have each profile light up the lock key as an indicator.

Set up copies of your default profile called CapsLock, ScrollLock, NumLock, CapsScroll, ScrollNum, NumCaps, CapsScrollNum, and define the lock keys to switch between them, having the lock keys light up or not depending on whether the feature is enabled. You can retain original key output in CUE 2, so the "status" is not lost between switching.

Rename SCR extension to EXE and schedule it to run when your computer is idle.

Create a hardware profile with keys dark, and let's call it "idle" and make it the default profile for good measure, and if you have a screensaver that can be linked, then link it (and you are done--set screen saver timeout to match monitor timeout). In the same CUE folder, put your old "default" profile. In your "default" profile, define a timer action set for the inactivity period of your monitor that will switch to your "idle" profile, and bind this to your frequently used keys, such as enter, retaining original key output. Ensure timer is configured to reset if there is key activity. In your "idle" profile, define actions, retaining original key output, to switch back to your "default" profile.

CUE 2 has a timer action that can be configured to be reset on activity. Bind such an action to frequently used keys, like "Enter", retaining original key output, and on timer expiry have it invoke a profile switch to your idle profile. In your idle profile, you can define actions for your keys retaining original output and switching profile back to your default profile.

Create afk profile with Corsair rainbow effect, and define actions keeping original key input to switch profile to your default static green profile. You can create a timer action in your static green profile to switch to your afk profile automatically on expiration, and bind it to a frequently used key, like Enter, having the timer restart every time you hit that key. This solution doesn't need IdleKey, so I will leave it to other posters to explain how to do what you want with that program, should you decide to use it.

Very easy to do--set up a macro which, when expires, goes to your idle profile with lights out, and have the timer reset if the key is used. Then bind it to any of your frequently used keyboard keys, such as Enter. Then, if your keyboard is idle, the profile with switch, even if you are active on the mouse. You can also set up actions for each key on your idle profile to retain original key settings and do a profile switch to your default profile.

You don't need "idle key"; you can set up a Timer action to switch to your dark idle profile after, say, 20 minutes if no activity, and bind this to a frequently-used key, such as Enter. You can further automate coming out of your dark idle profile by setting each key in it to retain original key settings and switch to your default profile.

What you want is already possible. Bind a profile switch to the first key (like Alt or Shft), and then you can have custom macro for the second key (like F8 or F3). See Tutorial: Switching Modes by Modifier Keys and Modifier Key Combos You can launch .exe, .bat, or .cmd files, and have those files run your VBS-script. (If you use a .EXE, you won't see a "command line" for VBS.)

Sounds like a possible issue (known or unknown) with the media software you are using. Perhaps they are intercepting the media key events sent by the keyboard.

Perhaps you just got a bad one; I have not experienced such problems as you describe, nor have many other people who share their CUE profiles on this forum. You might try RMA and see if you have better luck. I have encountered problems with new devices (laptop, handheld computers, cell phones, other), so I am not surprised when a particular electronic unit is a lemon--I have found that replacing it with another one (sometimes twice within the warranty period) usually works for me, and I wind up with a very stable unit.

Chess, Backgammon, Star Wars Galaxy of Heroes, Candy Crush Saga, Dragon's Lair, Ms Pacman, and any of the over 300 cartridges I have for my Atari 2600 video computer system.

Hello Inheritance, The Universal Serial Bus HID [Human Interface Device] Usage Tables, Version 1.12, 28 October 2014 in Chapter 10, Keyboard/Keypad Page (0x07), lists ALL the standard keycodes defined for a keyboard, and you can see that there is no single keycode for a shifted A character,as both uppercase "A" and lowercase "a" both send "usage id 4" from the keyboard to the host computer. (The footnote in this table indicates that usage id 4 is typically remapped to other letters if you are using a different language.) My post was describing exactly how to program a macro that could be bound that would send a SHIFT + A. This is not supposed to be the same as directly outputting the letter A. Depending on the application that is receiving the keyboard input, the computer might not "output a capital A"; it depends on what the application does when receiving an A while the shift key is held down, so if a game does something different for shifted A than unshifted A, the macro will work. I am not privy to Corsair's plans, but any better solution than SHIFT (keypress) A (keystroke) SHIFT (keyrelease) will be a UI or ease-of-use issue for the person wishing to program this functionality, and will not be "better" than the solution I gave, in terms of functionality, simply because to make a shifted A that will be recognized by a host computer, the keyboard must follow the standard. P.S. I see your tagline, "Cuddly Beta Nayn Cat." When you are production quality, will this become "Cuddly Nyan Cat?"

CUE 2 supports key combination support; see the tutorial. The trick is to make the first key switch to a different macro to recognize the second key. You can keep the effect of the first key, and assign the profile switch to a second action on the first macro.

Certainly, it is possible to do. [ame] [/ame]

It is possible to do this with CUE, but the way that occurs to me would require multiple profiles in CUE2 (or modes in CUE1). From the default profile, you would identify the first letter of your colors, G and R. Any time these letters were pressed, there would be a profile switch to identify the next letter. To identify both GREEN and RED, not only would one have a RED profile that colors the keyboard red, a GREEN profile that colors the keyboard green, a Default profile that colors the keyboard something else, but also several profiles to track intermediary recognition state (e.g. G, GR, GRE, GREE, R and RE). As you type each letter, the profile would recognize if you were spelling a color, and when you have typed out the full color name, then the keyboard will light up with the color you spelt. Default profile is "Default"; other profiles are shown in UPPERCASE. Lowercase letters following a profile indicate how that letter should be handled. Default g-> G g -> G !leave keyboard g in profile G unassigned G r -> GR G others -> Default GR e -> GRE GR g -> G GR r -> R GR others -> Default GRE d -> RED ! light keyboard red GRE e -> GREE GRE g -> G GRE r -> R GRE others -> Default RED r -> R RED g -> G RED others -> Default GREE n-> GREEN ! light keyboard green GREEN g-> G GREEN r -> R GREEN others -> Default Default r-> R r -> R ! leave keyboard r in profile R unassigned R g -> G R e -> RE R others -> Default RE r -> R RE g -> G RE d-> RED ! We already defined this profile to light the keyboard red. RE others -> Default In order to effect the profile transition, without losing the initial functionality of the alphabetic keys used in the color names, one defines two actions. One action, unbound, does the profile switch to the next letter. The other action uses a macro with one event of type keystroke, whose advanced properties specify as a second action the profile switch action defined above. The slight trickiness of this puzzle is if one types "GRED", that one needs to light the keyboard red. :biggrin: Of course, if instead of recognizing the color anywhere it is typed, you could modify the logic to include handling of word separators; this is left as an exercise for the student. As a practical matter, most profiles have the g and r keys defined to go to the G and R profiles, so as a practical matter, these would be defined first, and the profiles copied and renamed for use in the profiles that need it.

You would define A to be a SHIFT+A; the caps-lock acts as if the shift key were held down. See the Tutorial: Switching Modes by Modifier Keys and Modifier Key Combos

Hello Elestrial; Although the current functionality of the CUE performance tab lacks control over the "Num Lock, Scroll Lock, and Caps Lock" indicators, your statement that these are hardware driven and cannot be controlled by any software appears to be at incorrect, as any key can be programmed to act like "Num Lock, Scroll Lock, and Caps Lock" and the indicator lights toggle accordingly; if this were hardwired behavior, then I wouldn't expect the software that allows key rebindings to have any ability to turn on and off these indicator lights. My imagination currently fails to see any reason that there would be a technically infeasible reason preventing Corsair from updating the keyboard driver and CUE SDK to store the current state of the indicator lights and allow it to be queried and controlled by a program such as yours, because even if there is no current status flag, the path to light an indicator seems to be controlled by software, so that software can keep a flag and send another toggle event as needed for control. If I am mistaken, please do correct me. -------- Teatime: I thank you, sir. I'm always happy to be corrected. I shall remember that... next time.

With CUE 2, I set the hardware profile to static lighting (e.g. all keys off) and associate this profile to my screensaver. If the hardware profile has all the keys dimmed, then this replicates the description of the initial purpose of the idlekey program. Alternatively, a timer action can be set that retains original output, and resets on activity, calling the profile switch to the dark profile on timer expiration. This is bound to my "Enter" key, so that if my keyboard is inactive, then the profile switches automatically. In my dark profile, each key is defined to retain original keypress and switch profile back to my default profile.

I can control the Lock indicators in CUE 2, using the Performance tab. http://forum.corsair.com/v3/attachment.php?attachmentid=27943&d=1488092932 See also Whatff workaround.

To get started, after you've unpacked the ZIP file, use Visual Studio to open the .sln or .vcxproj files in the example folders. The capabilities of the SDK are focused on lighting control, so you may have to find another method to get the battery percentage of your VOID wireless headphones. (I only have the wired version of the headphones, or I'd try a few things out, such as WMI calls.) Overview The Corsair Utility Engine (CUE) SDK gives ability for third-party applications to control lightings on Corsair RGB devices. CUE SDK interacts with hardware through CUE so it should be running in order for SDK to work properly. SDK features are supported in CUE version 1.10 or higher. To use this SDK you should have basic knowledge in C and library linking.