#🤖│community_dev
1 messages · Page 24 of 1
would that replace #archived_wootility_feedback and/or #🤖│community_dev?
Hmmm, not sure if it would replace it, as there's always a place for more casual discussion like in Discord, but can imagine it'd be helpful for things that require a more connected thread of discussion that don't fit well into the mold of a github issue
No don't think so. The only problem I have with discord is that discussion is really volatile and fleeting. So if you have a question you can't really look for existing answers quickly. It's also hard to join in a discussion if you're not online at the time it's happening
But then when you look at GitHub issues, it's too technical and complicated
I think a solid way around that would be to have a full category for support, where individual issues could get their own channels if necessary. I think that having channel creation as a subthread option on a main thread is a great usage pattern.
not really what discord Was designed for an theres a 500 channel limit. while sounding much i think theres way too many issues someone could come accross. a dedicated forum would be the better solution
forums offer better search, better management of threads and would also show up on google after some time.
Hi folks, would someone here be interested in working on some pure web (Web HID) demos/projects? - it seems to work pretty well and has less friction than requiring people to install native tools to try it out
what is it supposed to do? the demo dose not seem to work.
hello everyone can someone tell me how to switch between all its profiles because I can switch between two profiles?
please go back to the other channels, people have answered you multiple times #💬│general #archived_fortnite_double_movement
they didn't even ask in the right channel at all
i cant move when i have the double movement enabled, i have removed the wasd bindings and i have lock input method as mouse
but it works if im in another tab
need help
have you disabled ignore gamepad input?
yes
run app as admin (temporary fix)
full solution here: https://github.com/WootingKb/wooting-double-movement/wiki/Troubleshooting#-when-fortnite-is-out-of-focus-you-can-get-double-movement
would it be possible to implement this ? https://twitter.com/meat/status/1342006601767669760
I just implemented this in my homebrewed Moonlander firmware so that the LED animations in my keyboard use perceptual rainbows instead of basic HSV/RGB, and the difference is incredible. Thanks Björn! https://t.co/dLuU57nAmm
It's a different color space for the keyboard
Is anyone here who could help me to find a suitable design for the new features of the wooting double movement app? Not so happy with my current design... looks to "blocky" imo if this is a word in eglish 😅
But I had to make the window a bit wider since there wasnt just not enaugh space on a 1080p monitor to display all fields 🙂
@limber timber very cool. I have some ideas to make the ui better. I’m a bit busy, maybe I’ll have something this Thursday for you
sounds good 🙂
Any other features or functionality you want to add?
Why is there a second column for bindings?
In Fortnite you can bind a direction of movement to two different keys. Until now you couldn't do that with the double movement tool enabled.
This is useful if you have bindings like me, where u can't press some key combinations while strafing / moving if u have only one key assigned.
Cool good to know
prob. found a better design. btw. ignore the labels from the sliders... couldn't find a good name for them until now^^
wrong channel. #archived_fortnite_double_movement would be ur way
Hey! Does the RGB SDK not support the Lekker yet? wooting_rgb_kbd_connected() is always returning false for me.
prob cause of the not implemented device ids
idk if anything changed to the w2 rgb handling on the keyboard firmware part
you could theoretically modify the sdk and recompile it and see if it works
@placid ledge not yet right?
No, not yet, there were many changes to the firmware so I'm going to have to do big changes
Alright! Thanks for the info. I'll keep an eye out for the eventual SDK update.
Wish I read this before trying and finding out for myself
trying the SDK on the lekker, i keep getting initialised with 0 devices, is that intended?
following this guide:
https://dev.wooting.io/wooting-analog-sdk-guide/c-guide/
right, scrolled up a bit, indeed not yet, will keep an eye out ^^
theres no sdk for the lekker yet iirc
was going to look into making my AHK script work using the sdk, but it'll have to wait
i think simon said he had a branch of analog working with lekker tho
maybe well have to wait for the god to descend into our plane of existence
one day wooting will get more developers
I'll make sure I release the analog SDK update with lekker support when we release v4.1 this week (aka prob tomorrow)
RGB SDK will be later

Which sdk lets you change profile
also I'm guesing wootility doesn't use these sdks since it works and these don't
it doesnt cause the effects are stored on kbd and execute there
the sdk is for sending manual rgb stuff like color arrays etc so programs like project aurora can run custom effects from the pc side
hmm, I guess I'll do that myself then
Was aiming to release new analog SDK update today but ran into some CD problems so gonna have to push it til tomorrow
All the stuff is merged so you can compile it yourself if you want (either develop or release/v0.6)
smh
I got got by windows
@grizzled wolf Analog SDK update is out for lekker, if you're on Windows it should prompt you for update in Wootility, otherwise you can update manually from github: https://github.com/WootingKb/wooting-analog-sdk/releases/tag/v0.6.0
are the functions the same or was there big changes
yup
i shall build a shrine for u simon
should anything happen visually after clicking on the "start analog sdk update" button in wootility?
It should indicate that it's loading
the installer is on that download link so you can manually update
about to push lekker wootility v4.1 out, the analog sdk updating is working on that. Seems like it's a little buggy with v4.0.2
ah
works great
well, time to make my ahk script in c# then
nah ahk wasn't precise enough
and besides it'd bug in some games like 6siege
i'd want to make it work with the sdk, then maybe propose it as a feature for wootility
as a way to use analog input in games that don't support it
by basically rapidly pressing/releasing the key?
yes pretty much
wouldnt that require software running again
which means it prob wont be in the wootility itself
well, if it runs "in the keyboard" it'd be more efficient
instead of having a very precise loop on your machine
given one is already needed to scan the keys
also requires some processing time then
definitely, if it's turned on, although the loop itself is very chill on the processing side of things
i was also psure someone already made such a thing
it's why i need precise sleeps in AHK, otherwise it nukes my cpu with a bajillion loops per second lol
for w1 and w2
i did make a script that worked a while back
but i want to make it in c#
since ahk's performance sucks
the script should work on the lekker/w1/w2 too out of the box, if you're curious to try it out
cant even click the link
yes
I've got some initial RGB sdk support in the works
I think I have enough for a beta version, just not sure how to let yous take it for a spin
not sure it's safe enough to just push out the firmware update including the tweaks I had to do
Hmmm, well, the changes are pretty small, so only thing they can break is the rgb sdk usage itself, shouldn't have any impact on anything else
Got a surprise for ye bois
You'll need to update to latest firmware v2.2.3 that I just pushed
Nothing has changed with the interface, only thing I changed was adding back the deprecated wooting_rgb_reset which allows the SDK to be a drop-in replacement in Aurora
This is just a basic initial implementation, so take it for a spin and let me know what you run into
NOTE: If you've making use of wooting_usb_send_feature to send commands outside of what the RGB SDK wraps, then be prepared for it to not work with Lekker. Nearly all of the commands/reports were rewritten for Lekker

😏
oho, i made the script work, legit lost hours on sending input with c# x)
oof, rip
i'll upload a clip real soon
so ahk or c# now
👍
noice noice
atm it's smooth enough that i actually can't tell it's not normal analog
my lekker is setup to have no keys bound at all in the profile i've been using, so it's all from the program
oh @placid ledge do you know if aurora still requires color corretction values with lekker?
ik that for the w1/w2 u had to tweak them a bit in the settings for better accuracy
dayum, sounds pretty sweet
should be aight, I think everything sent to lekker will go through the internal gamma correction
so it should match colours set through wootility *
so i can just remove the scalar settings to the default
aye, I think so
ok ya a quick test would have told me
looks way better without the adjustments for w1/w2
Awesome
Google Drive
video processing rn
that's with 5ms as the pulse cycle
i'm not sure how i'd share the program itself
not mp4 
i rarely use visual studio x)
or, i do but only for unity
let's see if this works
on the wootility i've made a layout with nothing bound (edited the first default layout)
the program asks for a cycle duration in ms, by default it's 20, but 5 or so works quite well too
then while it's running it'll mash the WASD keys to get analog-like input
not the cleanest code but hopefully close enough, let me know if there are doubts
as far as the program logic goes:
i set a cycle duration
a key is pressed, i press it
i keep doing so until the analog 0-1 value is higher than the percentage of time i spent pressing the key during the cycle (eg: if a cycle is 20ms and i've been pressing it down for 10ms, then the analog value is 0.5 or greater)
afterwards i release the key until the cycle ends
to improve reaction speed and whatnot, if the current analog value is greater than the total time since the cycle started, then i reset the cycle
so i don't need to wait for the cycle to be done to reset it if i press the key further
that however is a bit iffy with very short cycles since in theory slightly pressing down the key continuously will be the same as holding it down, but in practice i like how it feels
Thanks for the RGB SDK update! ❤️
When I call wooting_rgb_direct_set_key, it turns on the backlight for the entire keyboard - is that supposed to happen? I was hoping I could control the backlight for just one key, and have the RGB fx I configured in Wootility continue for all the other keys, but maybe that isn't possible.
AFAIK not possible but i shall see what the master himself has to say about it
oh pog rgb sdk update
thanks
did I do something wrong, I'm using the lekker support branch
Did you try running your binary as root?
oh that works, what do I have to do to fix that, I have udev rules and I'm in the input group (wootility works w/o root)
wootility doesnt work the same way the sdks do afaik
I don't know, @placid ledge pls explain ¯_(ツ)_/¯
the sdk doesn't go through libusb?
Nice, is that getting backported to legacy keebs as well?
With this RGB SDK build it does it for all of them
So should help with the udev rules you were trying to set up with only giving permissions to the relevant nodes?
I guess plugdev is the group usually used to give users access to hidraw, though I don't have that group so I'm not sure how many distros still use that or have any rules installed for it
IIRC both Wootility and analog SDK use hidraw as well
IIRC plugdev is generally on Debian based and stuff like arch uses input
ah ok
# Wooting Two Lekker Edition
SUBSYSTEM=="hidraw", ATTRS{idVendor}=="31e3", ATTRS{idProduct}=="1210", MODE:="0660", GROUP="input", TAG+="systemd", ENV{SYSTEMD_WANTS}="wooting-lekker-xinput@1210"
# Wooting Two Lekker Edition update mode
SUBSYSTEM=="hidraw", ATTRS{idVendor}=="31e3", ATTRS{idProduct}=="121f", MODE:="0660", GROUP="input"
then my rule needs updated
Well see that should just grant access to all hidraws and thus work 🤔
i dont think arch does that, things like the steam controller need rules to function too
KERNEL=="hidraw*", ATTRS{idVendor}=="20d6", ATTRS{idProduct}=="a711", MODE="0660", TAG+="uaccess" steam controller rule
And if woooooootility works then it's all good
yeah on arch /dev/hidrawX devices belong to root user/group, so the input group does not give access to them, you have to make a rule to do that, but for some reason the rule that works for wootility doesn't work for this
I figured it out, the subsystem has to be usb not hidraw
Interesting
ofc wootility wont work with usb, so both are needed
So it's just like how it works for legacy woots 🤔
Interesting, I'll have to take a deeper look
# Wooting One
# Wootility/Xinput
SUBSYSTEM=="hidraw", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="ff01", MODE:="0660", GROUP="input", TAG+="systemd", ENV{SYSTEMD_WANTS}="wooting-xinput@ff01"
# Analog/RGB SDK
SUBSYSTEM=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="ff01", MODE:="0660", GROUP="input"
# Update Mode
SUBSYSTEM=="hidraw", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2402", MODE:="0660", GROUP="input"
# Wooting Two
# Wootility/Xinput
SUBSYSTEM=="hidraw", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="ff02", MODE:="0660", GROUP="input", TAG+="systemd", ENV{SYSTEMD_WANTS}="wooting-xinput@ff02"
# Analog/RGB SDK
SUBSYSTEM=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="ff02", MODE:="0660", GROUP="input"
# Update Mode
SUBSYSTEM=="hidraw", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2403", MODE:="0660", GROUP="input"
# Wooting Two Lekker Edition
# Wootility/Xinput
SUBSYSTEM=="hidraw", ATTRS{idVendor}=="31e3", ATTRS{idProduct}=="1210", MODE:="0660", GROUP="input", TAG+="systemd", ENV{SYSTEMD_WANTS}="wooting-lekker-xinput@1210"
# Analog/RGB SDK
SUBSYSTEM=="usb", ATTRS{idVendor}=="31e3", ATTRS{idProduct}=="1210", MODE:="0660", GROUP="input"
# Update Mode
SUBSYSTEM=="hidraw", ATTRS{idVendor}=="31e3", ATTRS{idProduct}=="121f", MODE:="0660", GROUP="input"
This is what I have now and it works for wootility and the sdks
What do you do on exit to restore the rgb, my effects just freeze and wootility stops connecting until I replug it
wooting_rgb_close() is what I've done
is there a way to see if the keyboard is currently using an analog profile or the digital one?
that way i can check for it to turn my program on/off
dang I was hoping I could use the sdk without the effects disabling so I could port my g910 code but i'd have to make the ripple effect in my code
there prob is some undocumented usb feature for this
we can change profiles aswell within software and the wootility also retrieves the current profile iirc
thats whz ud use openrgb or aurora
then i cant use sdk without breaking that
breaking what
project aurora for example supports the w2(which is basically the lekker with the new wrapper) and u can make custom effect plugins or just layer existing effects
oo i see
i cant use aurora, openrgb doesnt have lekker yet, but when either of those are connected I cant use my own wooting rgb program, it breaks those
why is the lekkers vid not the same as previously anyway, that has caused many issues
it used to be 03EB now its 31E3
Yeah, Wooting is all grown up now with their own ID
they had an id though, they just changed it
so are old ones getting updated via firmware or staying the same
Tried just updating the vid/pid but there must be other changes, not sure the original author has a lekker, and I don't know much more than what I already did https://gitlab.com/ShayBox/OpenRGB/-/blob/master/Controllers/WootingKeyboardController/WootingKeyboardControllerDetect.cpp
thats why u write an aurora rgb effect plugin
and then only use aurora
general rule is only 1 thing has rgb control. either the wooting itself or any 1 program using the sdk
still windows only
and openrgb doesnt support w2 or le/he yet
unless you want to fix it
no im very happy with aurrora myself
been using it since i got my w2
also forgot ure linux user
sowwy
id just joink code from the rgb sdk like they did for the w1 controller (openrgb)
i mean they didnt even clean up the copy&paste nicely
well one person can only do so much, https://gitlab.com/CalcProgrammer1/OpenRGB/-/merge_requests/420 (nice, got the 420th pull)
also unsure if thez thought this would work for the one and two without even including the two matrix for either keymaps or leds
I can't link the dynamic library to my main.cpp. It shows error like this. I put the dylib in the same directory as main.cpp. Is there anything else I should do to link the library? I am kind new to C++.
also my test code is here
im unsure... while i have a macos vm i never really used it and its not setup for dev so i cant even test/help you
i mean the easiest way would be open @rpath if thats even a valid thing in macos
It's not a valid path. It appears in the dylib and I am not sure if I should change it.
imma quickly boot my vm and see how fast i can setup a dev env
i assume u use vs2019 for macos?
just a normal text editor
sorry will take a bit cause macos somehow isnt v11.0 and wont let me install xcode despite being 11.1
so imma quickly run the outstanding update to see if itll let me install xcode
I think I solved the problem. I have use an additional "-rpath ./" flag to solve the problem.
Never heard of this flag. Another cool thing to learn.
its a rust thing
but if that solves the problem 👍
had to soemtime setup macos for compiling anyway
strangely, today if i have nothing mapped to a key, WootingAnalogSDK.ReadAnalog will always return 0
It's in a different file
the script in r6siege
the weapon animation derps a little, possibly cause i used the digital layout
interestingly it's not due to the input cycle, regardless the movement is as smooth as expected, movement is quieter as expected
and aiming/shooting/etc work as expected, unlike true analog that disables them
would be curious to know how this looks like in third person, maybe the derpy animation turns out to be an advantage
I can't get any info about my keyboard 🤔. It is not detected during SDK initialization. I wonder what was wrong this time. It's a lekker keyboard.
btw @placid ledge the pc file for rgb sdk linux needs to be updated from -libusb to -hidraw so pkg-config can generate the correct flags
I didn't think of that, also tony does wooting game detection work on lekker, I can't test it
I wanted to know cause I'm making my own for linux in cpp but I can't get send feature with the values used in game detections code to work, idk if its a me problem or lekker changed those
prob new lekker codes
Lekker changed those, or that's what we've been told
no idk if we will ever know

@placid ledge pretty please gib the new stuff
thats whats inside the lekker wootility
and the codes seem to still be the same
unless theres support for w1/w2 left in the wootility
Hmm maybe it's just my code then, ill have to test the game detection on windows
currently repacking the asar with some debug code that doesnt exist to see if those codes are what were looking for
Your ideas a lot better than my Wireshark idea, I don't know how to use Wireshark
ya so
command 23 loads a profile
params are 0 based
for the 4 profiles gives u a range of 0-3
magic word is 56016
magic word?
and command 39 with parameter 0 hands u the loaded profile
psure the usb lib has the magic word
ya checked the rgb sdk and it builds the magic word itself
so a regular wooting_usb_send_feature(23, PROFILEID, null, null, null) should work
Oh I got it to work... I have to feature reset first, and load rgb isnt loading the rgb, but the profile is switching
and wooting_usb_send_feature(39, 0, null, null, null) should return the active profile
0 based again
hope that info helps you
naughty tony
Code if anyone wants it https://gist.github.com/ShayBox/dc478de774bac80b36ea9e468032ef4d
Its 7am and I'm tired, when I add a config, a pkgbuild, and build binaries I'll make a repo
well, I dont think windows or mac use x11
thats why ud make seperate files for the different platforms which export common function names to use in the main file
yeah I could, and maybe I will, though process names also change between platforms
onlz need to include a singular example line in the config and explain how it works
a redo of the profile switcher has been long overdue
especially in a lang that can compile a bit better than the cs app cop has
I believe windows and x11 have triggers for this stuff too, instead of polling
windows def does
I'm not great at C, my friend helped me figure out how to get the length of an array
ya i even made it use the event handler in my fork
unsure why cops tool still loops
one small thing tho
on app exit u should also maybe load the first profile it started with
the app never exits
wot
its always polling forever
@empty cobalt make sure you have the latest version installed with lekker support https://github.com/WootingKb/wooting-analog-sdk/releases/tag/v0.6.0
ok @quiet root I made a repo and boilerplate for win32 https://github.com/ShayBox/WootingProfileSwitcher
stuff needs to be done like the win32 code, macos code, reading a config file instead of the config in code
looking good
altho i thought more smth like include <windows_funcs.h>
and then call them to retrieve the active process etc
so that main c is mostly the same code and u dont have too many ifdef
if the code gets too long I will be moving each platform to its own file
i think moving them is a good decision now already
cause instead of looping id recommend using event hooks in x11 and windows
which would just require a single function call and no loop
you can do that if you want I moved it, I have no idea about any of the win32 stuff yet, I'm done working on this for today
imma go sleep in a few
I'm pretty sure I was using v0.6 SDK.
Hmm actually the code updates the rgb profile, but it doesn't load an effect, it keeps it static
Seems you now need an additional RefreshRgbColors (29) at the end
v0.6 Plugin is not getting compiled by CI. The latest release on Github is v0.5. @placid ledge I guess that's why the plugin can't detect the keyboard.
it is on releases
just as prerelease so it wont show without opening alk releases
latest release in repo overview only shows latest release marked as release not prerelease or beta
Nah, I was talking about the analog plugin
@empty cobalt The plugin has it's on CI but it's also built as a submodule of the analog SDK CD. wrapper/sdk/libwooting_analog_plugin.dylib inside the mac release tar of the analog sdk
(I'll update the instructions) The state of the analog plugin repo is a bit of a mess, I think I'm going to merge it into the main repo to cleanup the structure
Thanks. That info is really helpful. I now run into a problem where "wooting_analog_uninitialise()" will throw out "EXC_BAD_ACCESS" error. something is already released when I call the uninitialization. Could it be a rust feature that I don't need to actually uninitialize the SDK?
Hmmmm, that's weird, I'll have to take a closer look, but at least with the Analog SDK it's not the end of the world if you don't uninitialise. So you can omit it for now to prevent the error hitting you
so simon does using the rgb sdk, while the kbd is in tachyon mode, impact performance?
Without a doubt it will impact performance, the question is by how much, which I'm not really sure of the answer.
like thats how i used my old w2 since i never used built in rgb
and ya how much is the question i wanted to ask
Given that it's sending RGB information for the keyboard to update based on, it will result in it doing more work than it would otherwise with just tachyon & no rgb
ya but it doesnt need to do any processing for actual effects
its basically setting everything as sent from the host
Yeah, that's true, so it should be fairly minimal, but ultimately it has to do more work than with nothing. I'll put it on my list to investigate alongside with tachyon and see if I can get an idea for you what kinda impact it gives
that would be dope to know
another dumb question is
if i only set the colors once
and then not send any rgb commands
it should be static right
and not impact the event loop
yeah should be, the rgb will only update when the frame buffers are changed, so if you aren't sending anything then it shouldn't be doing any additional work
noice
(and while RGB SDK is "initialised" it disables any processing from the built in RGB fx)
yea
had aurora crash a few times when i first got the w2
wait but why is wootility static rgb disabled in tachyon then
would maybe be helpful to have some on-board way to reset rgb sdk initialisation in the case of an SDK usage not properly cleaning up and it getting stuck on
Although, that's somewhat solved by replugging or restarting the app
nah, I was thinking more of something like some key combo to uninit sdk incase it gets stuck on
imo thats too much code bloat for a simple replug/reboot of the app
yea true
what you mean by this?
as in if tachyon is enabled
u cant select static rgb in wootility and have it show
unless im dumb and it does that
when tachyon enabled it disables rgb fx, giving you the static rgb
no worries
Just realize "len" in wooting_analog_get_connected_devices_info() is the amount of devices. I always thought it was the memory length. I give it 48 when I have only one device. 
why verbose naming is so important
Kevin has been so nice to export an STL file for the keyboard feet for y'all: https://github.com/WootingKb/wooting-design/tree/main/common
Thank you @drifting wadi
@quiet root should I base the windows off your fork or is there something else better
then yes its the focus change eventr i used
forks are for eating
I just realized wooting has scroll lock and pause backwards to every single keyboard ever
I'm not adding windows to ProfileSwitcher, it's just pissed me off for the last 5 hours, I can't get cmake, gcc, or msvc to work, developing on windows is a shitshow, someone else can add it if they want, i'll leave the boilerplate in for it
and whoever decided to name the sdks differently on each platform, thanks
I made a stuff that scroll the page based on how hard you press the key.
The only problem is that I can't have the system ignore the original input lol
It's about the same speed as me scrolling the mouse wheel
Is it possible to set the keyboard to send nothing? Like a remap feature? As you can see in the gif, the program worked before the actuation. It will be perfect if the key does not actuate or send nothing to the system. 🤔
since ahk and other macro programs suppress the key handling further down the line your code can too. just make sure to have a keycombo to disable/enable it otherwise itll scroll when u wanna type smth
unless
u use pgUp pgDown for this
then enabling/disabling can even be done with ctrl+pgDown/ctrl+pgUp
since i dont know any widely used software using that combo
I don’t think there is any software that can suppress the keyboard event in macOS. Lack of api for this type of thing. I know there is an api in windows tho. It would be cool if it is a hardware feature.
then ull be pmuch reimplementing a lot of wootility code except the gui drag and drop
cause ud load the keymap from kbd
modify the data
and set a new keymap
obviously this would go horrible as soon as u remap urself in wootility while its running
I just played with wootility and found a switch to disable to the whole digital keyboard in analog profile(never checked them out before). It does what I want but for the entire keyboard.
I guess wootility already has had the feature I want but just not for individual keys.
wow, even better now. I just found out the gamepad mapping override. My problem is fixed now.
It disables digital key when there is a gamepad bind.
My entire numpad is filled with useless gamepad uparrow now lol
so u can only scroll up
or do u use the analog keymap
instead of reading the pressed key
ya so u purely go on analog mapping
instead of figuring out what key was pressed and where that is on the kbd
Yep.
unsure how well this works with remapping
since u can technically have the same key somewhere else
It is not like remapping but disabling the key.
no i mean
Remapping to a doing nothing key is like disabling the key
if u remap lets say num9 (which u could use for scroll up) to num7, num8 and num9
so that the entire top row of numpad is num9
and u do the bottom row (num1, num2, num3) to be num3
will it work with any
or does it break
cause idk how exactly this impact with the analog sdk
The analog sdk only reports scancode and a float. The scancode will always be the same(?) no matter how I remap the key.
so its fixed to physical keys
Yep
sad
The OS will find out what that scancode means. Thats why there is keycode.
problem is
maybe i wanna remap my keys
since u can map em per profile
meaning that scrolling up and down would be physically bound not bound by the real mapping
its a flexibility issue i guess not a real performance problem
Yep. Maybe there should be a callback for analog sdk to notice events such as switching profile. So the scroll action will only work on some profiles.
such event is never send to the pc tho
so ud basically poll the kbd profile
personally would prefer a keymap to scancode reversal aswell
so that for example
when i put my pgUp and pgDown to ctrl, shift for some games
i could still use the software
There is no such api to poll the profile either.
and use it when normally browing aswell
yes there is
u can send raw keyboard feature thingies
we have all the codes
.
the rgb sdk has wooting usb ya
rgb users may want to know when the keyboard switches profile
so far this is smth ur software should implement
poll current profile
and wait for changes
I don't quite understand this. Can you be more specific?
i play some games with a flight stick
i use this on left hand cause i subjectively feel like i have more control and am more precise
so i remap pgUp and pgDown for ingame scrolling to ctrl and shift
so my right hand doesnt need to move ever
but normally my keyboard is not remapped
i do entertain the idea of scrolling faster the more its pressed down
but i couldnt use the software since it means id be fixed to 2 physical keys
and not the mapping
ideally a software would read the mapping, fetch the relevant scancodes and check all of them
at least imo
I see. The scrolling is not caused by pressing pageUp and pageDown. It is caused by sending a system event of mousewheel up and down.
It is faking the system I am sending such events. When you bind the scrolling on ctrl and shift, if you don't disable the original function of ctrl and shift, it will cause two events the same time.
no
i mean
i know how u do the scrolling
but the software reads scancodes
so u have to push smth on ur kbd
i usually use pgup and pgdown
cause they also work besides scrollwheel
but its a fixed speed
obviously being able to use the same keys in 2 different keymaps is better imo
actually nvm ANYTHING i said
if u remap it
it should reassign the scancodes
im just mega dumb today
Hmmmm. I am so confused now lol
i mean scancodes are what the os gets
if u remap all ur keys to be a
then the entire keyboard is filled with the scancode for it
theoretically that is
Scancode is the physical position of key on the keyboard if I remember correctly(?)
Let me quickly test it
Nope. Remapping in wootility also changes scancode.
normally scancodes are fixed yes
but the remapping means it would be able to change the "physical position"
I admit that my method is a little bit hacky. Xinput is not a thing in macos, so who knows what the os gets and how the os thinks it is. But that's why we may need a feature to disable the individual key. Setting it to not actuate.
But still report the analog data
Yep. But it could cause potential problems in windows in some applications tho.
if gamepad is disabled no
but another idea is
check remap
if theres empty keys for remapping
I don't think there is a lot other than F13-F24(?)
I remember these is a video from linus tech tip showing off how one of its editor uses the entire keyboard to send macro. I should rewatch it.
Also, the reason why I use numpad 9 and numpad 3 to be my scrolling up and down function is that 9 is pageUp and 3 is pageDown if I disable the numpad. But for macos, the numpad cant be disabled.
he uses a seperate usb device
macos also still uses f13-f24
due to old mac keyboards having it
I compiled and installed wooting-rgb-sdk on mac, but how do I get pkg-config to recognize it
nvm the mac folder and makefile is missing a pc file
@floral crane did u forget to include main.h in the source?
nah you dont have to include the header file of the same filename
ya this is why i asked
msvc will def need a header
plus
making a header for this simple thing isnt even hard
there should be a header for every file, win/mac/linux.c all import main.h
main.h doesnt exist in the repo
oh hmm
lol
how did it compile
i made a main.h for me
do what you gotta do
oh wait i dont have any headers in my code... i must have deleted them for somereason
i installed hackintosh on my laptop so whenever I figure out how to detect window name on mac i'll add mac support
what config format should I use, just simple key=value, yaml, json, or something else
idk if process names can have spaces on any of the platforms
for win ill prob make it so it checks the list for title and proc match
Anything so long as it's not yaml
json if anything
having it recognise process name and window title as valid matches is probably best, there's cases where one process name is shared between multiple things, and window titles are too generic
{
"titles": {
"Binding of Isaac: Repentance": 1
},
"processes": {
"isaac-ng.exe": 1
}
}
hows this
why not make them both be in the same list
{
"Binding of Isaac: Repentance": 1,
"isaac-ng.exe": 1
}
I can do this
btw if you want to switch the code over to cpp to make it easier to code or read feel free to
I just hadn't needed anything in cpp yet to switch
Rewrite It In Rust
no thanks, i'm not maintaining wooting bindings too
well the only real issue actually
seems to be c not liking the fact that the wooting_usb_send_feature func isnt exported
at least msvc and the dll dont like to talk to each other because of this

did you import the header
i get no complains for that
oh linker issue, cant find the dll
i checked exports
its not in there
i think this might be why cop used a custom compile
wait its not _wooting its just wooting
interesting
it adds that to all funcs
oh ur right its not there
ya but it doesnt get exported to the PE header

the linker uses the .lib file which also doesnt contain it
its a pretty win specific thing
nice
i mean i could try implementing disassembling the exported funcs that use it and try finding the function offset dynamically
but at that point i can also submit a pr to correctly export the funcs
@placid ledge pls fix wooting_usb_* funcs not being exported to dll and lib
be my hero
pog
idk if that increases much with the usb feature stuff
but should all too much
the most increase would come from actual logic and json reading
only took 114lines of makefile

only
I assumed you were gonna make a vcxproj like wooting not a makefile 
also noticed this tho
na this is more flexible imo
plus still works with nmake
whatever im good with it
so /shrug
easier for me
i mean
with vcxproj we can prob get like 1mb or so
idk how to cut out all the standard shit with that
im better with make files
same but not that good 
i mean in msvc u just hand /NODEFAULTLIB to the linker
and then specify the libs u actually need manually
tomorrow ill already make the windows part working
and then hope we can also get the send usb thing working on win
which isnt necessary for testing luckily

oh shay if u got the time could u try compiling my windows-build branch on linux?
to see if i broke linux support or not
still good
noice
Hmmm is is possible to use the sdk to send key inputs 
Why do you have a main.h?
For all the other platforms to import for the main wooting function
no
Well it should be!, that'd be useful for making cross platform macros with full key support
Make every key on my function layer say a line to the bee movie
I guess that works, still kinda be cool
So many features to come, when's the next update, I don't remember
og I found it, its on the website, end of May, so maybe soon
i wouldnt think so for macros
but maybe
also shay
pls reinvite to repo
i saw it yesterday
which was a bit late i think
Can we get a way to be notified when the keyboard has consumed rgb commands? Or do the rgb set commands already block until the data has been written?
finally is working
while keeping the filesize damn small
so far it went from 4kb to 5kb
Json, om is gonna write a tiny simple parser instead of a lib, we're only using a tiny part of json
I think I'm gonna have a function for each platform that returns the path for the config file of that platform
We're using such a small part of json it would be smaller to just write a parser function into a struct array
im unsure how much it actually takes up to use these embedded system parsers
You want max performance so use https://github.com/simdjson/simdjson
Don't show this to r* Krappa
a single function with no extra code needed even slimmer, possibly, depending on what om makes
ya but what if it fucks up parsing
i just used cJSON array parser
and it increased the size by a hand full of bytes
not even kb
so its not a huge risk
since its known to work
and slim af
how can you mess up parsing
ye
cause for proper json parsing u also need some form of tokenization
and not just put data into array like caveman
especially since json doesnt need newlines and also doesnt have strict indent rules
true
is your working code pushed, i don't see much code, I thought it would take more than this to get the title
na windows has nice apis for this
ill need to check getting process name tho
not too sure what the most effective way is
but yes the windows-build branch is working code to print at least
its not yet switching profiles due to missing exports in the rgb sdk
syte 
dw hes a hero he'll save us
well when you're done make a pr or commit it directly, there's been a few commits since your fork so you'll have to merge a few changes
👍
the includes are a mess lol
not too bad
uh... when i rebased just now onto ur repo/master
you might be using a mix of tabs and spaces here btw
there's an extra #include windows.h in your win_native.h
its not extra
thats the standard windows header for win api shit
i have an even weirder problem tho
trying to use strrchr
but apparently its an unresolved external symbol
it does fetch the proc name now
altho i basically implemented ghetto strrchr
good enough now
now to wait for simon
oh windows has a windows.h, I see why you renamed that then
ya just to avoid confusion
fixed that yesterday btw
PR submitted
the exe turned out to be 6KB so far without any json
if this gets merged imma start work on implementing cJSON to main.c
since we only really need it in there as its not platform specific
Yeah no point in making a new file for such a small program
I'll look at it when I get home
@floral cranethe way u do profile updating for proc and win titles breaks as soon as the order u match in is match, no match since that causes the profile to default to 0
its why i implemented concurrent matching of both process and window title
Each platform has different sizes of things to match, and the they're all different,
Windows has executable name/path and window title
Linux has window name, window class, window title, and will have executable name/path
Mac will have executable name/path, window title, and possibly window class and window name if they provide those attributes
If the user doesn't provide a match in the config that matches update_profiles match variable it doesn't do anything, it just updates the last_match and skips updating the keyboard
nope does exactly what i predicted
rn for windows it matches win title then proc name
but since they are seperate calls it means if u dont use process names it just defaults to profile 0
the only solution i can think about thats flexible and cheap to implement is making update_profile return a 1 if the update was successful and 0 otherwise
actually no
also wouldnt fully work this simple
implemented a smarter approach so other functions can check if a match was already found and abort if necessary
Hmm that's probably a better way, I was gonna make the input an array and have it just pick the first successful match
Which way should we go for
both ways work
and both do the same
like they both pmuch would abort on the first match so its more of a programming comfort thing i guess
havent even thought about array arg tbh
lmk when your pr is ready to be merged, or merge it when you're done, also how would we get the active profile from the keyboard
oms parser isnt gonna work, you can add the cjson if you want
👍 thats a job for tomorrow me tho

tomorrow me might also find out why atexit wont compile on windows
btw how smol is the linux binary
noice
i always cry when i look at how small the linux makefile is
pains me to see what msvc needs to do the same
ya but thanks to msvc pmuch only offering nodefaultlib option
it then needs 20more options to add back the shit u want
ok how do I get the value from send_feature...
custom sdk build that exposes a read_result function so we dont have to redo finding the hid handle for the correct keyboard
I wanna learn how hidapi works and make my own lib but thats too much work
already added the necessary functions to my fork testing rn after i fixed the improper include of unist.h u added to main
oh yeah
wish there was a better solution, even the sleep didn't completely fix it
so i had to split the imports to their OS headers (which get included first anyway) and then use ifdef to differentiate between win32 and the rest
I still keep closing every program cause my close shortcut gets spammed thousands of times when closing isaac
ud have to sleep between all commands
the sleep is just to give time for all keys to be released before messing with the keyboard if the switch was caused by a key press like alt f4, win, or alt tab
ya but the keyboard freezes very briefly after every command
so should it actually not have the keys buffered as released yet u basically spam it with 4 hid requests
which take priority
safe to say im super confused rn
sending feature report 11 and doing an hid read right after should give us the profile since thats what the wootility does
but for some reason is always just comes back empty
@quiet root sleeping between each call also doesn't fix it
shay would u be ok with static linking of the rgb sdk?
Ey, what you boys up to
I read the source and I have an amateur question. How do you exit from start_listening()? The while loop is always true and there is no break(?)
So the rgb_reset() is not needed?
technically is but it wont make the kbd die
imma implement exit handlers later today anyway
Cool
You can also use the kill command to send a posix signal to end the process
Its very common to see infinite loops in these kinds of situations
Do keep in mind to put some delay in the loop :)
And use some kind of poll() instead of check_event();sleep(1);repeat();
tell that the linux man
i only do windows
and use the recommended getmessage event loop
My program eats a lot of resource when doing while loop like this. Trying to figure out why and learn from others.
Well according to docs XNextEvent blocks until an event is received so it's gucci
didnt even see that ngl
Unless your operating system intervenes or interrupt handler is triggered. Your process will be able to run infinite loops as fast as it can. As you most often don't need it running millions/billions of times per second, you can signal the operating system to put your process in the blocked state. Either to be activated after some time has passed(sleep) or some event being registered. This allows the operating system to use that thread/core to execute some other code (or just let it idle) in the mean time.
Nope its a syscall
also need to fix sleep calls in the code
I see. So that’s why there is a call for XNextEvent()
const char *last_match = "";
Keep in mind with strings in C, you need to reserve one more spot for the null '\0' character.
Have not looked if handled correctly, but from experience I know to be very diligent with that.
sleep fixed
i dont freakin get it
im so lost with hidapi reads
even when i compile in the rgb sdk as static lib
the reads come back all 0
but wootility still reads the current profile fine
what are you doing to read?
void wooting_usb_read_response(uint8_t *buff, size_t len)
{
int result = hid_read(keyboard_handle, buff, len);
#ifdef DEBUG_LOGs
printf("Read_timeout result \n");
for(int i = 0; i < len; i++ )
{
printf("%c", buff[i]);
}
printf("\n");
#endif
}
the first 3 or 4 bytes
are like the ones the wootility reads
but after that its all 0
where the wootility has a 1 and then the profile index
thats wootility
i get the first 4 bytes the same
wooting_usb_send_feature(GetCurrentKeyboardProfileIndex, 0, 0, 0, 0);
uint8_t buff[256] = {0};
printf("%d\n", buff[0]);
wooting_usb_read_response_timeout(buff, 256, 2000);
thats the code to read it
and GetCurrentKeyboardProfileIndex is 11
im so confused
are you certain the 4th byte is the same with what you're getting?
Cus 5th byte is the length of the data following
If the command is being called correctly it should always be 5: 1 6: profileIndex
are you reading this with wootility closed?
yes
The 4th byte is response code following this struct:
typedef enum {
UnknownResponseResult = 0x66,
SuccessResponseResult = 0x88,
OverflowResponseResult = 0x99,
ErrorResponseResult = 0xFF,
} ResponseResult;
Hopefully something I'm saying can help 😄
Hmmmm
The only thing I can think of is that this response somehow isn't coming from the intended command i.e. the getCurrentProfileIndex
so id need to implement a read into the send_feature to basically make sure the read is from that command
Maybe, but with the code you gave I can't imagine how it would end up with the wrong command unless you doing multithreading (which is also sending commands)
already tried both MT and MD
to rule out multi/single thread
both do the same tho
oh wait
it might be the fact im using the debug flag
ok no even after removing the MDd flag completely it still does it
hmmm, very strange, have you tried to see if any other commands work?
Can't really think of anything else that could be going wrong, the fact that you're getting the SuccessResponseResult indicates that it's definitely getting responded to by a command handler, but what makes it weirder is that the GetCurrentProfileIndex doesn't do any logic, just assign the len to 1 & profile index after that
same with the nearby command handlers, they should all at least give some sort of response
what result do you get from the hid_read?
i now reduced the app to purely main
and it now only send the feature
and reads
not even checking connection
still 0
very strange
lemme quickly build a dll for that
256
so it did read 256bytes as instructed
literally cut out everything from the entrypoint function that could interfere
only the 2 sdk calls
Hmmmm, looks like it should defo work to me
if you weren't getting a valid response that'd be one thing that'd indicate some clear problems
but getting a success response that's just empty is really strange
ya i even checked if wootility does the read different due to the node-hid wrapper
but its pmuch the same
i even thought it might a problem with the read not being able to write to the entire buffer but init with all 1 shows it fills it with 0
if you set it up to keeping reading responses til it can't get anymore what do you find?
dies in what way?
I don't mind it being a static Liv, but you gotta figure out how to do that on Linux, I've never done static libs
so as soon as i try to read again it just doesnt do anything
ah
Hmmmm, really struggling to think of more avenues for debugging
what if you try some other commands, do you some response body in those?
getAnalogProfileMainPartCommandHandler = 13 you should get an UnknownResponseResult. So 4th byte = 0x66
ye 7 won't return anything
Hmmmm, very weird
GetRgbProfileCore = 50 should defo give you data
it kinda seems like every command being run is pointing to the same thing, are you able to observe that ReloadProfile is actually doing the reload?
no, is a tricky one to test as wootility will clear any unsaved changes on exit.
hmmm, something very fishy is going on then
i found out what caused it
🤔
"call a reset"?
huh, that's weird
not always
like if i start and kill it a few times
i only get 1 or 2 responses
waiting a bit inbetween always returns data
some of the commands the sdk uses will have responses, so maybe if you implement the response reading in the wooting_usb_send_feature then there should be no hanging responses
I think I left a basic read commented in there
tbf i think my testing problems were a result from aurora
not properly exiting via the rgb sdk
oh, could be
ya
so if i spam run the program
sometimes it doesnt return data
but just even a second waiting inbetween
fixes it all
hmmm, sounds like the issue is coming from the read response not being from the command you sent
if you always read response after sending command then that shouldn't be a problem
Have got some changes planned for the communication as well which should hopefully make that situation a bit better as well. Mainly around multiple apps communicating with the keyboard causing undefined behaviour sometimes
pr it back to base
wooting-usb.h is completely useless on win
They need to be set-up with this stuff https://github.com/WootingKb/wooting-rgb-sdk/blob/feature/lekker-support/src/wooting-rgb-sdk.h#L14 to get properly exported on windows
ik
is that what you did? if so you can PR it in
forged it and already fixed it
also pushed the read functions
might add a separate function for sending a feature command and reading the response
sounds good
so
uh
i did the thing
and uh
hm ya
it just doesnt
were back to all 0
how can this be all 0
i dont understand
ya so i now tried another wooting board and clean boot without aurora doing rgb stuff first to eliminate that possibility
no dice still
all 0
syte silently bricked your code
ya prob
we went too deep
but tbf im at the same point as simon
idk why it shouldnt work
im just waiting for wootility 4.2 
@placid ledge wouldnt it be more appropriate if the get functions wouldnt be feature bytes but hid reports
In what way? You mean using the hid report id system?
Pretty much all of them make use of parameters, even tho they be a bit subtle
