On Thu, Jan 26, 2023 at 5:31 PM Armin Wolf <W_Armin@xxxxxx> wrote: > > Hello, > > i noticed that ACPICA handles integers passed to ToHexString() differently than the ACPI implementation of Microsoft Windows: > > Windows: > byte 0x0f =>"0xf" > word 0x0f0f => "0xf0f" > dword 0x0f0f0f0f => "0xf0f0f0f" > qword 0x0f0f0f0f0f0f0f0f => "0xf0f0f0f0f0f0f0f" > > ACPICA: > byte 0x0f =>"0000000f" > word 0x0f0f => "00000f0f" > dword 0x0f0f0f0f => "0f0f0f0f" > qword 0x0f0f0f0f0f0f0f0f => "0f0f0f0f" (32-bit table, but qword is 64-bit?) > > This causes problems on my Inspiron 3505, as the ACPI battery serial number is generated by using ToHexString(<16 bit field>, Local1) > and Mid(Local1, 0x02, 0x04, Local0), causing a wrong serial number to be displayed when using ACPICA (0020 instead of 20CD). > > Could it be possible to change the behavior of ToHexString() regarding integers to match the Microsoft Windows behavior? I think so, but I guess you'll need to submit a PR to the upstream ACPICA project on GitHub to get it started. > Something similar was already done in ACPICA version 20181213. Interesting.
