hidpp10: parse the profile list about libratbag

[cvuchener]

From my G500

02 00 01
ff ...

From floe's G700s

02 00 01
03 00 03
04 00 07
05 00 06
06 00 04
ff ...

How a profile is removed? By replacing the values with ff?

[phomes]

When a profile is disabled it is simply not in the list e.g. with profile 3 disabled:
02 00 01
03 00 03
05 00 06
06 00 04
FF FF

[cvuchener]

I tried writing the same data on my G500.
Writing to 0x0f with zero parameters (or immediately after writing page 1), does not load the profile from page 2 but the factory default profile, and reading 0x0f gives ff 00 00. But when the mouse is plugged, the profile from page 2 is correctly loaded.
Switching to a profile from a memory page still does not change the output of 0x0f.

[cvuchener]

I plugged the mouse with

02 00 01
03 00 03
04 00 07
ff ...

in memory on a computer with LGS. LGS actually read this just after the profile (I must have missed it before).
It then rewrite the page with

02 00 01
ff ff ff
04 00 07
ff ...

[bentiss]

For @phomes questions:

Do we want to support enabling/disabling of profiles from libratbag?
Probably (in the same way that we should support enabling/disabling resolutions within a profile).
Which means that the ratbag_device returns the max number of supported profiles, but some will be disabled.

Should ratbag-command show info for disabled profiles?
I don't think so (like we do for resolutions: just print a "" and return)

[phomes]

@bentiss and we hope that we can read the max number of profiles from somewhere on the mouse, right?

Since the list in page 1 shows in which pages the profiles are stored I suppose we then need to be keep track of memory use on the mouse. I mean, since they care to keep a list of pages where each profile is stored then that must mean that the locations are not just hardcoded.

[cvuchener]

Did you check how this data affects the behaviour of the 0x0f command?

[bentiss]

@phomes yes, I hope that this value is encoded somewhere in the hardware or is a constant across all devices that have this particular capability.

And yes, we should probably keep track of the profile/page association

[whot]

took benjamin's patch for this and extended it further into some basic code:
https://github.com/whot/libratbag/tree/wip/hidpp10-profile-directory
this is really just parsing the 3-byte directory tree (benjamin - where did the led_mask bit come from?) and handling it, but it's a start. At least it removes a bunch of odd g500s bits I sprinkled all over the place.

[cvuchener]

I don't know if Benjamin has another source. But I made a guess (just a guess not tested) about the LEDs from the G700s data in #22 (is there a way to link specific messages?).

[whot]

good question. The timestamp is the link to a specific message, but I don't know if there's a shortcut for it.
And thanks, I thought that led_mask came from @bentiss, I didn't realise you figured that one out. We don't have any documentation for this yet, so your guess is as good as ours - let's go with until we know otherwise.

[bentiss]

Yes, the led_mask credits are going to @cvuchener.
It might also be used as an extra way to identify which profile is which in the UI. Given that you remove the profile from the list, you need to know which page corresponds to which profile not to have the profiles being moved around in the UI.

And thanks both of you (@phomes and @cvuchener) for figuring out the profile directly. There are mentions of it in the HID++ 1.0 doc, but we don't currently have any device-specific documentation that could have helped us understood where the directory is and what it looks like.