wootingkb / wooting-rgb-sdk

Customize colors on Wooting Keyboard #WootDev

Wooting RGB SDK

Customize RGB colors on your Wooting Keyboard for developers and hobbyists.

Getting Started

This project will allow you to build your own DLL and customize the source code. Looking to directly get started with the DLL? Check out the downloads and guides in our developer portal.

Prerequisites

Windows

Visual studio

Linux

Dependencies:

libusb-1.0, libusb-dev, hidapi, libhidapi-dev

Additionally, you will need pkg-config, git, make and gcc to compile the Library.

Mac

Dependencies: hidapi, make, pkg-config, gcc (or clang through xcode) If you have homebrew set up then this command should get you sorted with most dependencies:

brew install automake pkg-config hidapi

Building / Installing

Debugging

You can add DEBUG_LOGto the preprocessor flag to build with debug logs enabled. For Linux / Mac add:

make CPPFLAGS=-DDEBUG_LOG

Instructions

Windows

git clone --recursive https://github.com/WootingKb/wooting-rgb-sdk.git

Open the visual studio project and select x64 (64-bit) or x86 (32-bit).

Now hit the build and find your DLL in the folder depending on your configuration.

64-bit

\wooting-rgb-sdk\windows\x64\Release\wooting-rgb-sdk.dll

32-bit

\wooting-rgb-sdk\windows\Release\wooting-rgb-sdk.dll

Linux

Clone the Git Repository:

git clone https://github.com/WootingKb/wooting-rgb-sdk.git

Change into the Linux Directory using cd wooting-rgb-sdk/linux and simply run make.

If you wish to use the Library yourself it might be useful to install it to your System. Do so with sudo make install

Mac

Clone the Git Repository:

git clone https://github.com/WootingKb/wooting-rgb-sdk.git

Change into the Mac Directory using cd wooting-rgb-sdk/mac and simply run make.

If you wish to use the Library yourself it might be useful to install it to your System. Do so with sudo make install

Example

For examples check out the wootdev website.

Keyboard Matrix

Keyboards

Keyboard matrix with rows and columns:

Wooting UwU

• Green Boxes: Lightbar LEDs
• Yellow Boxes: Analog Keys + LED
• Blue Boxes: Digital Buttons

The UwU isn't able to have an ideal matrix representation, it is not ideal when it comes to how it relates to the physical layout. So it is recommended to use proxy representations that are more relevant to what you want to visualise and transpose that onto the UwU matrix.

e.g. If you want to light up a single lightbar LED and move it around the lightbar, then you may want to make an array representation of the lightbar [(0,0), (0,2), (0,4), (0,6), (1,6), ... (1,0)] and apply your logic around that, then transform onto the 2D matrix.

License

This project is licensed under the Mozilla Public License Version 2.0 - see the LICENSE file for details.

wooting-rgb-sdk's Issues

Add device ID generation with results consistent with Analog SDK

This will help match up devices when using the RGB & Analog SDK simultaneously

support osx

hi I'm using the wooting one as a midi controller, and would like the lights to interact with midi signals. Obviously there is some osx interface into the lights as wootility is able to modify them, but I don't see support for that here. Do you have plans to add the rgb sdk for osx? If not is there some way I can interact with it anyway?

Incorrect Caps lock behaviour when SDK is controlling lighting

When enabling caps lock, they key turns the expected color as set in the wootility. When turning it off, the color reverts to the profile the keyboard is on, instead of the color set by the rgb sdk. This sounds more like a firmware issue, but i didn't know where else to make the issue.

This is a very minor bug but it's slightly annoying so i'm submitting it 😄

wooting_rgb_reset allows no further Commands afterwards

When issuing wooting_rgb_reset(), all further color-change commands are ignored.
Is this intended ? (It wasn't the case before).

I am using a Wooting One

EDIT: Additionally, not running wooting_rgb_kbd_connected() on start will also let all changes fail silently

State of the RGB SDK

It’s great to see that there’s so much activity here, but I feel bad that I haven’t been able to keep up with the developments. There’s some major things lacking and overall I’m not happy with the structure of the RGB SDK. I wanted to share some thoughts here and start a discussion about how we can make it better.

This post is just about the RGB SDK, there is also an Analog SDK post here. If you want to know why we split the Analog and RGB SDK, please read this gist.

What is wrong with the current SDK?

I think it’s easiest to start with some things I think are problematic with the current SDK.

1. It’s too hard to use, a developer needs to define their own set of functions and load the DLL.
2. There’s no good feedback if there’s something wrong.
3. It’s not clear if the developer should add the SDK to its project or if the user installs it.
4. There’s no good way to update the SDK, user nor application side.
5. If you create something cool, how do you share it?
6. It uses the same interface as the Wootility, so it can potentially conflict.

What are some options we can do?

From talking to you guys I’ve learned some options, current and new. I want to list some and talk about how they could address the issues. I’ll refer to the current setup as “1-DLL”.

1. Improve 1-DLL and “install” (add) it developer side

This is the current way. With just a DLL it seems impossible to update automatically. Interfacing and feedback could be improved. Sharing would require sharing full applications.

2. Improve 1-DLL and “install” (add) it user side

We attempted to add this to the Wootility, but we didn’t push it through. The Wootility can install the DLL and also update the DLL. Interfacing would be a little bit harder, since you need to find the installed DLL first. API changes will be very hard, because developer will be responsible for checking versions. Shares also requires sharing full application.

3. Split SDK in two: logic and interface

The user install the logic part and the developer adds just the interface part to its application.

The interface part wouldn’t have to be updates regularly and if it did it can take care of API changes. This also allow defined interfaces per language for easiest interfacing.

The logic part will be maintained by the Wootility and thus easily installed and updated. Sharing would still application dependant

4. Use the Wootility itself as the core

This feels like the end-game for the RGB SDK. It will make it easy to add different interfacing options: DLL, sockets, REST. It also removed potential conflicts. Another big plus is that we can add other configuration options, like changing keyboard mappings. This will morph the RGB SDK in a Wooting Config SDK.

Sharing could be done via a plugin system.

What to do?

Here is where you come in. I would love to get feedback on what you want to see from the RGB SDK and how you think would be the best way to achieve it.

I think one of the things that need to happens for sure is to not have the application add any logic, just the interfacing.

When it comes to the Wootility: even though I like the option, in its current shape it would require close sourcing parts of the SDK. We don’t want to take a step back. If we go this route we’ll open source the whole USB configuration part. It’s already a separate project, so it shouldn’t cause too much workload.

I’m most excited about the possibility of growing the RGB SDK into a Wooting Config SDK to allow full control for your applications.

That’s it for now. It’s a big post, but I feel it’s also a big decision to make.

Wootility inaccessible after running something using the SDK

This is a bit weird. If I run anything using the SDK (No matter if develop or master Branch), the Wootility will stop recognizing the Keyboard, even if the SDK Program exited cleanly, with the Wootility having been closed before running the Program.

So, it goes like this: Wootility recognizes Keyboard -> Close Wootility -> Run SDK Program until finished -> Wootility does not Recognize Keyboard upon reopening

Sample C++ Code:

#include <iostream>

#include "wooting-rgb-sdk.h"

int main() {
    std::cout << wooting_rgb_kbd_connected() << std::endl;
    std::cout << "G'day" << std::endl;
    wooting_rgb_close();
    return 0;
}

However, the SDK will continue to recognize the Keyboard. It's only the Wootility that doesn't.

Wooting 2HE, LE and 60HE crashing on FW 2.5.9

So I have updated my W2HE to 2.5.9 and ever since that it started to hang/crash when the RGB SDK interacts with it.
Sometimes I also got it to crash by changing RGB in the Wootility and some others had the same issue here

I have then tried the same on the LE which lead to similar results.
The 60HE seems to crash when playing around with RGB on the Wootility.
Crashing occurs anywhere from 30seconds to 1minute from my latest "testing"

This doesnt happen when using FW 2.4.14

Add opt-out to gamma mapping when using `array_set_full`, `array_set_single`

Allow override of select keys

Allow setting colours of keys, for a progress bar on UwU as an example, without setting the others so they remain using the original colours and effects.

Keyboard can not be found on Linux

We try to look for the keyboard by filtering for the Usage Page, but hidapi doesn't return them correctly. I remember reading somewhere that you can pick different USB drivers, but I don't have time to look into. Would appreciate if a linux user can investigate.

Edit: I'm assuming this is not a problem for OSX, but not sure yet

Initialize rgb buffers with current rgb values

Would be nice if on connecting the keyboard (wooting_usb_find_keyboard) and resetting the rgb (wooting_rgb_reset_rgb) the buffers where initialized with the actual color values on the keyboard. That way wooting_rgb_array_change_single can be used to change part of the keyboard.

wooting_rgb_close does not call wooting_rgb_reset_rgb for every keyboard

This resets the colors on the currently selected keyboard, leaving any others stuck

Please attach dll files in releases as assets

I'm attempting to automate a process that downloads the latest dll files from this repository.

Currently, the release posts just link to the files manually instead of them being added as an asset which makes it a bit harder to find them programmatically.

Although I could work around this, it would be really nice to get this in order.

Please consider fixing this 🌝

help

i updated my pc and now my movement doesnt work

Add a function to reset a key in the array buffer

Currently you can only reset single keys with wooting_rgb_direct_reset_key or the whole keyboard with wooting_rgb_reset.

It would be nice to have an array function here, analog to the painting functions.

USAGE_PAGE out of spec

The value of the define "WOOTING_ONE_CONFIG_USAGE_PAGE" are not in the valid range of FF00 - FFFF.

wooting-rgb-sdk/src/wooting-usb.c

Line 10 in 746670e

#define WOOTING_ONE_CONFIG_USAGE_PAGE 0x1337

Determine whether device is ISO or ANSI

Hello,

For the Wooting Artemis plugin I'd like to be able to detect what kind of physical layout the device has.
From what I can tell this is possible because Wootility shows the correct layout depending on what firmware you've flashed, either ISO or ANSI.

It would be nice if this could be added to the RGB SDK so that we know whether the extra ISO-only LEDs are present or not.

Move hid_write calls to a separate thread

So, it turns out that calling hid_write takes a long time in the Wooting RGB SDK, which results in wooting_rgb_array_update_keyboard blocking for quite a while.

It would be nice if the hid write calls were separate in another thread, so application developers don't have to worry about multithreading.

wooting_rgb_kbd_connected function always returns 0(false)

Code:

int main()
{
	while (true) {
		std::cout << wooting_rgb_kbd_connected();
		// check for keyboard is connected
		if (!wooting_rgb_kbd_connected()) {
			std::cout << "Waiting for keyboard connect...";
			while (!wooting_rgb_kbd_connected()) { Sleep(1); }; // wait for keyboard connect
		}
		std::cout << "Wooting keyboard connected!";
		POINT p;
		if (GetCursorPos(&p))
		{
			RGBTRIPLE result = getPixel(p.x, p.y);

			int r = result.rgbtRed;
			int g = result.rgbtGreen;
			int b = result.rgbtBlue;
			
			std::cout << r << ", " << g <<  ", " << b << endl;
		}
	}

	return 0;
}

RGB buffers are shared between devices of the same interface

Discussed in the discord, making an issue for tracking.

When a device is partially updated, the colors applied to the hardware might have been meant to the other device. Each device should have its own color buffer within the SDK.

Linux compiling issues

Hi can you give a hint how to compile this package on Arch linux?
When I run make I get this error:

src/wooting-rgb-sdk/linux (git)-[makepkg] % cc -Wall -g -Wl,--no-as-needed `pkg-config libusb-1.0 --libs` `pkg-config hidapi-libusb --libs` -shared -fPIC -Wl,-soname,.0 ../src/wooting-rgb-sdk.o ../src/wooting-usb.o -o libwooting-rgb-sdk.so
 
/usr/bin/ld: ../src/wooting-usb.o: warning: relocation against `key_code_limit' in read-only section `.text'
/usr/bin/ld: ../src/wooting-usb.o: relocation R_X86_64_PC32 against symbol `key_code_limit' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: bad value

libusb (1.0.23-3) and hidapi (0.10.1-1) are installed with pacman.
The kernel is: 5.9.14-zen1-1-zen #1 ZEN SMP PREEMPT Sat, 12 Dec 2020 14:36:44 +0000 x86_64 GNU/Linux

Implement something like an SDK "ping"?

As I was sitting here looking at my Wooting keyboard, I realized that it's been stuck with an RGB pattern that a script of mine drew on it.

The problem is, I killed the script a while ago, so its shutdown handler never called the reset function and never reset the LEDs which also renders the A1, A2, A3 and Mode keys useless until I unplug the keyboard or reset it using another script that utilizes the SDK.

What I'm trying to suggest to resolve that is quite simple:

Maybe introduce something like a ping function to tell the keyboard that something is still actively using the SDK. Once there is a ping timeout (after like 1 minute?), automatically reset the keyboard.