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@xxxxxxxxxxxxxx/
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@xxxxxxx> 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
