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?
