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

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 9/2/21 10:15 PM, Daniel Dadap wrote:
> 
> 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?

I agree that BACKLIGHT_FIRMWARE is more appropriate, that is the same
as what drivers/acpi/acpi_video.c uses and this is in essence operating
at the same level.

Regards,

Hans