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.