Re: [PATCH v3 5/6] platform/x86/tuxedo: Update and extend documentation

[Aaron Erhardt <aer@tuxedocomputers.com>]

Am 15.09.26 um 15:08 schrieb Ilpo Järvinen:
> On Wed, 26 Aug 2026, Aaron Erhardt wrote:
> 
>> Remove an incorrect comment about the Microsoft MacroPad reference
>> implementation allegedly deviating from the spec and add more
>> information about the module and some other minor improvements.
> 
> Was it "incorrect" or was the spec clarified in a later version? If the 
> latter, that would be worth to mention instead of claiming the original 
> comment was "incorrect".
> 
> This is a honest question, I don't know the answer but I'm kind trying to 
> read in between lines here how we ended up in this situation so my 
> impression could be entirely wrong. ...Thus, please don't assume I know 
> much about the content of these specs (despite me briefly looking into 
> what I could find around this feature was introduced).
> 

The MacroPad reference implementation never deviated from the spec in this
area, at least not in the way the comment suggests. The comment removed here
references another comment, which is removed alongside the code that was
touched in patch 3/6 and assumed that intensities should allow multiple values
to be assigned (e.g. 256 levels), but that was never required in the spec. Even
version 1.4 (the initial driver had 1.5 as a basis) of the spec already
suggests using only two intensities for on and off while everything else is
done through the RGB channels unless the device has some sort of global
brightness control in its hardware.

I think the reason for this misconception might come from an actual bug in the
reference implementation (which is fixed now:
https://github.com/microsoft/RP2040MacropadHidSample/commit/cfc29120a3910c5772976da29ecd57392dfd44d6)
and the natural assumption, that intensity should, similar to the RGB channels,
have 8 bit. Therefore, the driver initially implemented brightness exactly that
way with 256 levels, scaling the RGB intensities with integer arithmetic. But 
since the hardware doesn't scale the brightness and the spec doesn't require
this, there is no good reason to do this.