Kitty Edition shows up twice: 1532:0521 (Headset) and 1532:0F19 (Chroma Controller)

[Kusoneko]

Sister issue on openrazer: openrazer/openrazer#1520 (comment)

Hello,

I have a Razer Kraken Kitty Edition Headset. According to the Razer website, and on the Synapse 3 application on Windows, it supports the following Chroma schemes:

• Breath
• Fire
• Spectrum
• Starlight
• Static
• Wave
• Wheel

However, on Polychromatic there is currently only the following options:

• None
• Static
• Breath

I would like to use Spectrum and have it synced with the rest of my Razer devices. I tried to "force" it using polychromatic-cli by doing the following command: polychromatic-cli -d headset -o spectrum however, that gives me the following error message: Skipping: Razer Kraken Kitty Edition - Setting this option was unsuccessful or is not supported.

Here are my various version information strings:
OS: Gentoo
Openrazer: 3.0.1
Polychromatic: 0.6.0 (rebuilt today just in case)

Is there any way to enable chroma options that are disabled for some reason on polychromatic despite the device supporting them?

Thanks,
Kusoneko

EDIT: After looking into it further, I found out that chroma options are set up in the openrazer driver, so I opened a sister issue there as well which is linked at the beginning of this issue. Hopefully, this will help in solving this issue.

As a side note, the Kitty Edition actually shows up twice in lsusb: 1532:0521 and 1532:0f19, however the former shows up as "Unknown Device" on polychromatic:

$ lsusb
Bus 001 Device 005: ID 1532:0521 Razer USA, Ltd Kraken Kitty Edition
Bus 001 Device 004: ID 1532:0f19 Razer USA, Ltd Razer Kraken Kitty Chroma Control

[lah7]

Hi. OpenRazer utilizes hardware effects provided by its firmware, and Razer Kraken Kitty Edition only supports static/breath:

https://github.com/openrazer/openrazer/blob/f4e5147ac1369a7ecb7cf45b9c962256d1818c3d/daemon/openrazer_daemon/hardware/headsets.py#L273-L289

I couldn't see any info on its original issues/PR whether other hardware effects (spectrum, starlight, wave) were tested too and might have been missed, or maybe they don't exist:

• Support for Razer Kraken Kitty Edition openrazer/openrazer#949
• Add support for Razer Kraken Kitty Edition openrazer/openrazer#1262

If you're comfortable, you could hack about in the driver and see if the firmware accepts other effect commands.

Razer Synapse 3 is purely software driven, so the Synapse driver is actually doing all the rendering, not the hardware. Fire and Wheel in particular are software only effects. The secret is that some Synapse 3-only devices (like my Base Station Chroma 🎧 ) do support hardware effects!

For now, you can create your own "animated pixel frame-by-frame" effects in Polychromatic, although this is limited to devices that are of the same LED dimensions. It's just a matter of time that I'll have the new effects system finished which will implement fancier software animations and a way to sync custom effects.

It's also possible that "Spectrum" in Synapse is actually just the "Static" effect in disguise. An alternate workaround could be to write a script to change between them. On most devices, Static → Static fades between the colours.

---

Regarding the duplicate IDs, OpenRazer fixed this in openrazer/openrazer#1286. Polychromatic scans USB IDs to list Razer devices that were not picked up by the OpenRazer daemon (usually to help identify improper installations) but your device is a bit unusual to present two. I'll add an exception to ignore 1532:0521 if that's definitely the "duplicate" one.

[Kusoneko]

Hi. OpenRazer utilizes hardware effects provided by its firmware, and Razer Kraken Kitty Edition only supports static/breath:

https://github.com/openrazer/openrazer/blob/f4e5147ac1369a7ecb7cf45b9c962256d1818c3d/daemon/openrazer_daemon/hardware/headsets.py#L273-L289

Yes, I also noticed that file, hence why I opened an issue also in openrazer. I do believe that no matter the method Synapse uses to sync up all the devices with the Spectrum effect, it should be reproducible using OpenRazer.

I couldn't see any info on its original issues/PR whether other hardware effects (spectrum, starlight, wave) were tested too and might have been missed, or maybe they don't exist:

* [openrazer/openrazer#949](https://github.com/openrazer/openrazer/issues/949)

* [openrazer/openrazer#1262](https://github.com/openrazer/openrazer/pull/1262)

I'm not sure either, all I saw as well on the subject is that they added the device with none, static and breath options only, so I assumed perhaps it was added without further testing of whether the other effects are actually supported, otherwise they'd perhaps have mentioned it? If not, I'm hopeful the issue I made over there will confirm one way or another about this.

If you're comfortable, you could hack about in the driver and see if the firmware accepts other effect commands.

I might look into it soonish, not right now as I'm working and can't afford to play around with patching and recompiling openrazer to figure out if it is in fact possible.

Razer Synapse 3 is purely software driven, so the Synapse driver is actually doing all the rendering, not the hardware. Fire and Wheel in particular are software only effects. The secret is that some Synapse 3-only devices (like my Base Station Chroma headphones ) do support hardware effects!

Interesting.

For now, you can create your own "animated pixel frame-by-frame" effects in Polychromatic, although this is limited to devices that are of the same LED dimensions. It's just a matter of time that I'll have the new effects system finished which will implement fancier software animations and a way to sync custom effects.

I haven't really looked into these, I'm not too sure how they work, I'm kind of using my razer devices' chroma options as set once and never (or almost never) change them ever again.

It's also possible that "Spectrum" in Synapse is actually just the "Static" effect in disguise. An alternate workaround could be to write a script to change between them. On most devices, Static → Static fades between the colours.

Indeed it does, however, I tested just now with polychromatic-cli -d headset -o static -c ff0000;polychromatic-cli -d headset -o static -c 00ff00;polychromatic-cli -d headset -o static -c 0000ff and it appears to cycle through the colors indeed, however, it does so way faster than the other devices which are synced together with spectrum. Even just waiting sort of until spectrum reaches the exact color the headset is at before sending the command to change to the next one leads to the headset being done in about 3-4 seconds while the rest of the devices reach the next color after 6-7 seconds, which means simply scripting the color change for the headset would render the whole thing out of sync.

Regarding the duplicate IDs, OpenRazer fixed this in openrazer/openrazer#1286. Polychromatic scans USB IDs to list Razer devices that were not picked up by the OpenRazer daemon (usually to help identify improper installations) but your device is a bit unusual to present two. I'll add an exception to ignore 1532:0521 if that's definitely the "duplicate" one.

I believe, if I'm not wrong, that 1532:0521 is the headset itself, and 1532:0f19 is the Chroma Controller. It is odd that they're separate, but on the other hand, it might be done on purpose since they also advertise a feature where the effect you last put on it can be remembered and kept by simply plugging it into a battery pack while holding a specific button on the headset, in other words, the chroma controller might be there specifically for the purpose of maintaining chroma effects when not connected to a computer of any kind. It occurs to me that I could probably use synapse, set the correct setting there, and then use the method they cite to try to have spectrum on the headset even on linux, however I no longer have Windows at all, and don't really feel like making a Windows VM with USB passthrough only to attempt to see if it can be done this way.

[Kusoneko]

So, I'm sort of stuck right now.

I've updated the lines in headset.py to include spectrum, and recompiled openrazer, unloaded the whole thing via modprobe and reloaded the modules with modprobe, then restarted the openrazer daemon, and while spectrum now shows up in polychromatic, enabling it fails with the following error:

Traceback (most recent call last):
  File ’/usr/lib/python3.9/site-packages/polychromatic/backends/openrazer.py’, line 749, in set_device_state
    rzone.spectrum()
  File ’/usr/lib/python3.9/site-packages/openrazer/client/fx.py’, line 132, in spectrum
    self._lighting_dbus.setSpectrum()
  File ’/usr/lib/python3.9/site-packages/dbus/proxies.py’, line 141, in __call__
    return self._connection.call_blocking(self._named_service,
  File ’/usr/lib/python3.9/site-packages/dbus/connection.py’, line 652, in call_blocking
    reply_message = self.send_message_with_reply_and_block(
dbus.exceptions.DBusException: org.freedesktop.DBus.Python.PermissionError: Traceback (most recent call last):
  File ’/usr/lib/python3.9/site-packages/dbus/service.py’, line 715, in _message_cb
    retval = candidate_method(self, *args, **keywords)
  File ’/usr/lib/python3.9/site-packages/openrazer_daemon/dbus_services/dbus_methods/chroma_keyboard.py’, line 270, in set_spectrum_effect
    with open(driver_path, ’w’) as driver_file:
PermissionError: [Errno 13] Permission denied: ’/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2.2/1-1.2.2:1.0/0003:1532:0F19.0004/matrix_effect_spectrum’

So naturally, I went to /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2.2/1-1.2.2:1.0/0003:1532:0F19.0004/ with cd "/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2.2/1-1.2.2:1.0/0003:1532:0F19.0004/"... And then with ls -l to see if I couldn't find matrix_effect_spectrum... unfortunately it's not there, so then I though, why not just make it?

And thus we read this:

# touch matrix_effect_spectrum
touch: cannot touch 'matrix_effect_spectrum': Permission denied

So, I guess this means one of 2 things:

1. I need to figure out how to create the file despite being unable to create it with the root user, or
2. It's not supported in the hardware, and instead I should look into reproducing it via custom effects or some other method that can somehow be synced with all devices as well.

If there's any other suggestions, I'm open to trying them out.

[lah7]

Changes are required in the driver files too. The sysfs interface is a special filesystem so touching a file is impossible and would be witchcraft if it worked. 😄

Look at openrazer/driver/razeraccessory_driver.c and search for matrix_effect_spectrum. Add a case for your hardware where applicable:

case USB_DEVICE_ID_RAZER_KRAKEN_KITTY_EDITION:

For example, for the CREATE_DEVICE_FILE for spectrum near the bottom. Near the top, there should be one case for a spectrum command, and there's a few protocols/zones, but I would try this one first:

report = razer_chroma_extended_matrix_effect_spectrum(VARSTORE, ZERO_LED);
report.transaction_id.id = 0x3F;

You can also bypass the daemon and echo directly to the sysfs file (when it's working/reloaded):

echo 1 > matrix_effect_spectrum

[Kusoneko]

I went ahead and did what you said, I still get a missing matrix_effect_spectrum file, should I try changing where I'm adding the case line or does it confirm the hardware doesn't support it? I haven't really played with drivers and sysfs before so I don't really know if my understanding of things is correct or not.

On a side note, I kinda wish though there was a way to send the signals to the device (as they're apparently 2-bytes long IDs for what the chroma thing should do from what I can understand) without having to rebuild the openrazer driver and test it over everytime, kinda like say send to the device the signals from 0x00 to 0xFF and try to figure out which effect it applies so I could basically in 10 minutes discover what the device actually supports and what it doesn't without having to modify openrazer sources, create a patch, put patch into my package manager's user-patch location, rebuild w/ patch, remove all modules with modprobe, readd all modules with modprobe, manually run the openrazer-driver, see all the sysfs permission errors due to root suddenly being the group that owns all the files in each device's sysfs, change the group owner to plugdev on all of these, have polychromatic restart openrazer-driver, restart polychromatic, and finally try to apply spectrum to the headset. I sincerely hope openrazer devs didn't do all of this operation every time they were trying to add a new device and figure out the interface for it, so that's why I'm hoping there's a more direct method to send chroma signals to the headset without doing all of this all over again.

[lah7]

should I try changing where I'm adding the case line or does it confirm the hardware doesn't support it?

I'm not 100% confident with the driver myself, but I'd look at the diff changes from https://github.com/openrazer/openrazer/pull/1262/files and double check things like the case for CREATE_DEVICE_FILE are definitely for the right sections (possibly multiple spectrum protocols?)

It could be that the driver hasn't fully reloaded too. I'd do:

# => Close all Polychromatic
openrazer-daemon -s   
sudo modprobe -r razeraccessory  
# => Unplug the headset
# => Build/reinstall DKMS driver
sudo modprobe razeraccessory
# => Plug in the headset

Re-plugging the USB should guarantee the kernel loads the modified driver and with the correct plugdev permissions (which comes with udev rules).

If the command fails, you should see this in the kernel logs (dmesg)

I sincerely hope openrazer devs didn't do all of this operation every time they were trying to add a new device and figure out the interface for it

Devices are primally added through community contributions, but it is very useful to have pcaps from a VM so USB traffic can be analysed when run under Razer Synapse in case the protocol/instruction is unknown. Although, Synapse 3's effects just sends lots of custom frames, but knowing that it supports "Spectrum" gives hope that the hardware effect is still in its firmware.

One of the main contributors to OpenRazer has worked on a side project named razer_test which aims to implement support in user space, eliminating the driver. For now, I'm not aware of any tools that sends raw instructions to USB devices, but I imagine there is something out there.

[Kusoneko]

should I try changing where I'm adding the case line or does it confirm the hardware doesn't support it?

I'm not 100% confident with the driver myself, but I'd look at the diff changes from https://github.com/openrazer/openrazer/pull/1262/files and double check things like the case for CREATE_DEVICE_FILE are definitely for the right sections (possibly multiple spectrum protocols?)

I'll look into that as soon as I can.

It could be that the driver hasn't fully reloaded too. I'd do:

# => Close all Polychromatic
openrazer-daemon -s   
sudo modprobe -r razeraccessory  
# => Unplug the headset
# => Build/reinstall DKMS driver
sudo modprobe razeraccessory
# => Plug in the headset

Re-plugging the USB should guarantee the kernel loads the modified driver and with the correct plugdev permissions (which comes with udev rules).

The problem with replugging and everything is that all of the kernel modules are rebuilt, so I should unplug every single one of my razer devices and replug them, which is a massive pain in the ass, unless I can just ignore the other kernel modules and reinstall only the accessory one without the others losing plugdev?

If the command fails, you should see this in the kernel logs (dmesg)

I sincerely hope openrazer devs didn't do all of this operation every time they were trying to add a new device and figure out the interface for it

Devices are primally added through community contributions, but it is very useful to have pcaps from a VM so USB traffic can be analysed when run under Razer Synapse in case the protocol/instruction is unknown. Although, Synapse 3's effects just sends lots of custom frames, but knowing that it supports "Spectrum" gives hope that the hardware effect is still in its firmware.

One of the main contributors to OpenRazer has worked on a side project named razer_test which aims to implement support in user space, eliminating the driver. For now, I'm not aware of any tools that sends raw instructions to USB devices, but I imagine there is something out there.

Interesting, but I don't know if that's really necessary, I mean I have no issue with it being a kernel module, the issue I have is with the time it takes to go from unpatched openrazer to testing modifications to see if it worked, honestly.

[lah7]

so I should unplug every single one of my razer devices and replug them, [...] unless I can just ignore the other kernel modules and reinstall only the accessory one without the others losing plugdev?

For the purposes of testing, unload them all and just load/reload razeraccessory. The alternate to replugging the USB could be:

• Manually sudo chgrp plugdev matrix_effect_*
• Start a root shell and use that to echo to the sysfs file (but do not run openrazer-daemon or Polychromatic as root because it's only more permission headaches)

It sounds like Gentoo's package patching step could be adding to the pain. If you have Ubuntu/Debian (even just for a live session), OpenRazer's repository has a ./scripts/build_debs.sh script and then it's an apt install *.deb / modprobe [-r] with that.

You might be able to modify /usr/src/openrazer-driver-3.0.1 directly (this path could be different on Gentoo) and use dkms install.

For what it's worth, you could ask the people in openrazer/openrazer#1262 or openrazer/openrazer#949 if they did try probing for the other hardware effects.

[Kusoneko]

I asked in the issue and PR you linked to, as for the rest, I'm awaiting some actual free time where I'm not working to try it out, I don't think I'll need to leave Gentoo to try to fix it however, I believe if I don't load the other razer drivers, it might actually be simpler to test the headset exclusively. What I'm doing is essentially cloning the openrazer repo into ~/.local/src/openrazer, then making the changes, then git diff > enable_chroma_effects_kraken_kitty.patch and then copy the patch to /etc/portage/patches/app-misc/openrazer/enable_chroma_effects_kraken_kitty.patch and finally, re-emerge it.

[lah7]

Nice! Looks like openrazer/openrazer#1528 added the missing effects. Kudos to @999eagle 👍

I've renamed this issue so I can address the Kitty Edition appearing twice. Based on the first comment ☝🏼 I'll ignore 1532:0521 which appears as the "unknown" duplicate.