Connecting 8BitDo Micro (HID Keyboard) to legacy PocketBook 912 — "Permission Denied"

[SERG-987]

Originally Posted by rkomar

I have some JTAG devices lying around, but nothing like that. I thought I would try attaching to my 902 if I had the hardware for it already, but I don't want this enough to order new equipment for it. Still, I have enjoyed seeing how you got it done. Thanks for the progress reports.

https://aliexpress.com/item/1005004411693590.html

[SERG-987]

https://aliexpress.com/item/1005006011029284.html

[SERG-987]

Device Background:
Host: PocketBook 912 (released 2011), running Linux kernel 2.6.35.
Peripheral: 8BitDo Micro (released 2024/2026), modern Bluetooth 5.0+ controller.
OS Environment: Minimalist BusyBox, BlueZ 4.x stack (incomplete), Read-Only root filesystem.
Work Accomplished:
Environment Preparation: Gained root access and successfully remounted the root filesystem as Read-Write (mount -o remount,rw /) to create necessary symlinks (/opt) and system directories (/var/run/dbus).
Software Stack: Manually ported a more complete BlueZ 4.66 stack from Debian Squeeze (armel). This included bluetoothd, hidd, sdptool, and bluetooth-agent.
Library Dependency Resolution: Systematically resolved missing library dependencies by manual injection. Successfully added:
GLib 2.24 (and related gthread, gmodule, gio)
libdbus-1.so.3
libcap-ng.so.0
libpcre.so.3
D-Bus Configuration: Configured and successfully launched dbus-daemon as root, establishing the system_bus_socket.
Service Discovery: Successfully used sdptool browse to identify the 8BitDo Micro's HID services (Keyboard mode). Physical radio communication was verified.
The Fatal Obstacle (GLIBC Incompatibility):
The final attempt failed due to a fundamental mismatch between the system's C library and the ported binaries.
System GLIBC: 2.6.1 (compiled 2008).
Ported Binary Requirement: GLIBC 2.7 / 2.9.
Result: Even with a localized LD_LIBRARY_PATH pointing to a newer libc.so.6 (v2.11.3) extracted from Debian Squeeze, the binaries (specifically dbus-daemon and bluetoothd) triggered a Segmentation Fault.
Root Cause: A critical conflict between the system's old dynamic linker (/lib/ld-linux.so.3) and the newer GLIBC libraries. On this specific 2011-era firmware, the architecture gap between GLIBC 2.6 and 2.9 is insurmountable without recompiling the entire toolchain or using a chroot/container (which is resource-prohibitive for the PB912).

[rkomar]

Packages from Debian Lenny are compatible with these devices. Can you use the BlueZ stack from that distro instead?

Way back in 2012, I installed that version of debian using qemu. The install ISO I saved contains bluez-3.36. If you are really desperate, you could try doing the same thing, and then use that emulated system to build source packages from newer versions of debian. It would be a significant amount of work, though. I vaguely remember that @LoneTech uploaded the qemu images and scripts he used back then for building software. Perhaps you can find the pre-built images somewhere rather than build it yourself from scratch.

[SERG-987]

I considered rolling back to the BlueZ 3.x stack from Debian Lenny, since its libraries (Glibc 2.7) are potentially compatible with the reader's system. However, this would lead to another dead end: BlueZ 3.x lacks hardware support for the SSP (Secure Simple Pairing) protocol, which is a mandatory requirement for 8BitDo Micro gamepads. Thus, we are facing a classic 'Catch-22': the old software is compatible with the OS but incompatible with the gamepad, while the new software is compatible with the gamepad but breaks the OS."

[rkomar]

As I mentioned above, you could install Debian Lenny into a qemu-emulated system, and then build the newer bluez source packages in that to later install on your device. The packages you built in that system would be compatible with the software on your device.

[SERG-987]

Thanks a lot for all the ideas and explanations, especially the suggestion to use a qemu‑emulated Debian Lenny environment to rebuild newer BlueZ packages that are ABI‑compatible with the reader.

It really helped to clarify where the practical limits are for this hardware and kernel, and why going backwards to BlueZ 3.x or trying to push too new a stack onto 2.6.29 is unlikely to solve the 8BitDo Micro issue.
=======================

What the hidd log shows

The kernel HID layer is active and old:

Bluetooth: HIDP (Human Interface Emulation) ver 1.2 → classic HIDP implementation from the 2.6.x era.​

The Apple keyboard (A1314, 2009) is fully accepted:

input: Apple Inc. Keyboard as /class/input/input3

generic-bluetooth 0005:05AC:023A.0001: input: BLUETOOTH HID v0.50 Keyboard [Apple Inc. Keyboard] on 00:90:A2:6A:757
This means the HID control/data channels were established successfully and the kernel created a working input device node.​

The hidd cache file confirms both devices are paired and trusted:

/var/tmp/lib/bluetooth/00:90:A2:6A:757/hidd contains two entries:

E4:178:6B:ABB 2DC8:9021:0100 ... 8BitDo Tech Ltd Keyboard

78:CA:39:49:73:BD 05AC:023A:0050 ... Apple Inc. Keyboard
Each line has MAC, VID:PID:version, the full HID report descriptor, and the device name.
This proves that:

pairing and link keys for both devices were stored successfully;

the system recognizes both as HID keyboards and keeps them in the same HID cache.​

LMP versions show the generation gap:

8BitDo Micro: LMP Version: (0x8) → Bluetooth 4.x controller.​

Apple A1314: LMP Version: 2.0 (0x3) → classic Bluetooth 2.0 device.​
Both expose HID over PSM 17 in SDP, but they belong to very different protocol generations.

What this confirms
The PocketBook does support SSP and can pair with both the Apple keyboard and the 8BitDo Micro (the presence of both entries in hidd proves SSP/pairing succeeds, not fails).​

The Apple keyboard’s legacy HID implementation is fully compatible with HIDP 1.2, so the kernel creates input3 and it works as a normal keyboard.

The 8BitDo Micro is also seen as a HID keyboard and its descriptor is stored, but HID control channel setup fails at runtime, leading to:

Can't create HID control channel: Connection refused / reset by peer / timed out in user‑space tools during connect attempts (not shown in this snippet, but in previous logs).​

So the limiting factor is not pairing, not keys, and not configuration files, but the age of the HIDP 1.2 + BlueZ 4.47 stack versus the modern HID behavior of a Bluetooth 4.x controller:

old Apple A1314 (BT 2.0) fits exactly into what HIDP 1.2 was written for → works;

8BitDo Micro (BT 4.x, modern HID) can pair and gets cached, but the old HIDP implementation cannot complete the HID connection handshake, so the device never becomes a usable input device on this firmware.​


hidd

Spoiler:

E4:178:6B:ABB 2DC8:9021:0100 40 21 0111 05010906A1018501050719E029E71500250175019508810295 01750881039505750105081901290591029501750391039506 7508150026FF000507190029FF8100C0050C0901A101850315 0026800319002A8003751095018100C005010980A101850405 011981298315002501950375018106950175058101C000 00000000 8BitDo Tech Ltd Keyboard
78:CA:39:49:73:BD 05AC:023A:0050 40 0D 0111 05010906A1018501050719E029E71500250175019508810275 08950181017501950505081901290591027503950191017508 9506150026FF00050719002AFF008100C0050C0901A1018547 05010906A10205060920150026FF00750895018102C0C0050C 0901A10185111500250175019503810175019501050C09B881 0206FF0009038102750195038101050C851215002501750195 0109CD810209B3810209B4810209B5810209B6810281018101 8101851315002501750195010601FF090A81020601FF090C81 227501950681018509090B75089501B10275089502B101C000 00000000 Apple Inc. Keyboard