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

["Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>]

[-- Attachment #1: Type: text/plain, Size: 2311 bytes --]

On Tue, 15 Sep 2026, Aaron Erhardt wrote:

> 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.

Okay, thanks for the explanation. No further action required then for 
this patch.

-- 
 i.