VOID RGB USB Headset Support

[SethBarberee]

I attached the gist from the ckb-dev-detect that has the VOID RGB in it. Is there anything else that you need to add support for the RGB's on this device?

EDIT: https://gist.github.com/SethBarberee/f958fe641a6803c331aa680429968e1c

[ghost]

I attached the gist

Except you didn't :)

[SethBarberee]

My apologies, I did forget to attach it. I updated the comment above with the gist. I'm sorry about that!

[ghost]

Thanks.

References #2.

[kafeinnet]

Hi,

I just acquired the very same headset. Feel free to ask if you need testing or troubleshooting !

\fab

[tatokis]

Off the top of my head, I am thinking something along the lines of implementing another headset device class in the driver, which only claims the "control" endpoint used for lighting and input.
Not sure how to handle the audio stuff, maybe an easy way to pass through data to the virtual input device?

The GUI doesn't need to receive any of the audio, which would simplify this whole thing. Although, honestly, it would be quite difficult to implement such a thing without any of us having the actual device to test with.

I'll have a look if I have some free time.

[SethBarberee]

I don't mind testing the code for this feature when you have something together.

The GUI doesn't need to receive any of the audio

Totally fine with me, Pulseaudio handles it well anyway. All I want is color choice for the VOID.

[SethBarberee]

Is there any documentation or code that I could look at to help accelerate the development of this feature? I would just like to help in anyway that I can.

[tatokis]

@SethBarberee Sorry for the late reply.
I pushed a commit which sets the basics for a new device type (mousepad).

You can use 25e1d3d as a base to create another device 'class', headsets.
There's probably more that's not in that commit though, you'll have to find it yourself.

Daemon documentation can be found here https://doxygen.frickler24.de/ckb-daemon-full/

[SethBarberee]

I implemented the code that you sent to me in this fork. CKB detects the headset and assigns it to a /dev/ckb/ node. However, it does have three broken pipes upon initialization. I attached a gist with the output of ckb-daemon. Any help would be appreciated.

Issues that still have to be fixed:

• When attached to CKB, the headset cannot be detected in Pulseaudio
• The broken pipes

[tatokis]

@SethBarberee I thought I had replied to this, but apparently not. Apologies.

The broken pipes most likely indicate that the daemon is trying to talk to the headset using the wrong endpoint. Since the dev detect script reports 4 endpoints, you most likely have to edit usb_linux.c and tell it to use the right one.

Out of curiosity, can you cat everything inside the /dev/ckb2/ node?

In order for the headset to be detected using pulseaudio, you either need to not claim the usb audio endpoint (is that even possible?), or tell the daemon to use the kernel's userspace input driver to create a virtual headset like what is currently done with keyboards and mice.

[SethBarberee]

The broken pipes most likely indicate that the daemon is trying to talk to the headset using the wrong endpoint

That's good to know! In the lsusb gist that I attached from above, lsusb shows that the last endpoint is the USB HID Device while the rest are audio. If I'm not mistaken, the keyboard and mouse are the opposite because the daemon catches everything except the last endpoint.

In order for the headset to be detected using pulseaudio, you either need to not claim the usb audio endpoint (is that even possible?)

This would probably require rewriting the endpoint capture code to look for a headset (idk if mousepad behaves the same way).

Out of curiosity, can you cat everything inside the /dev/ckb2/ node?

I'll try to attach a log of the /dev/ckb2 node later when I have time.

[SethBarberee]

@tatokis
I tried to delete every endpoint except the HID endpoint (0x84) however it did not look like it worked. Basic GUI implementation such as displaying the device and its info is working. An overlay for the VOID would be nice for the display but that can be worked on later. Endpoints is the only hurdle IMO stopping this from being able to work. I'm still a beginner in C so it's a struggle.

[PurpleIsEverything]

Really would love to have this working for my void wireless, willing to provide any logs needed to get it working.

[SethBarberee]

Cool, thx @Shadowkitten! If you don't mind a ckb-dev-detect report would be great! I'm trying to get detection working on both Wired/Wireless. (And also see if another of my ideas might work)

[ssube]

I've recently switched to linux and ckb-next as my daily driver and would love to get this headset working (and maybe the stand, too). It looks like there were a few ideas, is that fork from above still worth running or do the patches need to be cherry-picked? I'd be happy to build and test changes, although my C/++ is pretty rusty.

ckb-dev-detect dump here: https://gist.github.com/ssube/57ecc00f14ed1431bf581475e1ccb134

[tatokis]

@ssube We are currently busy trying to finish support for the K55, as well as add the Polaris.
Once those are cleared off, we can then look into the Void (and the ST100 since you have one).

The latter will probably be easier to add, however if we can let the kernel driver handle the audio interface while we write data to the HID one on the headset, it should in theory work.

Apologies for not replying earlier, I got busy with other issues.
However, I now have more experience with the usb code, so it should be a bit easier to figure out what needs changing.

[ssube]

No problem, this issue has been dormant for a while. :)

Anything I can gather or debug in the mean time? This machine is set up with a Windows 10 KVM machine, not sure if there's a way to dump chatter between CUE and the devices with that, but I'm willing to crash a few things in the process.

[Ravenslofty]

not sure if there's a way to dump chatter between CUE and the devices with that

Funnily enough, there is. Come join us in IRC, we can help you out with that.

[tatokis]

ckb-next/ckb-next#9