k95 rgb Editing MR Indicators: Dialogue Resets Constantly

Howdy,

 

Got myself a nice new K95 RGB. Trying to get the M lights to work properly while the desktop is locked. Just using plain red colour.

 

Seems that the colour for the M2 profile (with CUE effects no less) saves properly while locked, but the M1 with plain colour doesn't (it turns... freakin' turquoise!?). I've run into a bit of an issue editing MR keys though...

 

When I right-click and select Indicator, the dialogue that pops up has all the settings defaulted. Also, whenever I select another M key/win-lock key, it defaults too. So it seems that I can only ever edit one key at a time, as whenever I edit another, it resets the one before.

 

Also, it seems that sometimes the brightness sliders are reversed. Sometimes far-left is 100%, othertimes it's far right. That's insane!

 

Any clues how to sort this out?

 

Running CUE 1.9.62, FW 1.30

Howdy,

 

Got myself a nice new K95 RGB. Trying to get the M lights to work properly while the desktop is locked. Just using plain red colour.

 

Seems that the colour for the M2 profile (with CUE effects no less) saves properly while locked, but the M1 with plain colour doesn't (it turns... freakin' turquoise!?). I've run into a bit of an issue editing MR keys though...

 

When I right-click and select Indicator, the dialogue that pops up has all the settings defaulted. Also, whenever I select another M key/win-lock key, it defaults too. So it seems that I can only ever edit one key at a time, as whenever I edit another, it resets the one before.

 

Also, it seems that sometimes the brightness sliders are reversed. Sometimes far-left is 100%, othertimes it's far right. That's insane!

 

Any clues how to sort this out?

 

Running CUE 1.9.62, FW 1.30

 

select the MR keys and right click --> clear

That has unfortunately had no effect. Even tried 'reset to default' too. Which made it white on the desktop, but still turquoise when locked (yes, after making sure to save it to the device). :(

I'm not sure what you want, but M1, M2 and M3 are a bit buggy. Red and that blasted cyan may have something to do with it.

 

There are two bugs relating to the M1, M2 and M3 keys.

 

Bug #1: Any colors assigned to the M1, M2 and M3 keys using the "Edit light" or the "Indicator" options only work when the CUE software is running. It doesn't matter that the settings are saved to the keyboard, because when the CUE software is not running these colors are lost.

 

However, there is a hidden method to assign colors to the M1, M2 and M3 keys that work when the CUE software is not running.

 

In the CUE software do the following:

 

1. Select mode 1.

2. Set the background color for the M1 key to indicate that mode 1 is active.

3. Set the background colors for the M2 and M3 keys to indicate that modes 2 and 3 are inactive.

4. Select mode 2.

5. Set the background color for the M2 key to indicate that mode 2 is active.

6. Set the background colors for the M1 and M3 keys to indicate that modes 1 and 3 are inactive.

7. Select mode 3.

8. Set the background color for the M3 key to indicate that mode 3 is active.

9. Set the background colors for the M2 and M3 keys to indicate that modes 1 and 2 are inactive.

10. Save all that to the keyboard's memory.

 

Note that you don't have to right click the keys. Just select them and use the color selector in the lower left of the window instead. You won't see a color change in the CUE, though. Ignore that.

 

The above sounds great, right? However, there is another bug.

 

Bug #2: The colors set in steps 2, 5 and 8 have their bits flipped by the CUE software.

 

That's not a joke, just a term used by software engineers. In the binary representation of the color every 1 becomes a 0 and every 0 becomes a 1. It means that a color will be assigned, but it is not the one that we want. The colors set in steps 3, 6 and 9 don't have that problem.

 

Now assume that in step 2 I want the color to be pure red. In binary this is written as 1111 1111 0000 0000 0000 0000. So if the bits will be flipped by the CUE software then we flip the bits ourselves first, lookup what color that represents and assign that instead. If we flip the bits we will get 0000 0000 1111 1111 1111 1111. That's easy right. Now we need to convert that to a color. Not so easy.

 

Luckily there is no need to use binary. We can use the CUE's color dialog box and the Windows calculator to do the work for us.

 

If you open the CUE's background color selection dialog box then you'll notice near the OK-button an HTML field. Now select pure red in that dialog box. Red will be shown there as #ff0000. Copy that, without the hash tag, with Ctrl+C to the clipboard. Leave the dialog box by pressing Cancel. Start the Windows calculator. Switch to the Programmer view. Press the "Hex" button. Paste the clipboard to the calculator with Ctrl+V. The number will be shown there as FF 0000. Press the "Not" button. You only need the last 6 characters from the result shown. That will be 00 FFFF. Remember that. Forget about the space in there. Go back to the color dialog in CUE. In the HTML field enter #00FFFF (the value we got from the calculator (without the space) with a hash tag in front).

 

Any idea what color #00FFFF is? *drum roll* Yes, you guessed it: Pure cyan. Ghehe.

 

If you apply that color in step 2 to the M1 key then it will be shown as red when the CUE software is not running and when mode 1 is active. Don't forget step 10 of course.

 

I hope this is part of your puzzle.

BTW: The MR, Brightness and WinLock keys can use the same hidden background coloring trick, because these too are effected by bug #1. Fortunately these do not suffer from bug #2 of the M1, M2 and M3 keys.

Ooh, now we're getting somewhere - I appreciate the in-depth response!

 

Unfortunately, it seems I'm suffering some confusion as to how the background vs. foreground vs. indicator colours are applied. Setting the background colour to Cyan gives me the red foreground colour in windows, and white when locked. So I tried setting the inverse of that (black), but that gets me back to Cyan. Setting Cyan foreground (indicator) and/or background in windows also gets me a white key while locked.

 

The other M keys I'm not as bothered about now - they're off (well, black) in windows and red at least when locked, but that doesn't really match being flipped either?

 

If I reset M1 to default, I get white in Windows, and cyan still while locked. I'm trying my best to keep the indicator/foreground and background colours the same for testing purposes, but it seems inconsistent to me.

 

I set M2 to a white background, active & inactive indicator profiles, but when locked, the red still comes on so it ends up pink.

 

Still, white's better than cyan!

No problem.

 

That's odd. With the methods described above I can set any color to those keys. Well, except the flashing red of the MR-key. Not sure if that one has an RGB-LED, though.

 

Anyway... Try this. Delete your default profile. Back it up first. Mine got corrupted somehow during the update to the latest CUE software. It worked fine, until I wanted to change things. Unexplained problems that went away after recreating my default profile.

BTW: If you are interested in my default profile then let me know. It'll show you that it really can be done. ;)

 

Edit: Just remembered. Not sure if it makes a difference, but I'm using the advanced settings.

BTW: If you are interested in my default profile then let me know. It'll show you that it really can be done. ;)

 

Edit: Just remembered. Not sure if it makes a difference, but I'm using the advanced settings.

 

Thanks MadIce for the bug report. Its been confirmed and reported.

Thanks MadIce for the bug report. Its been confirmed and reported.

Thanks. That's good to know. It has taken me considerable time to figure this one out. One has to be a bit mad to figure out the bit flipping. :P

 

I take it you are one of the beta testers? You guys do great work. It's appreciated. :)

 

Edit: I do hope that they'll keep this "hidden method" (without the bit flipping of course). You can use it to your advantage to indicate that those keys behave differently during boot or without the CUE software running. Maybe add it as a more friendly option?