Hi, i found out that the behavior of the ToHexString() ASL operator differs between Windows and Linux: - Windows: byte 0x0f =>"0xf" word 0x0f0f => "0xf0f" dword 0x0f0f0f0f => "0xf0f0f0f" qword 0x0f0f0f0f0f0f0f0f => "0xf0f0f0f0f0f0f0f" - Linux (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 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 (0020 instead of 20CD). Would it be possible to change the behavior of ToHexString() for integers to match the Windows behavior? Something similar was already done in ACPICA version 20181213 regarding the behavior of ToHexString() on buffers. I understand that this has the potential of introducing regressions, but i believe that most systems target the behavior of Windows anyway. Armin Wolf
