Ckb-next: [Scimitar pro] Save profile not working

[sum01]

Devices information

ckb-next-dev-detect-report.gz

Bug report

The daemon fails to load saved keybindings & DPI settings. They load once the GUI is opened, but if I "quit" via the settings menu then it goes back to defaults.

General information

Arch Linux 4.18.1-arch1-1-ARCH
The ckb-next-daemon.service is enabled & started via systemctl.

Source

Version 0.3.1-1 installed from the AUR

[Ravenslofty]

So this turns out to depend on #136, along with the Glaive.

[CommandZebra]

Seem to have a similar issue, can't save profiles on my Scimitar pro

ckb-next-report-1536165606.gz

[Ravenslofty]

Yes, it's intentionally disabled because the Scimitar uses a hardware profile system that is not yet fully implemented, and given that I was literally bought a Scimitar Pro yesterday by @fleischie, you'll have to wait.

[Ravenslofty]

A person on IRC commented about there still being no save to hardware support for the Scimitar, so I'd like to give an update.

We have the basics of the Scimitar hardware format understood; it shares a lot in common with the K95P. However, there are a few unresolved problems.

The format uses several fairly straightforward metadata files which we presume the device reads from flash, and a completely opaque blob which we suspect to be a binary for the animation itself. Unfortunately without more context we do not wish to bundle this binary as it could lead to a copyright infringement claim we could not fight. If it is a binary, then to reverse engineer the animation would require reverse engineering the entire mouse to understand what is happening. That's not going to be fun.

Additionally, the mouse uses hardware animations, but CKB was designed from a perspective of full external control; the daemon is fed frames, not animations, from the GUI, and if you currently asked the daemon to save to hardware you would just get a single colour, not an animation like CUE can do.