You are not logged in.
Hello, users of the archwiki!
I am trying to run arch linux on this Lenovo Ideapad and for some reason (both in tty and linux), specific keys such as (8,i,k and , itself) stops and starts working randomly. The frequency of bugging is more of like after coming from sleep and booting but sometimes it occurs randomly as well. The keys just stop working.
i am very lost and I am not sure on what I should post for better intel and therefore i am linking my journalctl -b and dmesg info for better context.
Journal from boot:- https://0x0.st/8Ad3.log
Dmesg:- https://0x0.st/8Adg.log
for more clue, i found that 8,i,k and , itself designates under the same keyboard column.
I am not sure how to continue from this bug and I couldn't find a temporary work around it.
It will be immensely helpful if someone could provide any kind of support related to a fix or a temporary solution.
i like unix
Offline
There's nothing that would be in any keyboard driver that would randomly discriminate against these specific keys. This is most likely HW. Did you drop the thing at some point? Is it bent around the part? Some dust in between the keys? Can you remove it and check whether any of these things are the case? Your best bet for anything that would be software would be at most a UEFI/BIOS update but that's extremely unlikely.
Can you reproduce any of this with an external keyboard?
Offline
There's nothing that would be in any keyboard driver that would randomly discriminate against these specific keys. This is most likely HW. Did you drop the thing at some point? Is it bent around the part? Some dust in between the keys? Can you remove it and check whether any of these things are the case? Your best bet for anything that would be software would be at most a UEFI/BIOS update but that's extremely unlikely.
Can you reproduce any of this with an external keyboard?
Hello there, V1del, Thanks a lot for your response ![]()
Nope, The touchscreen/tablet/laptop (Lenovo Ideapad D330-10IGL) which I have been using is a brand new and there is nothing wrong with the keyboard, absolutely (in terms of its current physical status). There is no bent or obstacle or dust between these keys whatsoever.
I have dual-booted this laptop with windows and i havent found any bugs related with the keys in question (yet). The keys are working for me in linux (at the moment) but it still frequently stops me from using the keys in the column.
Can you reproduce any of this with an external keyboard?
Nope, external keyboard works just fine for me. I still dont think this is a relevant factor because ive used windows for around 4 months in this and just recently changed into linux and I havent experienced this issue with the keyboard before.
Last edited by thetareefarz (2025-02-27 03:51:53)
i like unix
Offline
dual-booted this laptop with windows
3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.
ive used windows for around 4 months in this and just recently […] experienced this issue
Things work and then they're broken. The circle of life.
The thing that gives away "hardware" wa stated by yourself:
i found that 8,i,k and , itself designates under the same keyboard column.
The problem might be temperature driven.
What is *under* that column in the case? And does it heat up?
Offline
3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.
Hello seth, thank you for your response.
I dont think the 3rd link wont do much considering ive decided to delete everything in this device and reinstall windows and use it for an entire day.
The result: No problem with the keys whatsoever, not even once
I have reinstalled a fresh copy of arch linux just now and ive experienced this key problem 3 times already. It fixes automatically in the most random moment and its quite annoying sometimes.
The problem might be temperature driven.
What is *under* that column in the case? And does it heat up?
I have never experienced any sort of heating up in this computer, whatsoever. The keyboard doesnt even heat up because its an attachable keyboard, it has no cpu or nothing whatsoever. The main computer is in the screen itself. This is a tablet computer with an attachable keyboard. Let me send pictures of my device for better clarification.
https://imgur.com/a/H3cMzjQ
https://imgur.com/a/JHPpOdy
https://imgur.com/a/QCRpMH5
https://imgur.com/a/zJj12vN
Last edited by thetareefarz (2025-02-27 14:35:15)
i like unix
Offline
How is this attached? USB? i2c? Bluetooth??
I can easily see kernel/powersaving related issues w/ the bus, but limited to one key column is beyond odd and yells "mechnical/electrical problem".
Does this also happen w/ some live distro like grml?
And just to be clear, if you've not properly shutdown windows - it's in hibernation afa the BIOS/UEFI/ACPI is concerned.
Even if you format the partition or so.
Offline
How is this attached? USB? i2c? Bluetooth??
The attachable keyboard provides some indent and magnet in the end of it so it can align with the tablet computer to make it work (sort of like an i-pad)
I can easily see kernel/powersaving related issues w/ the bus, but limited to one key column is beyond odd and yells "mechnical/electrical problem".
Does this also happen w/ some live distro like grml?
I haven't really experienced this sort of problem with a live distro (yet).
And just to be clear, if you've not properly shutdown windows - it's in hibernation afa the BIOS/UEFI/ACPI is concerned.
Even if you format the partition or so.
I clearly remember shutting down the computer to get some lunch and then start working aftermath so I don't believe there is any problem with the bios/uefi.
Thank you.
i like unix
Offline
yes and shutting down from windows without ensuring fast boot is disabled will leave you in a logically inconsistent state. If you have a Windows again, make sure that it is disabled. Note that whether you wiped Windows doesn't matter. If it was booted just once and this setting was not adjusted before shutting down the firmware will be in a state that expects a Windows hibernation image to reinitialize it. This generally bites itself with different operating systems.
If you need more proof than taking our word for it, here's a very recent fallout from this: https://bbs.archlinux.org/viewtopic.php?id=303718
Last edited by V1del (2025-02-27 17:11:27)
Offline
The attachable keyboard provides some indent and magnet in the end of it so it can align with the tablet computer to make it work (sort of like an i-pad)
Q: What kind of car do you have?
A: A green one!
I asked for the bus, not how it's phyically tied to the system ![]()
Please post your complete system journal for a boot w/ the keyboard attached
sudo journalctl -b | curl -F 'file=@-' 0x0.stalso
lsusb -tvOffline
I asked for the bus, not how it's physically tied to the system
I am extremely sorry for the inconvenience and lack of understanding. I am not very familiar with the technicalities
which makes me difficult to discuss about these things.
I am not sure what bus means but research leads me to the fact that bus basically refers to the medium from which 2 things communicate.
I am pretty its in the lsusb part given below
Journal: https://0x0.st/8mj8.txt/
lsusb: https://0x0.st/8Ad3.log/
Thanks in advance for your kind help.
Last edited by thetareefarz (2025-02-28 12:03:17)
i like unix
Offline
If you need more proof than taking our word for it, here's a very recent fallout from this: https://bbs.archlinux.org/viewtopic.php?id=303718
I am sorry for the misunderstanding, I don't need any proof or anything, any support I can get from anything for this issue is extremely helpful and I am grateful for it.
I have already deleted windows before I have disabled fast-boot so there is no chance of disabling it now. The other options which are left is to unplug the CMOS battery and resetting the BIOS. The thing is that the computer is fully soldiered with the display so there is no chance of me pulling out the CMOS (atm). I resetted the BIOS and the problem still persists.
i like unix
Offline
No need to be sorry, it was rather amusing ![]()
The lsusb output is the journal again (wrong link, don't freak out) but there's
Feb 28 12:55:30 ln kernel: input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3
Feb 28 12:55:30 ln kernel: hid-generic 0003:17EF:60C8.0001: input,hidraw0: USB HID v.11 Keyboard [HAILUCK CO.,LTD Lenovo HID Device] on usb-0000:00:15.0-5.2/input0and from a quick google I assume it's the HAILUCK usb thing. (the i8042 keyboard shows up around the camera) - you can check "libinput debug-events" to see on what input device the keyboard generates input.
https://wiki.archlinux.org/title/Power_ … utosuspend
Add "usbcore.autosuspend=-1" to the https://wiki.archlinux.org/title/Kernel_parameters
Offline
The lsusb output is the journal again (wrong link, don't freak out) but there's
Sorry for the error, I have fixed the link.
i like unix
Offline
you can check "libinput debug-events" to see on what input device the keyboard generates input.
just for more context, here is the libinput debug-events output: http://0x0.st/8m2B.log/
Apparently the device is under event5 which is:
-event5 DEVICE_ADDED HAILUCK CO.,LTD Lenovo HID Device seat0 default group5 cap:ki will try out autosuspend kernel parameter and let you know with more details.
Thank you for your support.
i like unix
Offline
the problem perssts
i like unix
Offline
Post a system journal that actually covers the loss of those keys (and ideally also their return)
Also, how do you determine their failure (do they still generate inoput in evtest/libinput debug-events)
It fixes automatically in the most random moment
Either something is just grabbing them or this is a hardware problem - and if it's not the hardware stumbling over the bus autosuspend nor a mechanical (tension) or electrical (static build up) problem, I've no good idea what would make a single column of the keyboard fail - can you btw. force the "fix" by re-attaching the keyboard?
Offline
tred both lbnput and evtest a few mn ago and no the heys do not regster on the output of both of the test.
reattached the heyboard and stll no change.
am stll gong through ths problem atm and me shall post the journal related wth ths sesson:
journal: http://0x0.st/8mRz.txt
dmesg: http://0x0.st/8mRH.txt
(me wll correct the post once me gets hand on a external heyboard or the attachable one fxes randomly.)
Last edited by thetareefarz (2025-03-01 12:51:26)
i like unix
Offline
Feb 28 18:15:30 ln kernel: usb 1-5.2: new full-speed USB device number 6 using xhci_hcd
Feb 28 18:15:30 ln kernel: usb 1-5.2: New USB device found, idVendor=17ef, idProduct=60c8, bcdDevice= 0.06
Feb 28 18:15:30 ln kernel: usb 1-5.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Feb 28 18:15:30 ln kernel: usb 1-5.2: Product: Lenovo HID Device
Feb 28 18:15:30 ln kernel: usb 1-5.2: Manufacturer: HAILUCK CO.,LTD
Feb 28 18:18:09 ln kernel: usb 1-5.2: USB disconnect, device number 6
Feb 28 18:18:12 ln kernel: usb 1-5.2: new full-speed USB device number 8 using xhci_hcd
Feb 28 18:18:18 ln kernel: usb 1-5.2: New USB device found, idVendor=17ef, idProduct=60c8, bcdDevice= 0.06
Feb 28 18:18:18 ln kernel: usb 1-5.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Feb 28 18:18:18 ln kernel: usb 1-5.2: Product: Lenovo HID Device
Feb 28 18:18:18 ln kernel: usb 1-5.2: Manufacturer: HAILUCK CO.,LTD
Feb 28 19:25:18 ln kernel: usb 1-5.2: reset full-speed USB device number 8 using xhci_hcd
Feb 28 21:49:25 ln kernel: usb 1-5.2: reset full-speed USB device number 8 using xhci_hcd
Feb 28 21:54:29 ln kernel: usb 1-5.2: reset full-speed USB device number 8 using xhci_hcd
Feb 28 22:03:04 ln kernel: usb 1-5.2: reset full-speed USB device number 8 using xhci_hcd
Mar 01 12:28:20 ln kernel: usb 1-5.2: reset full-speed USB device number 8 using xhci_hcd
Mar 01 12:36:32 ln kernel: usb 1-5.2: USB disconnect, device number 8
Mar 01 12:36:32 ln kernel: usb 1-5.2: new full-speed USB device number 10 using xhci_hcd
Mar 01 12:36:37 ln kernel: usb 1-5.2: New USB device found, idVendor=17ef, idProduct=60c8, bcdDevice= 0.06
Mar 01 12:36:38 ln kernel: usb 1-5.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Mar 01 12:36:38 ln kernel: usb 1-5.2: Product: Lenovo HID Device
Mar 01 12:36:38 ln kernel: usb 1-5.2: Manufacturer: HAILUCK CO.,LTD
Mar 01 18:43:39 ln kernel: usb 1-5.2: reset full-speed USB device number 10 using xhci_hcd
Mar 01 18:47:36 ln kernel: usb 1-5.2: USB disconnect, device number 10
Mar 01 18:47:49 ln kernel: usb 1-5.2: new full-speed USB device number 12 using xhci_hcd
Mar 01 18:47:54 ln kernel: usb 1-5.2: New USB device found, idVendor=17ef, idProduct=60c8, bcdDevice= 0.06
Mar 01 18:47:54 ln kernel: usb 1-5.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Mar 01 18:47:54 ln kernel: usb 1-5.2: Product: Lenovo HID Device
Mar 01 18:47:54 ln kernel: usb 1-5.2: Manufacturer: HAILUCK CO.,LTDThe disconnects are all after waking the system up, the disconnects are probaly "you"?
My lat best guess is radio interference.
Can the keyboard be used detached (eg. via blutooth)?
What happens when you rfkill bluetooth and wifi?
1. does the keyboard break?
2. can you now actually reliably use it?
Offline
Can the keyboard be used detached (eg. via blutooth)?
Nope, it has no bluetooth connection or wireless connectivity.
What happens when you rfkill bluetooth and wifi?
I rfkilled all the available wireless interfaces i have in this computer but none of them did anything to fix the key issue.
I truly think this is a driver or a problem with a kernel because while ive used windows in this computer, I have never ever experienced this problem.
What do you think about what should I do, regarding the problem? I am thinking of reinstalliing windows and daily driving it for couple of weeks/months and see
if the key problem ever occurs to me.
Thanks for your help.
Last edited by thetareefarz (2025-03-02 07:07:34)
i like unix
Offline
ive decided to delete everything in this device and reinstall windows and use it for an entire day.
The result: No problem with the keys whatsoever, not even onceI have reinstalled a fresh copy of arch linux just now and ive experienced this key problem 3 times already.
But
I truly think this is a driver or a problem with a kernel
The problem with that is that there's nothing special about those keys.
A driver/kernel bug that makes a specific column of your keyboard w/o any logical system to the keys is beyond unlikely, nNotably since there's not a great many deal of keyboard drivers around (it's rather standard input).
So the answer is more likely that either something causes a really weird issue w/ the bus (again: no logical system to those keys) or that something triggers mechanical/electrical issues with the keyboard (heat or its power supply - I assume it doesn't have its own batteries but gets fully powered via usb?)
It's also not a programmable keyboard, ie. you're not installing a special windows driver that then uploads firmware to the device to redefine the keys (feature often found in gaming-marketed keyboards)
We btw. have still not seen the bus layout, the supposedly fixed link is just another journal.
Offline
hardware problem, not related with software.
Thanks for your time and your help.
Last edited by thetareefarz (2025-03-09 12:29:57)
i like unix
Offline