v4.5.0 Beta feedback

[upbeat cobalt]

RGB Layers gang

v4.5.0 Beta feedback

[grave sorrel]

That's super cool

(the RGB layers)

[copper sentinel]

Hell yea 😄

[hollow tusk]

Just tried it, looks promising!
Found something odd, there's an issue with the Shift key and Rapid Trigger, it seems to skip uppercase sometimes when typing. I'm on the Wooting Two.

[frail wing]

Per-layer RGB looking good!

I also like the ability to be able to change the threshold for modtap, though at first glance it took me awhile to find the little gear icon.

Only weird behaviour I've noticed so far is that after modtap is set on the caps lock key, trying to change the colour of it's active state does not save.

The UI changes, but it stays as the previous colour, even after saving. (not sure about other advanced keys). Removing modtap lets the colours change like how they should.

@empty tangle I think the ability to change the modtap threshold was something you mentioned earlier today right?

[empty tangle]

exactly that, knew you masterminds had something brewing

[cosmic tundra]

per layer rgb is super cool, any chance sdk apps could get access to what layer is active somehow? i can see people asking for this in artemis already 😅

[thin torrent]

opening

[upbeat cobalt]

Hmmm, interesting point, would it be so that sdk apps can send specific rgb based on the active layer? I'll have a think about it, as I've been thinking about how I can make it nicer for tracking the active profile, so could go hand in hand with that pretty nicely

@wild shale @astral owl @restive arch

[upbeat cobalt]

Is it possible that the shift key is releasing too early?

[upbeat cobalt]

Hmmmm, I can't replicate this, is this where the mod tap configuration itself doesn't have caps lock on it?

[hollow tusk]

Maybe, seems like holding it instantly makes it unpress or something.

[upbeat cobalt]

does it behave normally without rapid trigger enabled?

[hollow tusk]

It does behave normally yeah, I didn't notice any regressions so far

[frail wing]

Caps lock is set to tap, another key on hold (in my case Fn 1)

[astral owl]

I second this, I have caps lock set to tap and Fn1 on hold and i cant save new colours to the active state of caps lock

[upbeat cobalt]

Hmmm, I'll have another go at replicating it

Ohhhh, I see what's happening. Due to the fact you have Fn 1 & Caps lock on mod tap, it shows the indicator for Fn 1, which is for when Fn Lock is used, rather than the Caps lock indicator

hmmmm

[astral owl]

When i turn on Fn lock, my Fn1 button on the bottom right of the board shows the correct colour (yellow) that i set caps lock to but caps lock does not show any colour

So the indicator for Fn1 on caps lock does not show

[astral owl]

It seems to be working fine for me. Cant replicate this issue

I had RT set to 0.15

[hollow tusk]

Could be related to the range, I kept the defaults and didn't change the values, I'll try when I get back.

[restive arch]

I don't understand what the circles are that are on the space bar and FN 1 keys. These are new on the beta and they don't seem to do anything.

I'm still having issues with using space as my FN1 modifier via mod tap. It does seem to be improved compared to the current non-beta firmware, but I still have issues with it entering the function layer when typing normally. I set the activation threshold to 1000ms and if I tap space and a letter key quickly, I can see my fn layer 1 RGB activate immediately.

Also, my keyboard whines when function layers are active now and I don't think it used to do that.

[astral owl]

The circles are Fn lock activation colour

[astral owl]

And Fn may be activating when typing quickly because of this

Maybe wootility thinks the space bar is a modifier key

[restive arch]

~Ah, I didn't even know this was a feature.~ Actually, yes I did 😅

[astral owl]

Toggle key still does not work properly when used with Fn1.

But i guess thats what Fn lock is for. Still would be nice to be able to toggle Fn layer with a single press

[frail wing]

Just noticed this as well, but perhaps there is an issue with the translations. I have english selected, but seems like there is some chinese showing for the ` key

[astral owl]

very strange. Mine does not show that

[wild shale]

Once im back from holidays gonna check it out and report anything i find.

Thanks @upbeat cobalt !

[frail wing]

Could be an issue only for me since I am also contributing to the community translations (though I did not enable testing of the translations yet)

[gritty ginkgo]

RGB brightness is different. I had to adjust the brightness by +20% to get the same result as in the previous version

[upbeat cobalt]

Huh, that's weird, which keyboard model do you have?

[sacred vortex]

Yo. The custom hold duration for Mod Tap is amazing. I was kinda afraid about a 60% keyboard, but I think I've finally gotten all the annoyances out of the way. Is there anything specific that you're looking to confirm for the beta other than this?

[copper sentinel]

Try to break things and report back if you're successful 🙂

[sacred vortex]

I'll definitely try to break the delicate house of cards that are the bindings that give me all the keys I need 🙂

[sacred vortex]

Actually had a qq. I'm noticing that for the Override Hold Duration setting, the beta notes mention that just in time activation of the hold key applies to modifier and FN keys, but it doesn't seem to be the case where the key that's pressed with these keys is a mod tap key.

Just wondering if it's possible to have just in time activation actually take precedence for the FN key. I have the hacks for giving me arrow keys (bottom right modifiers set to mod tap, and the adjacent keys setup as arrow keys in the FN layer), but I'm finding that sometimes if I hit FN + say, RCTRL, RCTRL's mod tap tap key activates. I'm not sure how this could be useful; I'd almost expect the FN layer to take precedence since, if I wanted mod tap on any key while FN is held, I could just add mod tap to the FN layer.

Hopefully that was clear. tl;dr - Is it possible for FN to always have just in time activation of the mod tap hold binding regardless of whether the key that triggers just-in-time-activation has mod tap?

[gusty remnant]

yo my keyboard isnt being detected and its stuck on update

what do i do

[dim sonnet]

First: Love to be able to finally color-highlight FN layers
Followup: Can we have some kind of Save/Load or Copy/Paste options to transfer the colors of a whole layer from one profile to another?

[empty tangle]

I've been wanting this as well

[gritty ginkgo]

60he

[upbeat cobalt]

What keyboard model do you have, what OS are you on and are you using the web build it not? Have you still had no luck?

[tidal minnow]

the white balance on lighting is still way off on my 60HE with the beta, it's a little greenish at low brightness and purple at max brightness

[gusty remnant]

Resolved!

[ancient grove]

does RGB fn layers work with tachyon?

[restive arch]

Yes

[upbeat cobalt]

Can you confirm if you have 60HE AVR or ARM?

[upbeat cobalt]

Same question as above, can you confirm AVR or ARM?

[tidal minnow]

arm

I feel like green min is slightly too high and max is slightly too low, it's pretty white at 50% but needs around 20% more green at max brightness and maybe 5% too much at low, I'll post some pics, the left/top color is FFF0FF, middle is FFFFFF and right/bottom is CBFFCB

and at 100%, 50% and 5% brightnesses top to bottom

obviously my values aren't exactly right but shows the shift from green to purple as the brightness increases

[upbeat cobalt]

@tidal minnow are you certain that this behaviour is different in the beta compared to stable? On my board, I'm able to confirm what you describe here. But when I switch between stable/beta firmware, the behaviour is exactly the same

oh whoopsie, just read what you said before with is still way off, I thought you had a similar thing to the other guy where the behaviour changed

Basically the RGB needs calibrated a bit better, I'm gonna see if I can get this improved, as it's pretty rough. It's especially blatant if you have all white RGB and use the breath effect 😳

[tidal minnow]

as long as you can reproduce it and it's not just me!

[frail wing]

I have encountered a situation where the RGB Layers randomly reset, and the 2nd Fn layer comes back (I delete it since I don't use it)

I'm not sure what the cause is though. Perhaps a bug with the auto-rgb turn off feature?

[wild shale]

@upbeat cobalt recently downloaded the new wootility beta. Should i uninstall the other stable wootility i had?

[upbeat cobalt]

Hmmm, probably best to keep it. Once the beta is complete and the changes are pushed to stable, I would recommend you to use the stable version only at that point. The beta probably won't be kept perfectly up to date with stable

[wild shale]

Ah allright, so it is okay to update the firmware via beta and later on with the stable version, right ?

[upbeat cobalt]

Yeah, once the current beta is moved to stable, it'll just be the same or newer version than the current beta, so you can just switch back

[wild shale]

Thanks!!

[upbeat cobalt]

@frigid gate just wanna move the talk into here

@cosmic tundra do you think all lock indicator behaviour should just be disabled when RGB SDK is active?

[wild shale]

@upbeat cobalt with my stable version (first picture) the downstroke is 0,2mm and the upstroke is 0,5 mm

Hence i think that on beta should be 0,20 mm and 0,50 mm

So i guess the rounding conversion is kinda off since i have 0,15 mm for the 0,2 mm and 0,55mm for the 0,5 mm

with the downstroke it decreased 0,05 mm and on the upstroke it increased 0,05 mm

I know you you put steps on 0,5 mm for major precision but the rounding conversion at least what i think is kinda off

[upbeat cobalt]

yeah, well, the issue with the stable version is that it doesn't really do any rounding. The slider is also not discrete, so you can have a range of settings which show as '0.2mm' but obviously they're not all 0.2mm. Partially down to the fact that the most precise value it can show is to 0.1mm precision, but with the new version it does 0.05mm. So with those in mind, it's only natural that the values would end up displaying differently with a properly discrete slider

[wild shale]

Yeah but shouldn't those from stability be in beta 0,20 mm and 0,50 mm ?

[upbeat cobalt]

No? Let's say the actual underlaying value for your downstroke is 0.17mm. In stable build that'll round up to 2mm, in the beta with 0.05mm precision, logically that'll round to 0.15mm

The sensitivity values which will show as '0.2mm' in stable will roughly be 0.249mm -> 0.15mm. In beta, what would show as '0.2mm' would be ~ 0.224 -> 0.175mm. So naturally there are going to be various configurations that won't round to the exact same value in the beta compared to stable

[cosmic tundra]

you can recreate caps and num lock with artemis or aurora but Fn or Win lock aren't possible for example

i'm fine with eiither but some users have strong opinions one way or the other

[upbeat cobalt]

Hmmm, maybe logical default would be disabling caps/num/scroll lock but keeping Fn/Key lock?

[cosmic tundra]

could this be user configurable or is that a big ask?

[upbeat cobalt]

It defo could be user configurable, but is quite specific so would be tricky to implement it in a nice manner UX wise

[cosmic tundra]

what about 1 global option for everything

"allow sdk to override indicator lights"

that way users can pick and choose if they want indicators or not, with the tradeoff being the Fn and Win lock being unavailable through Artemis and Aurora

[wild shale]

Perfect then, thanks for the explanation

[frigid gate]

If indicator lights overriding Artemis is supposed to be a feature, it needs some extra polish. Right now they only start overriding Artemis on indicator state change (regardless of what the state is), and stop overriding on profile change.

For example, if I create a solid red layer over the entire keyboard in Artemis and use the default Analog Profile 1, Caps Lock LED is initially red (even if Caps Lock is on), but after pressing Caps Lock once it alternates between blue and white depending on Caps Lock state — until I switch to another profile.

[cosmic tundra]

yes, i know: https://github.com/WootingKb/wooting-rgb-sdk/issues/58

[frigid gate]

My point is, the best solution is probably to revert to previous behaviour, because in its current state overriding isn't really useful anyway.
As for Win Lock and Fn Lock, wouldn't it be better to make them available via SDK (assuming it's possible)?

[upbeat cobalt]

I think for starters I'll make the standard lock indicators (i.e. Caps, Num, Scroll) become disabled when the SDK is active, leaving the Win/Key Lock and Fn Lock as is (as they can't otherwise be replicated with the SDK currently). Then can work towards a more flexible solution

[tiny panther]

is there an option to revert back from stable?

*to stable from beta

[tiny panther]

every since I upgraded to beta, my keyboard has had an issue where it randomly stops working and I have to disconnect then reconnect in order to get it back to being responsive. I assume this was due to the beta update because it wasn't doing this before so I wanted to test with a regression back to stable. If that's not possible I might have to use my backup keyboard until the new stable build is out I suppose.

[upbeat cobalt]

Assuming you have a Lekker board then you can revert by doing the restore process on the stable version of Wootility. It's under the Troubleshoot tab. It will reset your profiles btw. In what way does it stop working? Like is the RGB off or does it just stop inputting correctly?

[tiny panther]

input stops working entirely

RGB stays and doesn't change

[upbeat cobalt]

Are you able to change profiles on-board still? Which exact model do you have?

[tiny panther]

I have the razer SDK rgb stuff enabled and I have the wooting 60he

happens to me in overwatch and fortnite

which have razer chroma integration, not sure if it's the cause of the issue

[upbeat cobalt]

You can try disabling it to see if it appears again

[tiny panther]

Thanks, was able to revert to stable

going to try out stable for a while and see if the issue persists

if not, ill try swapping back to beta and report my findings

[upbeat cobalt]

Alright, let me know, as I want to make sure this issue gets sorted :)

[upbeat cobalt]

@everyone Hey, I just pushed out a lil firmware update, v2.6.12. This build makes it so that lock indicators (Caps, Scroll, Num) will be disabled when the RGB SDK is active @frigid gate this one is for you. I also fixed up some behaviour for when the RGB SDK is active and RGB layers are being used. Additionally, I fixed up a lil bug that was introduced to profile switching so it should be pretty solid now @astral owl

Also @tidal minnow I spent some time working on the RGB calibration and I've been able to make a good improvement to it. The changes are not included in this firmware build just yet, but if you want to try it out now you can DM me

[astral owl]

Yep much better for me now. No issues so far

[wild shale]

Gonna check it out today!
Have you seen the new github issue ?
I dunno why caps lock changed color to base color on RT display.

[upbeat cobalt]

I had a wee look but haven't had time to dig into it properly yet

[wild shale]

Ahh allright. I have another github issue regarding lightning and profile switching. Gonna make a video today

[upbeat cobalt]

With the latest firmware? I did a lot of fixups on RGB w/ profile switching so make sure you're on the latest

[grave sorrel]

does it include some fixes for the problem that switching profiles via shortcut sometimes does not trigger? https://github.com/WootingKb/wootility-issues/issues/184

oh shit I just saw you commented on it a month ago

[grave sorrel]

nvm that wasn't that issue but still that issue exists

I replied now

[wild shale]

Yeah it's only one kinda annoying.

First pick a RT display profile. Put it on max light.

Switch to another profile that has low light (like 1%) with FN + Enter.

Switch again to the RT profile on max light: you will notice that it will fully light the leds for a second after turning off.

Proof bug video

https://github.com/WootingKb/wootility-issues/issues/196

Hopefully, it should be easy to fix

[upbeat cobalt]

Thanks for the report, ye looks like something that should be pretty easy, is related to the stuff I was already fixing

[livid stag]

So uh... my RPG and layers are all over the place 😄

Didn't notice until just now, but updating to beta made Wootility (beta) not notice the FN1 and FN2 layers, even though the keyboard clear has them (adding them fixed this)

However more importantly this whole per-layer RGB is acting... oddly. I can't make the FN layers do the same thing as base layer. So if I tap FN, my entire keyboard flickers, because it can't/won't apply the trail RGB effect I use.

Ideally I'd like to just uh... disable the FN1 and FN2 layer being different, since I can't apply the base layer effect across all three. 😄

[livid stag]

(Reverted to non-beta and the issue seems to be gone)

[wild shale]

After installing artemis 2 im getting this

@upbeat cobalt

[cosmic tundra]

wootility won't work if artemis is controlling the rgb

(or anything else is controlling the rgb as far as i know, including chroma?)

[wild shale]

Is the league of legends plugin working ?

if i install artemis on wooting

[cosmic tundra]

if you're going to ask artemis questions, do so in that discord.

[wild shale]

Ok so

after uninstalling artemis

i cannot control the rgb via wootility

any ideas why?

@cosmic tundra

[grave sorrel]

why does this look like a python exception

[upbeat cobalt]

you should replug keyboard and restart wootility to ensure clean state for wootility connection after using 3rd party software

[upbeat cobalt]

I'm trying to understand what you're saying, but it somewhat sounds like what you were seeing is the intended behaviour? By default on the colour tab you won't have any additional layers, you still have them in remap, but you have to add them in the Colour tab to have different RGB for the Fn layers. Having RGB effects on an Fn layer wouldn't really make that much sense, well, at least taking the main RGB effects wouldn't make any sense (then if you had like rainbow wave on then the RGB layers would just show the same so be pointless), the idea did come up of being able to configure RGB effects per RGB layer, which I wouldn't necessarily rule out right now, but is out of the scope of this release

[livid stag]

So in the current stable build I have the trails effect applied on the base layer.

When I switch to Beta, having it apply equally across all three layers is no longer possible.

I can't opt out of per-layer, but I also cannot apply Trails to all three layers.
So the instant I hold down FN my 20% idle brightness turns into 100% immediately.

This makes doing arrow keys quite jarring, since my keyboard suddenly lights up out of nowhere as soon as I hold down FN for anything 😄

[upbeat cobalt]

You can opt out of per-layer, if you remove the layers in the colour tab then nothing will change when you activate that layer

The default configuration, where you just have the main layer, is supposed to behave exactly the same as stable (i.e. with no RGB layers)

[livid stag]

Lemme give it a try. Flashing to beta again.

This is post-beta update and closing Wootility and reopening.
If I touch FN the LEDs all flicker for an instant.

I can't get it back into the state where holding FN would make LEDs go to 100% though. I think I did that previously by adding the other FN layers in the list.

[upbeat cobalt]

Hmmmm, that's not intended behaviour, lemme have a wee looksie, I think I may have already fixed this in dev

[livid stag]

ARM board btw

[upbeat cobalt]

Ah yeah, I can replicate it on the current beta firmware but not latest dev firmware. I'll see if I can get the fix for that into the beta

[livid stag]

Feel free to PM me the DEV version if it's "safe" and I'll report any oddities. 🙂

[zinc yoke]

Hi! Am I safe to switch to Wootility v4.5 if im using a Wooting Two Flaretech? Im currently on 3.6.16 and for some reason it won't copy the codes of my profiles, doesnt copy anything at all. The profiles will get lost by updating to 4.5 i suppose?

[livid stag]

I would recommend doing a share on all of them for backup when doing an update.

[zinc yoke]

yup, that's what I'm trying to do. However after clicking share my clipboard is empty

[livid stag]

Hmm... very odd. I'm having similar issues, but I think those stem from me using a dev build, not the app.

Though I guess the Wootabase could be temporarily down.

[zinc yoke]

Might be the case. I haven't tried copying it before. I guess I'll wait some time and try again later. :)

[zinc yoke]

nice keyboard!

[livid stag]

Thanks! More pics over here to avoid derailing the channel 😄
https://discord.com/channels/167181566978555904/1070675891551739904

[wild shale]

Can you add an enter disable modkey?

@upbeat cobalt

Right now i have mod tap on hold for some keys on a game

and whenever i wanna chat since the hold is on 100 for the skills ingame it works but on chat it messes all up whenever i type

One enter to disable the mod tap feature, one enter to enable it again

https://github.com/WootingKb/wootility-issues/issues/198

[upbeat cobalt]

@wild shale Hmmmm, I kinda feel like that behaviour is more of a job for different profiles (or using e.g. Fn Layer 3 all regular bindings and locking to that temporarily).

As you're always going to have some special configurations for some keys in certain games and if you do something like this you're just going to be playing wack-a-mole to disable various things, when you should just be switching to a configuration that is clean for typing

[wild shale]

yeah is not the end of the world

[waxen oak]

Is per key rapid trigger (individual key sensitivities) getting added soon?

I like setting the left shift key to 0.15 but would prefer WASD to be 0.3+

@upbeat cobalt

[upbeat cobalt]

It's on the list, but not included in the scope of the releases coming soon. Currently focused on wrapping up stability things with this beta and the next update. Then the door will be open for more feature additions

[wild shale]

Can we have a little glimpse of the new features coming in next update ?

[upbeat cobalt]

FYI, I just pushed a firmware build, v2.6.13 that includes some bug fixes for this beta:

• Fix fn key causing RGB effect flicker when no rgb layers configured
• Fix gamepad mapping override blocking presses on other layers
• Fix DKS getting stuck when using 1.5mm actuation point on Flaretech boards
• Make USB connection more reliable on some machines
• Fix Snappy joystick to follow last input priority when opposing directions are equal

[upbeat cobalt]

You'll find out soon 😉

[upbeat cobalt]

Thanks everyone for helping out with the beta 😁 Closing the thread, further feedback on these changes should be shared in the #1088119875131682931 thread :)