I found that xinput --test-xi2 --root and xinput --test-xi2 --root <keyboard_id> work.

I tinkered with ralph.ronnquist's solution in post #13 and figured out that this is what's actually going on when you decompress the logic:

$ master_id=$(LANG=C xinput list | grep -i 'master keyboard' | egrep -o 'id=[0-9]+' | egrep -o '[0-9]+')
$ keyboard_id=$(LANG=C xinput list $master_id | grep 'XIKeyClass' | egrep -o '[0-9]+')

This version is easier for my pea brain to grasp.

Yes, that works even on my wife's wonky hardware where multiple "slave keyboards" are listed.

eileen@vaio:~$ xinput list --id-only | xargs -n 1 -I+ sh -c "xinput list + | grep -wv + | grep XIKeyClass" | egrep -o '[0-9]+'
12

Wow, ralph.ronnquist. Very impressive. Thank you!

I understand the logic of the command, but don't understand how you figured out that it was the necessary logic. Will chew on it.

BTW, I had also found that nugget on stackexchange, but do not want to give users anything in addition to the shell script I've created. The script is here if you are curious:
https://github.com/bdantas/iksilo

Thank you both. I think we're getting warmer. Does this work on all your test systems?

LANG=C xinput --list | grep -i keyboard | egrep -iv 'virtual|video|button|bus' | egrep -o 'id=[0-9]+' | egrep -o '[0-9]+'

For what it's worth, I find FSF/GNU and OpenBSD folks equally trustworthy. They bicker a lot over licensing, style, and other fine points, but the fact that both camps insist on source code being available tells me they have nothing to hide.

Unless a person decides he will become an island to himself and use only his own products, we have no choice but to trust others. So the question is not whether to trust, but who to trust. When it comes to software, I completely trust the FSF/GNU and OpenBSD folks (unless they are talking about each other ).

alupoj, if you care this much about your hardware not having backdoors (as I do and as we all should), then you need to use a computer that does not have proprietary BIOS or, even worse, Intel Management Engine or (AMD's) Platform Security Processor. See https://www.fsf.org/blogs/sysadmin/the- … rs-freedom

If you don't already, you should be using a computer with Libreboot (i.e., no proprietary BIOS and Intel Management Engine completely disabled). You can get a laptop with Libreboot on Minifree, Technoethical, or Vikings. They may be more vendors, but these are the ones I know of. I have been happily using a T400 with Libreboot (on which I dual-boot Devuan and OpenBSD) for several years. Everything works perfectly except for virtualization, which I have had to sacrifice. The choice between security and convenience affects everybody.

I second HoaS's plug for OpenBSD. Devuan is one of the the best GNU/Linuxen around, but GNU/Linux in general is not about being "most secure". If most secure is what you're looking for, that's what OpenBSD does by default--no need to swap key software components or tweak configuration settings.

TL;DR version:
    This HP printer's dhcp client is flaky. If the printer's dhcp lease expires while printer is off, the printer cannot reliably get back on the network after being powered on--despite what its friendly beeps and lights might lead one to believe. Configuring router's dhcp server (dnsmasq) to give the printer a non-expiring ("infinite") lease solved the problem.

-----

Detailed version:
    I was able to consistently reproduce the problem by turning printer off, revoking printer's dhcp lease (in router: # pkill dnsmasq,  delete the line in /var/lib/misc/dnsmasq.leases that shows printer's lease, # dnsmasq), then turning printer back on. After printer fully powers on, its blue network light blinks for a little while then printer makes a friendly beep and blue light goes steady to indicate it has a network connection--which I found to be a big lie. In my experiments I found one of three things to always be true:

1. Printer takes a long time to negotiate a new dhcp lease--no new lease shows up in router's dnsmasq.leases (and printer is not reachable by ping or traceroute) until several minutes after printer's blue light is steady
2. Printer does not negotiate a new dhcp lease at all until I push some buttons on its little screen asking it to display its network settings
or
3. Printer never actually negotiates a new dhcp lease and reports that it has an ip address that is not even on my network (169.254.227.111)

Explaining the problems I was experiencing:
    Sometimes the kids turn off the printer and it is off for a few days until we find ourselves having to print again, by which time the printer's 24-hour dhcp lease has certainly expired. Those times it seemed that I needed to reboot my laptop before I could print again were probably due to situation #1 above--me rebooting was simply giving the printer enough time to finish negotiating a new lease with my router.

The solution:
    Configure printer to do as little as possible network-wise (in its settings, choose "get address automatically", provide the wireless network password, and that's it) and let the router not only assign the desired static IP but also make the lease non-expiring. This line in dnsmasq.conf takes care of both things: dhcp-host=aa:bb:cc:11:22:33,192.168.10.7,infinite (where aa:bb:cc:11:22:33 is the printer's MAC address, of course).
    Now when I turn the printer off and back on, it quickly gets on the network (can be reached by ping and traceroute) and can print reliably.

I hope this helps someone. I've been scratching my head on and off because of this for well over a year at this point.

Thank you, Head_on_a_Stick. It seems NetworkManager parses /etc/dhcp/dhclient.conf then appends a few lines, to produce /var/lib/NetworkManager/dhclient-wlan0.conf. The latter file already contains request;. This is what the complete /var/lib/NetworkManager/dhclient-wlan0.conf looks like:

Any idea what needs to be changed in order to achieve the desired behavior?

The dnsmasq man page solved the mystery of dhcp always giving particular computers particular IP addresses:

The --dhcp-sequential-ip flag causes dnsmasq's behavior to be what I expected. Hope this helps anyone who finds themselves doing some head-scratching as I was

Hmm, I was curious about the ?zc= suffix in the printer's URI. An internet search tells me the zc stands for zeroconf and is related to avahi-daemon.

https://bugs.launchpad.net/hplip/+bug/521909

The strange thing is that avahi-daemon is not running on my machines because I disabled it (it is privacy-unfriendly). (Maybe I disabled avahi-daemon after installing the printer? I installed ASCII and setup the printer a long time ago and can't remember.) Maybe the ?zc= suffix has something to do with the flaky connection to the printer. I'll try re-creating the printer with the ?ip= suffix in its URL followed by its local ip address.

UPDATE:
I reconfigured the printer:

eileen@vaio:~$ lpstat -s
system default destination: HPWireless
device for HPWireless: hp:/net/Photosmart_7520_series?ip=192.168.10.7

Not sure if the new URI will cause the printer to be reachable more consistently, but it sure looks better!

Here is some basic printer information:

eileen@vaio:~$ lpstat -s
system default destination: HPWireless
device for HPWireless: hp:/net/Photosmart_7520_series?zc=HPA0D3C1E1E36F

Ping and traceroute can't reach the printer when the problem occurs. Strangely, I cannot reproduce the problem at will--it seems to happen randomly.

Here are results when I can print:

eileen@vaio:~$ ping -c 1 -W 2 192.168.10.7
PING 192.168.10.7 (192.168.10.7) 56(84) bytes of data.
64 bytes from 192.168.10.7: icmp_seq=1 ttl=255 time=1.86 ms

--- 192.168.10.7 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.861/1.861/1.861/0.000 ms

eileen@vaio:~$ traceroute 192.168.10.7
traceroute to 192.168.10.7 (192.168.10.7), 30 hops max, 60 byte packets
 1  HPE1E36F (192.168.10.7)  4.685 ms  4.918 ms  4.886 ms

Here are results when I cannot print:

eileen@vaio:~$ ping -c 1 -W 2 192.168.10.7
PING 192.168.10.7 (192.168.10.7) 56(84) bytes of data.

--- 192.168.10.7 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

eileen@vaio:~$ traceroute 192.168.10.7
traceroute to 192.168.10.7 (192.168.10.7), 30 hops max, 60 byte packets
 1  192.168.10.187 (192.168.10.187)  1069.930 ms !H  1069.884 ms !H  1069.869 ms !H

Why is it that I need to reboot the computer (not the printer) in order to be able to print again?