Your message dated Wed, 26 Nov 2025 13:02:05 +0100
with message-id <[email protected]>
and subject line Re: Bug#325495: bluez: bt hid support in early boot without
hid proxy
has caused the Debian Bug report #325495,
regarding bluez: bt hid support in early boot without hid proxy
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
325495: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=325495
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: bluez-utils
Version: 2.19-1
Severity: wishlist
Hi,
I'm using a bunch of bluetooth HID devices (Logitech diNovo, mouse/keyboard/
mediapad), which work quite well with bluez in general. I have auth/encrypt
enabled in hcid.conf. Now, if for some reason the pairing between the dongle
and the input devices is lost (because I used it with another computer, or
because I rebooted in Windows where I have to repair the devices - the
link keys of the widcomm stack are obfuscated, so I can't use the same link
keys on both OS) - then I have to attach another keyboard to log in (GDM),
open a terminal, use hidd --connect (and possibly /etc/init.d/bluez-utils
restart when it complains about a failed "Device Exchange" or something),
type in the pair code with the wired keyboard, and only then will my wireless
keyboard work again.
Now, it seems this should be possible in a more user-friendly manner.
- On boot it should try to connect hidd with previously paired devices.
- If permission is denied, we know the link keys have changed, and it should
initiate a pairing with the keyboard. Then it either:
- displays a randomly generated pin key,
or
- uses a sysadmin set preset key a la bug #239820 and bluez-pin-preset.
... so all that's left to do is type it in the wireless keyboard, and enter.
Now, ideally I'd like to have access to my keyboard quite early, that's why I
say "on boot" (I guess if the user's using something like bootsplash/splashy/
... it might still be a problem). The other possible moments where one could
show a "pregenerated pin key" screen would be during the GDM/KDM/XDM screen, or
during the user's session, but one might wonder how one would log in without a
keyboard.
Other issues to consider:
- is this only for HID devices, or would it be benificial for other types too?
- what about HID devices without numeric input (like mice), should the pin key
"0000" be given immediately in that case?
- maybe it's possible to show the "pregen pin key" screen whenever a "connect"
button on a device is pressed. In this case, would it be only for previously
paired devices, or for all devices? (at the risk of showing a pin screen on
all bluez-equipped pc's in range).
Thanks for your consideration...
-- Mourad DC
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1-k7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages bluez-utils depends on:
ii bluez-pin 0.25-1 Bluetooth PIN helper with D-BUS su
ii dbus-1 0.23.4-6 simple interprocess messaging syst
ii libbluetooth1 2.19-1 Library to use the BlueZ Linux Blu
ii libc6 2.3.5-5 GNU C Library: Shared libraries an
ii libusb-0.1-4 2:0.1.10a-21 userspace USB programming library
ii module-init-tools 3.2-pre8-1 tools for managing Linux kernel mo
ii modutils 2.4.27.0-3 Linux module utilities
ii sysvinit 2.86.ds1-1.1 System-V like init
bluez-utils recommends no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
I think after 20 years it's time to close this bug.
For people still looking for solutions for this, there are several
workarounds:
- use dracut: https://github.com/dracutdevs/dracut/pull/1139
- use standard packages with mkosi-initrd
- unlock your root partition with TPM2, and your home directory on login
with systemd-homed or something similar
- …?
Anyway, I think the landscape changed enough and there's ways to deal
with this now, so it's probably time to close this.
Thank you,
-- Mourad DC
--- End Message ---
