Watch buttons do not recognize G-Keys

[forTtoo]

Hi, thanks a lot for your work, everything but the 3 G-keys is working for me.
Using "g933-utils watch buttons" is not triggered by any of the G-keys. Instead it stays on loop.
"g933-utils get buttons" gives me "Enabled" as it should.
I have a new g933 with firmware version 98.3.27. I would like to know if it still working for you (and on which firmware).
Merry Christmas btw :)

[ashkitten]

hi! i just did some minimal testing and according to my notes i don't think i've ever actually seen get_buttons_enabled() (raw 11 ff 05 1x) return anything other than 1/true, and the functionality of the request was just an assumption after all... good catch! now i'm not entirely sure that there even is a function that returns the enabled status of the button passthrough, but no matter.. for your situation, just use g933-utils set buttons true and it should enable it c:

[forTtoo]

I have found a solution now, and there is a bug in your code i guess.
You say that x in line 168 of notes.txt

[05 2x] # enable_buttons
# Turns button reporting on (01) or off (00)
- [01] : [01] # From logitchgaming_startup.pcapng
- [00] : [00] # From logitechgaming_shutdown.pcapng

is unspecified or unimportant, but

g933-utils raw 11 ff 05 21 01 # = g933-utils set buttons true (a)
g933-utils raw 11 ff 05 2d 01 # (b)

(a) seems not to work, but (b) does which is taken from package number 76 of logitechgaming_startup.pcapng.
Just typing this command enables the buttons and especially allows using "g933-utils watch buttons".

Now this suggests that there could be more problems with possible errors with not so unimportant Xs, but i have not looked further into that.

[ashkitten]

i don't know how it's possible that the second nibble of byte 4 would affect that... are you sure you're doing those commands? in this hid++2.0 specification draft, it states the fourth byte second nibble refers to the software identifier:

A number uniquely defining the software that sends a request. The firmware must copy the software identifier in the response but does not use it in any other ways

i have not in my testing seen this to be untrue, and the command g933-utils set buttons true does work for me...

[forTtoo]

Of course i can only speak for myself, but the above solution fixed it. My guess is the firmware since my headset is new.

[forTtoo]

Another problem coming up in this context is the microphone mute button, which is not working after enabling the G-keys. The volume changing wheel still works, but the headset seems to forget about the toggle button.
Can you confirm this behavior?
I get the exact same situation when i kill the Logitech software in Windows.
This table sums up the different states that are equivalent:

• Windows | default | Logitech software running | kill software
• Linux | set buttons false/disabled | no equivalent | set buttons true/enabled
• Working Keys | default Gkeys & MicToggle | custom Gkeys & MicToggle | Gkeys readable by watch buttons, no MicToggle

Notice that the default state in Linux is buttons Disabled (this conclusion just comes from observing the behavior of the keys), although "get buttons" always returns "Enabled", as mentioned in the second comment.

[ashkitten]

yes, indeed it seems you are correct. when button reporting is enabled, it appears that the headset does not handle microphone muting on its own.. i'll be adding a "listen raw" subcommand to hopefully help kickstart the implementation of host-side button handling..

[forTtoo]

A workaround i am using now goes like this.
Assuming you have your g933 as the default source, you can bind one Gkey to
pactl set-source-mute @DEFAULT_SOURCE@ toggle
Then you would just use the Gkey instead of the MicButton which is then obsolete.