Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for G815 keyboard #188

Closed
Nitram-L opened this issue Sep 22, 2019 · 27 comments
Closed

Add support for G815 keyboard #188

Nitram-L opened this issue Sep 22, 2019 · 27 comments

Comments

@Nitram-L
Copy link

Latest G815 needs to be supported

@hsegnitz
Copy link

I've got one, if it helps:
VendorID: 046d
DeviceID: c33f

@hsegnitz
Copy link

g810-led -dv 046d -dp c33f -tuk 1 -a 000000

worked for me.
Although not all keys went dark. The G1-5 keys, the logo, the "M1", the brightness switch and the four media keys stayed on.
Just built the project from source, using Ubuntu 18.04 LTS.

@MatMoul
Copy link
Owner

MatMoul commented Sep 22, 2019

@hsegnitz Thanks for the feedback, it's a good start to add support to G815.
I'll try to implement all keys for this keyboard.

@hsegnitz
Copy link

Happy to help, let me know if I can try out something for you - assuming you don't have the keyboard at hand - I also have windows 10 on the same machine with the new logitech software that was required to run this keyboard. The previous software (which was fine with both G512s) didn't detect it at all.

@pearsonk
Copy link
Contributor

I started some work on this, but I tend to start with the native effects, which have changed up a little bit regarding their methodology. Even so far as having inverted the byte used for logo vs keys.
Interesting that they are supporting the older method (32-bit per key), so that may ease integration on that front. My dumps from GHub show them supporting a new method that is a bit more compact (URB control messages specifying RGB once followed by up to 13 keys for the color to be applied to). Also, a previously unchanging byte in the data section now has a different value, so there was a bit of refactoring necessary to support it.

I'll hop back on GHub and cut in a few more usbpcap dumps and post. Can probably tackle this in stages. I'll post a PR for the protocolByte refactor soon, and follow up with the native effects after I complete and perform some initial testing.

@pearsonk
Copy link
Contributor

Added several captures to PR MatMoul/g810-led-resources#4

@MatMoul
Copy link
Owner

MatMoul commented Sep 23, 2019

Yeah, after the dumps of @pearsonk and his last PR #190, we can try to add g815 in g810-led...

@pearsonk If you work on it, you have the whole week before I get involved.

@cornernote
Copy link
Contributor

cornernote commented Dec 18, 2019

I would love to get rid of the flashing rainbow effect from my new keyboard, and just have a flat colour. :)

I am running Ubuntu 18.04 and I have a G815.

I tried both the master and develop branches from this repo.

My installation looks like this:

sudo apt install libusb-1.0-0-dev
git clone https://github.com/MatMoul/g810-led.git
cd g810-led
make bin LIB=libusb
sudo make install

Which results in this error:

Matching or compatible device not found !
makefile:85: recipe for target 'install' failed
make: *** [install] Error 2

I also tried this:

./bin/g810-led -dv 046d -dp c33f -tuk 1 -a 000000

But it gives the same error:

Matching or compatible device not found !

UPDATE

Just needed to reboot. :)

Also need to run g810-led with sudo

@cornernote
Copy link
Contributor

I made a branch so I can run g815-led, without sudo and without needing -dv/-dp/-tuk.

Some of the keys dont map, like logo and multimedia. And I'm not sure how to get the M/G-Keys working. I looked at some of the dumps from @pearsonk and tried changing some of the bytes in Keyboard to match what I thought was showing in the dumps, but it didn't work.

https://github.com/cornernote/g810-led

@cornernote
Copy link
Contributor

I'm trying to get the following groups to work:

  • logo
  • multimedia
  • gkeys
  • backlight key

I got some data from wireshark under windows running the logitech software (ignore the spaces, they just help me read it):

set logo to d58287
11ff101f d2 d58287 ff0000000000000000000000

set multimedia keys to d58287
11ff101f 9e d58287 ff0000000000000000000000
11ff101f 9b d58287 ff0000000000000000000000
11ff101f 9d d58287 ff0000000000000000000000
11ff101f 9c d58287 ff0000000000000000000000

set gkeys to d58287
11ff101f b4 d58287 ff0000000000000000000000
11ff101f b5 d58287 ff0000000000000000000000
11ff101f b6 d58287 ff0000000000000000000000
11ff101f b7 d58287 ff0000000000000000000000
11ff101f b8 d58287 ff0000000000000000000000

set backlight key to d58287
11ff101f 99 d58287 ff0000000000000000000000

When I try to change the logo to d58287 it sends this:

11ff101f d2 d58287 ff0000000000000000000000 # via logitech software
11ff101f d2 10000201 d58287 0000000000000000 # via g810-led

I'm not sure how to change g810-led to move the colour to the left.

All the other key groups are working normally.

@cornernote
Copy link
Contributor

I stumbled across the python version of this program here https://github.com/MatMoul/g810-led-python

I was able to use the wireshark data to alter the script to work with all the keys. I pasted the code here: https://gist.github.com/cornernote/82972cc307985df29f3ddca214a4dc39

Things worth noting:

  • Data without the ext (aka short data) now uses 8 less digits, removed from the right, however the packet length is unchanged.
  • The updateKeyboard() data changed from 11ff0c5a to 11ff107f. The new one was required to save anything using the short format, which included the logo, multimedia keys, g-keys, and the backlight. The old one saves the long data format, the new one saves both.

@cornernote
Copy link
Contributor

cornernote commented Dec 20, 2019

I pushed some more changes to my branch, which is in PR-202. It's a work in progress, but I'm a bit stuck as this keyboard seems a bit different to the ones in there now.

All the RGB commands work properly on this keyboard, with the following 3 issues remaining:

  1. I wasn't sure how to map the keys (logo, multimedia, backlight, gkeys) to the right codes, so I just overwrote Keyboard.h. It will mean every other keyboard is broken except the G815. Is anyone able to help me adjust the key codes the correct way? - see Keyboard.h diff

  2. When I run g815-led -g multimedia 000000, only some of the keys are turned off. It seems that when packing multiple key+color into a single data packet that a commit with 11ff107f is required after each packet. The code indicates other keyboards allow multiple packets to be sent before a final commit, but the G815 does not seem to support this.

  3. G-Keys - I can't find the code to unlock the G-Keys from the F-Keys.

@cornernote
Copy link
Contributor

Seems it actually broke everything.

I left the original working changes in a PR-203, and I moved the broken code to cornernote/g810-led/tree/develop-g815-keygroups. You can see how badly I did looking at the compare.

For now I'm going to give up on the non-working RGB keys and try to focus on making the G-keys work. I have had success with a G105 keyboard using sidewinderd. I have created issue-40 there, and I will post my findings as I go.

@gfauredumont
Copy link

Any news on this ?
I have a G915 which would be configurable with this PR ;)
I haven't touched any C++ in 15 years bout would be willing to help: just tell me what to do !

@cornernote
Copy link
Contributor

@gfauredumont the G915 is different, but from looking at the source code the RGB commands already work. Or are you talking about the G/M/MR keys?

@MatMoul
Copy link
Owner

MatMoul commented Feb 20, 2020

One of my g810 has a ded led key, I'll buy a new g815...
I hope that I can merge and finalise the support of new G keyboard...

@Nitram-L
Copy link
Author

Great news. I guess there will be a big progress soon.
Please let me know if I can test something.

@yawor
Copy link

yawor commented Mar 13, 2020

@cornernote you're right that the G915 is different. It won't work right away using the current code, even with your work on G815. Check my comment in #198.

@MatMoul
Copy link
Owner

MatMoul commented Mar 13, 2020

Just received my g915 and i hate the keys...
But I can now work on this new keyboard...

@cornernote
Copy link
Contributor

cornernote commented Mar 14, 2020 via email

@yawor
Copy link

yawor commented Mar 14, 2020

@MatMoul @cornernote it seems that all you have to do with G915 to get G815 is to connect it to PC using USB cable instead of the wireless dongle :). Of course reported name is G915 and the USB product id is different (C33F for G815, C33E for G915). Other than that it should work the same.

The difference between wired mode and wireless mode is that in wired mode the 2nd byte (device index, target id, whatever it is called) in HID++ protocol data is ignored. But in wireless mode it has a meaning. Value 0xFF is for communicating with the dongle itself and to communicate with the keyboard it needs to be set to 0x01.

@MatMoul
Copy link
Owner

MatMoul commented Mar 14, 2020

Sorry, I've received the g815...
@yawor Not at home now but I surrely used lsusb to report the model...

@MatMoul
Copy link
Owner

MatMoul commented Apr 26, 2020

Hello everyone,
The g815 branch is ready to be merged.
Just a few more tests with old keyboards to make sure it doesn't break all.

@MatMoul
Copy link
Owner

MatMoul commented Apr 28, 2020

I've published the v0.4.0 with g815 support.
FX isn't supported now.

@MatMoul MatMoul closed this as completed Apr 28, 2020
@cornernote
Copy link
Contributor

Woohoo, the G keys, media keys, etc now have lights! :)

Well done @MatMoul

@serious-angel
Copy link

serious-angel commented Jan 21, 2021

@MatMoul @cornernote it seems that all you have to do with G915 to get G815 is to connect it to PC using USB cable instead of the wireless dongle :). Of course reported name is G915 and the USB product id is different (C33F for G815, C33E for G915). Other than that it should work the same.

The difference between wired mode and wireless mode is that in wired mode the 2nd byte (device index, target id, whatever it is called) in HID++ protocol data is ignored. But in wireless mode it has a meaning. Value 0xFF is for communicating with the dongle itself and to communicate with the keyboard it needs to be set to 0x01.

@yawor May I ask how did you get that information? I might try investigate the issue further.

@jayofdoom
Copy link

I just got a G915; I'm happy to run any debug commands that might be helpful in getting it working over wireless.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants