USB keyboard connected to laptop doesn't return on waking from sleep (ie `lsusb` doesn't show it til I physically replug). How to diagnose if opensuse software bug or hardware issue?

So I have a USB keyboard plugged into my laptop running opensuse tumbleweed
(KDE, if it’s somehow related to the desktop environment?)

When I wake it from sleep, the keyboard doesn’t seem to return
– ie, it doesn’t show up in lsusb until I physically unplug and replug it.

  • It’s an old ergodox (microcontroller “`OpenMoko, Inc. Teensy 2.0 Development Board”)

  • It’s plugged in through an old usb hub/input-splitter/dongle thingy

  • The laptop’s physical keyboard is german (de)
    but the ergodox is… mostly us.
    (
    or rather, it’s mostly pretending to be us
    – the actual layout is radically different,
    but most of that is hidden away inside the firmware running on the ergodox,
    so the computer mostly just sees it as a mostly normal us
    )

I had it plugged in the same way to a different computer until recently
(until that computer had an unrelated total hardware failure),
and it didn’t have any problem like this with that computer…

How do I diagnose whether this is a software problem with something on my opensuse system,
or some hardware problem with the ergodox itself starting to fail for some reason?

(
I am… obviously pretty paranoid of doing anything that might risk harming the ergodox,
because I am super dependent on it to be able to type normally,
and I am still not done finalizing an emergency plan for what to do if it does fail.
)

So currently, I’m just not sleeping my opensuse laptop overnight.
(
until the last couple days I’ve been doing big backup/copying jobs on my slow old external data drives anyway,
so I wasn’t gonna sleep it anyway
)

That being said, I have indeed rebooted the system 2 or 3 times,
and I’ve never had any problems with the ergodox then

Some suggestions:

To rule out this thingy, can you plug another device in it and see if that shows also the problem?

Would be also good to plug in the keyboard into another port and see if that works.

Also, check the journal after you resume from sleep, i.e. write down the time of the resume and use “sudo journalctl -b” and check for USB related messages around that time. If you need help interpreting them, post them here. Use the Preformatted Text (Ctrl+E), the 6th button in the editor window to format the text.

Thanks.


I have a wireless mouse and a wireless headphone dongle plugged into the same usb hub,
and they never have any problems.


I only just started using journalctl like a week ago honestly.
Does it still have that same bug dmesg has with the --ctime/-T flag,
where it just counts seconds since boot,
and then naively turns that into a “human readable” timestamp,
but completely ignores wake/sleep (ie “suspend to ram” or whatever the official term is)
so the timestamps actually drift further and further back out of sync from the actual real time the longer have your computer running,
if you’re sleeping it every night but not rebooting?


What other diagnostic commands are there I should know about?

I only know of:
lsusb
lshw
xinput
…?

Like I said, I’m paranoid about risking physically(/electronically) “shocking” the hardware somehow,
so I’m trying to do as much of the purely software side of the testing as I can first,
before I start plugging and unplugging it a bunch…

If you have problem with the timestamps, run:

$ su root -c ‘echo “Sleep started” > /dev/kmsg’
$ su root -c ‘echo “Sleep ended” > /dev/kmsg’

Before and after sleep. Then search in the journal for these messages.

If lsusb indicates the device is not there your only hope is the journal and maybe power cycling that “old usb hub/input-splitter/dongle thingy”.

For some, but very few, USB hub you can control the power using software using uhubctrl and that way you could reset things using software.

Oh thanks, you can just pop in your own stuff into the “kernel messages” that easy, eh?
(
I was just trying to look up kmsg now that you told me about it,
but of course I can’t find anything about it directly as a manpage,
but I just found out you can use the -K flag with man like
man -K '/dev/kmsg'
and that’ll search for manpages that mention it
(first one was dmesg)


ah, but if you add -w you’ll get the list like
$> man -w -K '/dev/kmsg'
#=>

/usr/share/man/man1/dmesg.1.gz
/usr/share/man/man8/systemd-journald.service.8.gz
/usr/share/man/man8/dracut.8.gz
/usr/share/man/man5/journald.conf.5.gz
/usr/share/man/man5/systemd.exec.5.gz
/usr/share/man/man7/systemd.generator.7.gz
/usr/share/man/man7/systemd.directives.7.gz

)

… also I just found that journalctl -k (long --dmesg) gets you basically the output of dmesg.
(Not sure yet if the timestamps drift the same or work differently. They’re currently the same, but I don’t think I’ve slept the computer since last boot-up.)


So what’s the best way to make something run before sleep and after resume?
(
Like, should I be looking at cronjob options?
Or systemd-timers?
(
I still haven’t gotten around to learning anything about systemd-timers…
From my first very superficial glance they looked kinda verbose and boiler-plate-y,
but for all I know they’re actually really powerful/flexible/reliable…
)
Or should I be looking at something KDE-specific?
(As far as I can find the only related thing is the KDE systemsettings kcm_autostart GUI, and that only seems to deal with boot-up (or well, sign-in))
)


Although, the fact that you told me I should do the kmsg thing manually I guess implies that nothing in any of the inputs for journalctl records anything about sleep/wake by default?

So I can’t just grep back through journalctl for whatever points I can find directly after a wake/resume-from-suspend
(again, wish I knew for sure what the official terms actually were…)
and just see what happened directly after that?


[Thanks for telling me about uhubctl. Still looking into it…]

I can not follow you here. Did you try to the kernel messages added? Did you see them ending up in the journal? What is in between these lines?

cronjob, systemd-timers

Both are doing something at a particular time, that is not immediately what you want. systemd works with “events” and you an specify some action to be done some time after a event happens.

If you like to go that way, better have first a look at:

https://www.01signal.com/other/usb-device-stuck-reset/

Thank you!

(Yeah, uhubctl is firmly still on the backburner for now.)


Right, but I can’t find anything similar to:
man systemd.event
or:
man systemd-event

What should I be looking for?

I found this file:
/etc/systemd/sleep.conf
should I be working with that?

To be clear, I mean I’m trying to figure out how to take:
su root -c ‘echo “Sleep started” > /dev/kmsg’
and
su root -c ‘echo “Sleep ended” > /dev/kmsg’
and make them automatically run before and after sleep respectively
(as close as possible to the last/first thing before/after that sleep).


I meant:
there wouldn’t be any entries already in the journal marking where the computer woke up from sleep?

ie, there really won’t be anything in the journal marking where the computer woke from sleep
unless I do something myself to make it start adding those entries?

(
Because if there was something in the journal before I add it myself,
then I could search backwards and find the sections of the journal for what already happened in the past
(ever since I first started using this keyboard with this computer)
whenever I’ve woken this computer from sleep.
)

Because on one hand, I’d be very surprised that nothing in the journal already by default marks wake-from-sleep,
but on the other hand, like I said:

Why automatically?? You can manual initiate the sleep and wake and it is for debug only so why not do it by hand?

On systemd:

On your questions on what will be in the journal: I do not see a reason to speculate, just review the log and share it if you need help to interpret it.

Why automatically?

It just seemed… obviously like a bad idea to not make the effort to learn to do it the right way?

Since it’s something highly generalizable that I should really learn anyway,
and I just know that if I don’t set it up to catch everything automatically
(which I would think it should already be doing by default),
then the problem is bound to occur some time when I didn’t happen to have manually pre-prepared to catch it or whatever,
and I’ll miss it, etc…