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
