Re: HP Zbook studio G5 Brightness and mic mute keys give same scancode

Re: HP Zbook studio G5 Brightness and mic mute keys give same scancode

[Andy Shevchenko]

+Cc: subsystem maintainers

On Sun, May 17, 2020 at 2:24 PM <thestroyer@cock.li> wrote:
>
> Hi,
> On my HP Zbook studio G5 a few keys on my keyboard give the same
> scancodes. Most notably, the brightness and mute function keys all give
> the scan code sequence 0xe0 0x20 0xe0 0xa0 as reported by showkey
> --scancodes. It only produces a scancode when pressed, not when
> released. I found another very similar issue in this mailing list found
> in https://www.spinics.net/lists/platform-driver-x86/msg16791.html. The
> issue in that mail was solved by a bios update. I'm running the latest
> bios, but I still have the issue.
> I tried the kernels: Manjaro 5.7rc4-1, Manjaro 5.6.11-1 and Manjaro
> 5.4.39-1
> I also tried a few other distributions, but they all have the same
> issue.
> I'm happy to provide more information about this issue if needed.
>
> Thanks,
>
> Friso



-- 
With Best Regards,
Andy Shevchenko

Re: HP Zbook studio G5 Brightness and mic mute keys give same scancode

[Hans de Goede]

Hi,

On 11/5/20 5:47 PM, Andy Shevchenko wrote:
> +Cc: subsystem maintainers
> 
> On Sun, May 17, 2020 at 2:24 PM <thestroyer@cock.li> wrote:
>>
>> Hi,
>> On my HP Zbook studio G5 a few keys on my keyboard give the same
>> scancodes. Most notably, the brightness and mute function keys all give
>> the scan code sequence 0xe0 0x20 0xe0 0xa0 as reported by showkey
>> --scancodes. It only produces a scancode when pressed, not when
>> released. I found another very similar issue in this mailing list found
>> in https://www.spinics.net/lists/platform-driver-x86/msg16791.html. The
>> issue in that mail was solved by a bios update. I'm running the latest
>> bios, but I still have the issue.
>> I tried the kernels: Manjaro 5.7rc4-1, Manjaro 5.6.11-1 and Manjaro
>> 5.4.39-1
>> I also tried a few other distributions, but they all have the same
>> issue.
>> I'm happy to provide more information about this issue if needed.

So this already came in another thread for another HP laptop model,
this seems to be a common issue on some (newer?) HP laptop models.

It seems that we need to make some special WMI calls for this, either
to figure out which key is actually pressed when receiving the
PS/2 scancode which is shared between multiple keys. Or to get the
device to send different scancodes.

This will require someone with some knowledge of ACPI/WMI as well
as of writing kernel code to get physical access to an affected HP
laptop to figure out what is going on and write some code to deal with
this special setup.

Regards,

Hans

Re: HP Zbook studio G5 Brightness and mic mute keys give same scancode

[Hans de Goede]

Hi,

On 11/12/20 7:25 PM, Friso Smit wrote:
> Hi,
> 
> I'm not sure if you have read the previous mails in this thread, but the
> problem is solved, at least for me, with a bios update.

At that is good to know.

> I don't know how
> it works exactly, but all keys produce different scan codes now. Are there
> still some models where this is a problem?

Yes this is till a problem on at least the hp-pavilion-cx-0598na, see
the mail thread starting here:

https://lore.kernel.org/platform-driver-x86/CAGTBY+sgwYrDPtQgJV=TcXJ73n8TGf9Nw=arCfWMUrVFzAsEVQ@mail.gmail.com/

I've just asked the reported of that problem to check if there is a BIOS
update for his system.

Regards,

Hans




> On 11/9/20 2:44 PM, Hans de Goede wrote:
>> Hi,
>>
>> On 11/5/20 5:47 PM, Andy Shevchenko wrote:
>>> +Cc: subsystem maintainers
>>>
>>> On Sun, May 17, 2020 at 2:24 PM <thestroyer@cock.li> wrote:
>>>> Hi,
>>>> On my HP Zbook studio G5 a few keys on my keyboard give the same
>>>> scancodes. Most notably, the brightness and mute function keys all give
>>>> the scan code sequence 0xe0 0x20 0xe0 0xa0 as reported by showkey
>>>> --scancodes. It only produces a scancode when pressed, not when
>>>> released. I found another very similar issue in this mailing list found
>>>> in https://www.spinics.net/lists/platform-driver-x86/msg16791.html. The
>>>> issue in that mail was solved by a bios update. I'm running the latest
>>>> bios, but I still have the issue.
>>>> I tried the kernels: Manjaro 5.7rc4-1, Manjaro 5.6.11-1 and Manjaro
>>>> 5.4.39-1
>>>> I also tried a few other distributions, but they all have the same
>>>> issue.
>>>> I'm happy to provide more information about this issue if needed.
>> So this already came in another thread for another HP laptop model,
>> this seems to be a common issue on some (newer?) HP laptop models.
>>
>> It seems that we need to make some special WMI calls for this, either
>> to figure out which key is actually pressed when receiving the
>> PS/2 scancode which is shared between multiple keys. Or to get the
>> device to send different scancodes.
>>
>> This will require someone with some knowledge of ACPI/WMI as well
>> as of writing kernel code to get physical access to an affected HP
>> laptop to figure out what is going on and write some code to deal with
>> this special setup.
>>
>> Regards,
>>
>> Hans
>>

Re: HP Zbook studio G5 Brightness and mic mute keys give same scancode

[TheStroyer]

Hi,

Somewhere between 28-11-2020 and today my brightness hotkeys are broken 
again. They act as mic mute key again. I don't know if this is caused by 
the system upgrade or something else. I have used windows for the first 
time in a while, so that may have sneakily upgraded something.

I have tried downgrading the packages linux, linux-headers, 
linux-firmware, systemd and systemd-libs (form Arch Linux) to some older 
version.

I also tried updating the bios from the bios screen and updating the 
firmware from windows device manager. This all didn't change anything.

So we're back where we started I guess.

Best regards,

Friso

On 24/11/2020 12:14, Hans de Goede wrote:
> Hi,
>
> On 11/12/20 7:25 PM, Friso Smit wrote:
>> Hi,
>>
>> I'm not sure if you have read the previous mails in this thread, but the
>> problem is solved, at least for me, with a bios update.
> At that is good to know.
>
>> I don't know how
>> it works exactly, but all keys produce different scan codes now. Are there
>> still some models where this is a problem?
> Yes this is till a problem on at least the hp-pavilion-cx-0598na, see
> the mail thread starting here:
>
> https://lore.kernel.org/platform-driver-x86/CAGTBY+sgwYrDPtQgJV=TcXJ73n8TGf9Nw=arCfWMUrVFzAsEVQ@mail.gmail.com/
>
> I've just asked the reported of that problem to check if there is a BIOS
> update for his system.
>
> Regards,
>
> Hans
>
>
>
>
>> On 11/9/20 2:44 PM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 11/5/20 5:47 PM, Andy Shevchenko wrote:
>>>> +Cc: subsystem maintainers
>>>>
>>>> On Sun, May 17, 2020 at 2:24 PM <thestroyer@cock.li> wrote:
>>>>> Hi,
>>>>> On my HP Zbook studio G5 a few keys on my keyboard give the same
>>>>> scancodes. Most notably, the brightness and mute function keys all give
>>>>> the scan code sequence 0xe0 0x20 0xe0 0xa0 as reported by showkey
>>>>> --scancodes. It only produces a scancode when pressed, not when
>>>>> released. I found another very similar issue in this mailing list found
>>>>> in https://www.spinics.net/lists/platform-driver-x86/msg16791.html. The
>>>>> issue in that mail was solved by a bios update. I'm running the latest
>>>>> bios, but I still have the issue.
>>>>> I tried the kernels: Manjaro 5.7rc4-1, Manjaro 5.6.11-1 and Manjaro
>>>>> 5.4.39-1
>>>>> I also tried a few other distributions, but they all have the same
>>>>> issue.
>>>>> I'm happy to provide more information about this issue if needed.
>>> So this already came in another thread for another HP laptop model,
>>> this seems to be a common issue on some (newer?) HP laptop models.
>>>
>>> It seems that we need to make some special WMI calls for this, either
>>> to figure out which key is actually pressed when receiving the
>>> PS/2 scancode which is shared between multiple keys. Or to get the
>>> device to send different scancodes.
>>>
>>> This will require someone with some knowledge of ACPI/WMI as well
>>> as of writing kernel code to get physical access to an affected HP
>>> laptop to figure out what is going on and write some code to deal with
>>> this special setup.
>>>
>>> Regards,
>>>
>>> Hans
>>>

Re: HP Zbook studio G5 Brightness and mic mute keys give same scancode

[Hans de Goede]

Hi,

On 12/4/20 2:05 PM, TheStroyer wrote:
> Hi,
> 
> Somewhere between 28-11-2020 and today my brightness hotkeys are broken again. They act as mic mute key again. I don't know if this is caused by the system upgrade or something else. I have used windows for the first time in a while, so that may have sneakily upgraded something.
> 
> I have tried downgrading the packages linux, linux-headers, linux-firmware, systemd and systemd-libs (form Arch Linux) to some older version.
> 
> I also tried updating the bios from the bios screen and updating the firmware from windows device manager. This all didn't change anything.
> 
> So we're back where we started I guess.

Interesting, this sounds as if Windows is doing something which causes them to
all send the same scancode.

If the device has a removable battery, or an option in the BIOS to disable the
internal battery for long term storage (it will get re-enabled when you plug
in a charger then), it would be good if you can either remove the battery or
use the BIOS option; and then after that boot directly into Linux. I'm guessing /
hoping that that will fix things.

This is not really a good / usable workaround but it would be in interesting
data point.

If the battery is not removable; and there is no BIOS option, you could disable
the emergency shutdown on low battery behavior on Linux and let the battery be
drained until the battery-management-controller turns the machine off, that
hopefully has the same result.

Regards,

Hans


> 
> Best regards,
> 
> Friso
> 
> On 24/11/2020 12:14, Hans de Goede wrote:
>> Hi,
>>
>> On 11/12/20 7:25 PM, Friso Smit wrote:
>>> Hi,
>>>
>>> I'm not sure if you have read the previous mails in this thread, but the
>>> problem is solved, at least for me, with a bios update.
>> At that is good to know.
>>
>>> I don't know how
>>> it works exactly, but all keys produce different scan codes now. Are there
>>> still some models where this is a problem?
>> Yes this is till a problem on at least the hp-pavilion-cx-0598na, see
>> the mail thread starting here:
>>
>> https://lore.kernel.org/platform-driver-x86/CAGTBY+sgwYrDPtQgJV=TcXJ73n8TGf9Nw=arCfWMUrVFzAsEVQ@mail.gmail.com/
>>
>> I've just asked the reported of that problem to check if there is a BIOS
>> update for his system.
>>
>> Regards,
>>
>> Hans
>>
>>
>>
>>
>>> On 11/9/20 2:44 PM, Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> On 11/5/20 5:47 PM, Andy Shevchenko wrote:
>>>>> +Cc: subsystem maintainers
>>>>>
>>>>> On Sun, May 17, 2020 at 2:24 PM <thestroyer@cock.li> wrote:
>>>>>> Hi,
>>>>>> On my HP Zbook studio G5 a few keys on my keyboard give the same
>>>>>> scancodes. Most notably, the brightness and mute function keys all give
>>>>>> the scan code sequence 0xe0 0x20 0xe0 0xa0 as reported by showkey
>>>>>> --scancodes. It only produces a scancode when pressed, not when
>>>>>> released. I found another very similar issue in this mailing list found
>>>>>> in https://www.spinics.net/lists/platform-driver-x86/msg16791.html. The
>>>>>> issue in that mail was solved by a bios update. I'm running the latest
>>>>>> bios, but I still have the issue.
>>>>>> I tried the kernels: Manjaro 5.7rc4-1, Manjaro 5.6.11-1 and Manjaro
>>>>>> 5.4.39-1
>>>>>> I also tried a few other distributions, but they all have the same
>>>>>> issue.
>>>>>> I'm happy to provide more information about this issue if needed.
>>>> So this already came in another thread for another HP laptop model,
>>>> this seems to be a common issue on some (newer?) HP laptop models.
>>>>
>>>> It seems that we need to make some special WMI calls for this, either
>>>> to figure out which key is actually pressed when receiving the
>>>> PS/2 scancode which is shared between multiple keys. Or to get the
>>>> device to send different scancodes.
>>>>
>>>> This will require someone with some knowledge of ACPI/WMI as well
>>>> as of writing kernel code to get physical access to an affected HP
>>>> laptop to figure out what is going on and write some code to deal with
>>>> this special setup.
>>>>
>>>> Regards,
>>>>
>>>> Hans
>>>>
> 

Re: HP Zbook studio G5 Brightness and mic mute keys give same scancode

[Friso Smit]

Hi,


> On 12/4/20 2:05 PM, TheStroyer wrote:
>> So we're back where we started I guess.

Correction, there is something different this time around. Last time there

were other keys that had the same scan codes as each other. They are still

working now. This results in a win of four keys, yay.

> Interesting, this sounds as if Windows is doing something which causes them to
> all send the same scancode.
Yeah, but I still cannot say with confidence it's not something else.
> If the device has a removable battery, or an option in the BIOS to disable the
> internal battery for long term storage (it will get re-enabled when you plug
> in a charger then), it would be good if you can either remove the battery or
> use the BIOS option; and then after that boot directly into Linux. I'm guessing /
> hoping that that will fix things.
>
> This is not really a good / usable workaround but it would be in interesting
> data point.
>
> If the battery is not removable; and there is no BIOS option, you could disable
> the emergency shutdown on low battery behavior on Linux and let the battery be
> drained until the battery-management-controller turns the machine off, that
> hopefully has the same result.
>
> Regards,
>
> Hans

Sound like an interesting workaround. Unfortunately there is no BIOS

option for this and the battery is not easily removable.  I do not want

to risk damaging my battery as this is a very expensive laptop. Thanks

for the help though. I will update when something interesting happens


Regards,

Friso

>
>> Best regards,
>>
>> Friso
>>
>> On 24/11/2020 12:14, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 11/12/20 7:25 PM, Friso Smit wrote:
>>>> Hi,
>>>>
>>>> I'm not sure if you have read the previous mails in this thread, but the
>>>> problem is solved, at least for me, with a bios update.
>>> At that is good to know.
>>>
>>>> I don't know how
>>>> it works exactly, but all keys produce different scan codes now. Are there
>>>> still some models where this is a problem?
>>> Yes this is till a problem on at least the hp-pavilion-cx-0598na, see
>>> the mail thread starting here:
>>>
>>> https://lore.kernel.org/platform-driver-x86/CAGTBY+sgwYrDPtQgJV=TcXJ73n8TGf9Nw=arCfWMUrVFzAsEVQ@mail.gmail.com/
>>>
>>> I've just asked the reported of that problem to check if there is a BIOS
>>> update for his system.
>>>
>>> Regards,
>>>
>>> Hans
>>>
>>>
>>>
>>>
>>>> On 11/9/20 2:44 PM, Hans de Goede wrote:
>>>>> Hi,
>>>>>
>>>>> On 11/5/20 5:47 PM, Andy Shevchenko wrote:
>>>>>> +Cc: subsystem maintainers
>>>>>>
>>>>>> On Sun, May 17, 2020 at 2:24 PM<thestroyer@cock.li>  wrote:
>>>>>>> Hi,
>>>>>>> On my HP Zbook studio G5 a few keys on my keyboard give the same
>>>>>>> scancodes. Most notably, the brightness and mute function keys all give
>>>>>>> the scan code sequence 0xe0 0x20 0xe0 0xa0 as reported by showkey
>>>>>>> --scancodes. It only produces a scancode when pressed, not when
>>>>>>> released. I found another very similar issue in this mailing list found
>>>>>>> inhttps://www.spinics.net/lists/platform-driver-x86/msg16791.html. The
>>>>>>> issue in that mail was solved by a bios update. I'm running the latest
>>>>>>> bios, but I still have the issue.
>>>>>>> I tried the kernels: Manjaro 5.7rc4-1, Manjaro 5.6.11-1 and Manjaro
>>>>>>> 5.4.39-1
>>>>>>> I also tried a few other distributions, but they all have the same
>>>>>>> issue.
>>>>>>> I'm happy to provide more information about this issue if needed.
>>>>> So this already came in another thread for another HP laptop model,
>>>>> this seems to be a common issue on some (newer?) HP laptop models.
>>>>>
>>>>> It seems that we need to make some special WMI calls for this, either
>>>>> to figure out which key is actually pressed when receiving the
>>>>> PS/2 scancode which is shared between multiple keys. Or to get the
>>>>> device to send different scancodes.
>>>>>
>>>>> This will require someone with some knowledge of ACPI/WMI as well
>>>>> as of writing kernel code to get physical access to an affected HP
>>>>> laptop to figure out what is going on and write some code to deal with
>>>>> this special setup.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Hans
>>>>>

Re: HP Zbook studio G5 Brightness and mic mute keys give same scancode

[Hans de Goede]

Hi,

On 12/5/20 7:21 PM, Friso Smit wrote:
> Hi,
> 
> 
>> On 12/4/20 2:05 PM, TheStroyer wrote:
>>> So we're back where we started I guess.
> 
> Correction, there is something different this time around. Last time there
> 
> were other keys that had the same scan codes as each other. They are still
> 
> working now. This results in a win of four keys, yay.
> 
>> Interesting, this sounds as if Windows is doing something which causes them to
>> all send the same scancode.
> Yeah, but I still cannot say with confidence it's not something else.
>> If the device has a removable battery, or an option in the BIOS to disable the
>> internal battery for long term storage (it will get re-enabled when you plug
>> in a charger then), it would be good if you can either remove the battery or
>> use the BIOS option; and then after that boot directly into Linux. I'm guessing /
>> hoping that that will fix things.
>>
>> This is not really a good / usable workaround but it would be in interesting
>> data point.
>>
>> If the battery is not removable; and there is no BIOS option, you could disable
>> the emergency shutdown on low battery behavior on Linux and let the battery be
>> drained until the battery-management-controller turns the machine off, that
>> hopefully has the same result.
>>
>> Regards,
>>
>> Hans
> 
> Sound like an interesting workaround. Unfortunately there is no BIOS
> 
> option for this and the battery is not easily removable.  I do not want
> 
> to risk damaging my battery as this is a very expensive laptop.

Discharging your battery till the hardware shuts itself off should never
harm the battery, the battery-management-controller will turn off all
power (simulating removing the battery) before the battery discharges
to a level where it can be damaged.  So unless there is some very bad
bug in the hw of your laptop this should be safe to do. Otherwise
the OS hanging while the battery is already low and you are not
present to detect this could also damage the hardware.

With recent Linux distributions you need to disable the upower daemon
(you probably need to mask it in systemd to avoid it being autostarted)
to avoid the auto-shutdown.

Note I completely understand if you still do not want to do this,
I'm just saying that it is not *that* dangerous.

Regards,

Hans




> Thanks
> 
> for the help though. I will update when something interesting happens
> 
> 
> Regards,
> 
> Friso
> 
>>
>>> Best regards,
>>>
>>> Friso
>>>
>>> On 24/11/2020 12:14, Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> On 11/12/20 7:25 PM, Friso Smit wrote:
>>>>> Hi,
>>>>>
>>>>> I'm not sure if you have read the previous mails in this thread, but the
>>>>> problem is solved, at least for me, with a bios update.
>>>> At that is good to know.
>>>>
>>>>> I don't know how
>>>>> it works exactly, but all keys produce different scan codes now. Are there
>>>>> still some models where this is a problem?
>>>> Yes this is till a problem on at least the hp-pavilion-cx-0598na, see
>>>> the mail thread starting here:
>>>>
>>>> https://lore.kernel.org/platform-driver-x86/CAGTBY+sgwYrDPtQgJV=TcXJ73n8TGf9Nw=arCfWMUrVFzAsEVQ@mail.gmail.com/
>>>>
>>>> I've just asked the reported of that problem to check if there is a BIOS
>>>> update for his system.
>>>>
>>>> Regards,
>>>>
>>>> Hans
>>>>
>>>>
>>>>
>>>>
>>>>> On 11/9/20 2:44 PM, Hans de Goede wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 11/5/20 5:47 PM, Andy Shevchenko wrote:
>>>>>>> +Cc: subsystem maintainers
>>>>>>>
>>>>>>> On Sun, May 17, 2020 at 2:24 PM<thestroyer@cock.li>  wrote:
>>>>>>>> Hi,
>>>>>>>> On my HP Zbook studio G5 a few keys on my keyboard give the same
>>>>>>>> scancodes. Most notably, the brightness and mute function keys all give
>>>>>>>> the scan code sequence 0xe0 0x20 0xe0 0xa0 as reported by showkey
>>>>>>>> --scancodes. It only produces a scancode when pressed, not when
>>>>>>>> released. I found another very similar issue in this mailing list found
>>>>>>>> inhttps://www.spinics.net/lists/platform-driver-x86/msg16791.html. The
>>>>>>>> issue in that mail was solved by a bios update. I'm running the latest
>>>>>>>> bios, but I still have the issue.
>>>>>>>> I tried the kernels: Manjaro 5.7rc4-1, Manjaro 5.6.11-1 and Manjaro
>>>>>>>> 5.4.39-1
>>>>>>>> I also tried a few other distributions, but they all have the same
>>>>>>>> issue.
>>>>>>>> I'm happy to provide more information about this issue if needed.
>>>>>> So this already came in another thread for another HP laptop model,
>>>>>> this seems to be a common issue on some (newer?) HP laptop models.
>>>>>>
>>>>>> It seems that we need to make some special WMI calls for this, either
>>>>>> to figure out which key is actually pressed when receiving the
>>>>>> PS/2 scancode which is shared between multiple keys. Or to get the
>>>>>> device to send different scancodes.
>>>>>>
>>>>>> This will require someone with some knowledge of ACPI/WMI as well
>>>>>> as of writing kernel code to get physical access to an affected HP
>>>>>> laptop to figure out what is going on and write some code to deal with
>>>>>> this special setup.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Hans
>>>>>>
> 

Re: HP Zbook studio G5 Brightness and mic mute keys give same scancode

[Hans de Goede]

Hi,

On 12/7/20 2:23 PM, Friso Smit wrote:
> On 12/5/20 7:50 PM, Hans de Goede wrote:
>> Hi,
>>
>> On 12/5/20 7:21 PM, Friso Smit wrote:
>>> Hi,
>>>
>>>
>>>> On 12/4/20 2:05 PM, TheStroyer wrote:
>>>>> So we're back where we started I guess.
>>> Correction, there is something different this time around. Last time there
>>>
>>> were other keys that had the same scan codes as each other. They are still
>>>
>>> working now. This results in a win of four keys, yay.
>>>
>>>> Interesting, this sounds as if Windows is doing something which causes them to
>>>> all send the same scancode.
>>> Yeah, but I still cannot say with confidence it's not something else.
>>>> If the device has a removable battery, or an option in the BIOS to disable the
>>>> internal battery for long term storage (it will get re-enabled when you plug
>>>> in a charger then), it would be good if you can either remove the battery or
>>>> use the BIOS option; and then after that boot directly into Linux. I'm guessing /
>>>> hoping that that will fix things.
>>>>
>>>> This is not really a good / usable workaround but it would be in interesting
>>>> data point.
>>>>
>>>> If the battery is not removable; and there is no BIOS option, you could disable
>>>> the emergency shutdown on low battery behavior on Linux and let the battery be
>>>> drained until the battery-management-controller turns the machine off, that
>>>> hopefully has the same result.
>>>>
>>>> Regards,
>>>>
>>>> Hans
>>> Sound like an interesting workaround. Unfortunately there is no BIOS
>>>
>>> option for this and the battery is not easily removable.  I do not want
>>>
>>> to risk damaging my battery as this is a very expensive laptop.
>> Discharging your battery till the hardware shuts itself off should never
>> harm the battery, the battery-management-controller will turn off all
>> power (simulating removing the battery) before the battery discharges
>> to a level where it can be damaged.  So unless there is some very bad
>> bug in the hw of your laptop this should be safe to do. Otherwise
>> the OS hanging while the battery is already low and you are not
>> present to detect this could also damage the hardware.
>>
>> With recent Linux distributions you need to disable the upower daemon
>> (you probably need to mask it in systemd to avoid it being autostarted)
>> to avoid the auto-shutdown.
>>
>> Note I completely understand if you still do not want to do this,
>> I'm just saying that it is not *that* dangerous.
>>
>> Regards,
>>
>> Hans
>>
>>
>>
>>
>>> Thanks
>>>
>>> for the help though. I will update when something interesting happens
>>>
>>>
>>> Regards,
>>>
>>> Friso
>>>
>>>>> Best regards,
>>>>>
>>>>> Friso
>>>>>
>>>>> On 24/11/2020 12:14, Hans de Goede wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 11/12/20 7:25 PM, Friso Smit wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'm not sure if you have read the previous mails in this thread, but the
>>>>>>> problem is solved, at least for me, with a bios update.
>>>>>> At that is good to know.
>>>>>>
>>>>>>> I don't know how
>>>>>>> it works exactly, but all keys produce different scan codes now. Are there
>>>>>>> still some models where this is a problem?
>>>>>> Yes this is till a problem on at least the hp-pavilion-cx-0598na, see
>>>>>> the mail thread starting here:
>>>>>>
>>>>>> https://lore.kernel.org/platform-driver-x86/CAGTBY+sgwYrDPtQgJV=TcXJ73n8TGf9Nw=arCfWMUrVFzAsEVQ@mail.gmail.com/
>>>>>>
>>>>>> I've just asked the reported of that problem to check if there is a BIOS
>>>>>> update for his system.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Hans
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On 11/9/20 2:44 PM, Hans de Goede wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 11/5/20 5:47 PM, Andy Shevchenko wrote:
>>>>>>>>> +Cc: subsystem maintainers
>>>>>>>>>
>>>>>>>>> On Sun, May 17, 2020 at 2:24 PM<thestroyer@cock.li>  wrote:
>>>>>>>>>> Hi,
>>>>>>>>>> On my HP Zbook studio G5 a few keys on my keyboard give the same
>>>>>>>>>> scancodes. Most notably, the brightness and mute function keys all give
>>>>>>>>>> the scan code sequence 0xe0 0x20 0xe0 0xa0 as reported by showkey
>>>>>>>>>> --scancodes. It only produces a scancode when pressed, not when
>>>>>>>>>> released. I found another very similar issue in this mailing list found
>>>>>>>>>> inhttps://www.spinics.net/lists/platform-driver-x86/msg16791.html. The
>>>>>>>>>> issue in that mail was solved by a bios update. I'm running the latest
>>>>>>>>>> bios, but I still have the issue.
>>>>>>>>>> I tried the kernels: Manjaro 5.7rc4-1, Manjaro 5.6.11-1 and Manjaro
>>>>>>>>>> 5.4.39-1
>>>>>>>>>> I also tried a few other distributions, but they all have the same
>>>>>>>>>> issue.
>>>>>>>>>> I'm happy to provide more information about this issue if needed.
>>>>>>>> So this already came in another thread for another HP laptop model,
>>>>>>>> this seems to be a common issue on some (newer?) HP laptop models.
>>>>>>>>
>>>>>>>> It seems that we need to make some special WMI calls for this, either
>>>>>>>> to figure out which key is actually pressed when receiving the
>>>>>>>> PS/2 scancode which is shared between multiple keys. Or to get the
>>>>>>>> device to send different scancodes.
>>>>>>>>
>>>>>>>> This will require someone with some knowledge of ACPI/WMI as well
>>>>>>>> as of writing kernel code to get physical access to an affected HP
>>>>>>>> laptop to figure out what is going on and write some code to deal with
>>>>>>>> this special setup.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Hans
>>>>>>>>
> 
> Hi,
> 
> It worked! I looked up a video online and apparently it's not that hard to remove the
> battery. For those reading this who will never boot windows again, just remove the
> battery and re-insert it. In my case (HP Zbook Studio G5) I had to remove the battery
> screws as well to make room for disconnecting the battery. I waited a few minutes for
> any remaining energy to drain and reconnected the battery.
> 
> I booted straight to Linux (with Grub). I noticed the keyboard backlight was turned on
> because of the power disconnect, so that's probably a sign to look if it worked.
> Now my brightness keys work again, and the other special keys still work as well.

Good, so now we know that it is some embedded-controller setting which Windows
(or likely some HP specific sw/drivers under Windows) enables, which is causing
this problem.

> At some point I will probably have to boot into windows again, so can I do something
> before that to get some data out of this?

Nothing comes to mind, but maybe others have some good ideas ?  One thing which you
could do is contact HP about this and see if they are willing to provide some help.

If they can just tell us which WMI method (I'm guessing it is a WMI method) Windows
is calling and what we can do to undo that; or how to receive the events in the same
way Windows is receiving them then that would be helpful.

The other options is some kernel-dev with some ACPI/WMI experience getting their
hands on an affected device and then poke around a bit and hopefully figure out
a solution.

Regards,

Hans