Re: [PATCH v4] platform/x86: Add driver for ACPI WMAA EC-based backlight control

[Daniel Dadap <ddadap@nvidia.com>]

On 9/2/21 5:19 AM, Thomas Weißschuh wrote:
> It seems that the encoding of the mail has been set as plain ASCII while it is
> actually UTF-8.
> Thunderbird is probly correctly inferring the actual encoding.
> Normally git-format-patch would detect the Unicode characters and add a
> matching content-type header to the patch.
> But as these Unicode characters are added after format-patch has run it is now
> git-send-emails task to add those headers again.
>
> In my version of git I get the following message from git-send-email:
>
>    The following files are 8bit, but do not declare a Content-Transfer-Encoding.
>        0001-....patch
>    Which 8bit encoding should I declare [UTF-8]?
>
> As this feature seems to be really old already it should be available.
> Is your "git email-patch" using "git send-email"?
> Do you have "sendemail.assume8bitEncoding" set in your git config?
> (It should either not be set or to UTF-8.


Ah. That's likely the problem. The actual patch and associated commit 
message don't contain any characters that require more than 7 bits to 
encode, but the eventually sent e-mail does, since I added the 
information about the review revisions. Presumably git send-email is 
evaluating the encoding before the edit stage, but not after. 
sendemail.assume8bitEncoding is unset in my git config; I'll explicitly 
set it to UTF-8.


>>>> +	props.type = BACKLIGHT_PLATFORM;
>>> Is this WMI method a standard interface?
>>> If so, BACKLIGHT_FIRMWARE might actually fit better and still fulfill the
>>> requirements.
>>> The actual maintainers would know better than me, though.
>> I'm not certain what you mean by standard. It's defined as part of system
>> design guidelines that NVIDIA shares with OEMs, but I'm not sure if it's
>> part of the ACPI spec. It is implemented by multiple notebook system
>> vendors, hence naming the driver after the ACPI method rather than a
>> particular vendor. Reading the documentation on the backlight driver types,
>> it does seem that this may fall more under the purview of BACKLIGHT_FIRMWARE
>> than BACKLIGHT_PLATFORM. I'll go ahead and retest with the driver registered
>> as BACKLIGHT_FIRMWARE, but I'm sure it'll still work after inspecting the
>> code for at least gnome-settings-daemon, which implements the policy
>> recommended by Documentation/ABI/stable/sysfs-class-backlight.
> I only went by the comment about "standard firmware interface" from
> backlight.h.
> This was mostly a pointer for you (and the pdx86 maintainers) to take a look
> and decide.


Got it. From my interpretation of linux/backlight.h and 
Documentation/ABI/stable/sysfs-class-backlight, I *think* 
BACKLIGHT_FIRMWARE is probably more appropriate, so I'll change it to 
that, unless a maintainer disagrees. Hans/Andy?