Comment 17 for bug 1822633

I've recently found that while pairing with this pen does not work, "merely" connecting to the pen does work. That is:

# This command fails
$ echo -e "scan on\npair <MAC>\nscan off" | bluetoothctl

# But this command works
$ echo -e "scan on\nconnect <MAC>\nscan off" | bluetoothctl

Looking through the hcidump logs, it appears that "connect" has lower (really, "no") security requirements, which could explain why it succeeds where pairing fails (the AuthReq = 00 sent from the device implies it doesn't want/support security).

I see that GNOME ships /usr/share/gnome-bluetooth/pin-code-database.xml which defines default PINs. Inside the file, it says "the special NULL pin means that the devices will not be paired, but connected to and marked as trusted. This is for devices such as mice and joypads where there is no encryption." If I add the pen to the database by adding the following lines at the top of the "device" section, GNOME pairing starts working (although it seems to be a little hit-or-miss):

<!-- Dell Stylus -->
<device oui="BC:82:5D:" name="Dell PN557W Pen" pin="NULL"/>

====================

With the connection fix in place, a new issue has been identified. Specifically, the kernel input device is removed after processing just a single Bluetooth HID event. Looking at the output of "journalctl -b0", I see the following error message logged, followed by normal device disconnect messages:

bluetoothd[6318]: Error Reading PNP_ID value: Request attribute has encountered an unlikely error

Looking at the hcidump logs, it seems that when the pen's Bluetooth button is pressed, it briefly wakes up only long enough to send a HID report to the system. After doing so, it disconnects to save power. The logs show that the system begins requesting information from the device when it connects, and that it gets a response to some of those requests, but at some point (e.g. when asking for PNP_ID) the device goes to sleep and a response is never returned.

It would seem that there either the system needs to not re-ask the device for information like PNP-ID (which it already received in the initial "connect" process and should have associated with its MAC) or to not be so stringent when these requests fail.