Message with Mouse Bluetooth [ 32.960478] hid-generic 0005:099A:0500.0001: unknown main item tag 0x0 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1385113
This is still present in 4.0.0. Bluetooth keyboard disconnects, bluetoothd seems to crash, etc. Do you need any further information to help debug this? This bug makes the bluetooth keyboard unusable.
Same in 4.2.0 (-34-generic in Ubuntu 15.10).
Bluetooth behavior was good in ubuntu 15.10 - bluez5.35, blueman device manager and kernel 4.3.6. I use a bt mouse and OEM bt keydock (Asus T100-CHI) Starting with 4.4 thru 4.6-rc1-next*, I have to open blueman's device manager to search for devices after idle timeouts. I also need to leave the device manager dialogue open/minimized to prevent rapid loss of connection. Device pairing is remembered, but manually searching is difficult when the pointing devices stop working. My test setup has a usb mouse as a workaround. dmesg has "unknown main item tag 0x0" after each idle timeout". If I move mouse during boot, it will auto-connect, but it then suffers a rapid timeout soon after booting. See dmesg posted at #114561. It looks like something is incrementing the bluetooth input assignment # when anything times out.
Has anyone solved this yet?? I have the same issue with a bluetooth keyboard and kernel 4.14.
The issue was fixed for the Asus T100 (baytrail) 2-in-1 family. See this commit. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?id=c4c285da1ee18582ace366f07e56e355c20ebc49 which is in kernel 4.15. You could try adding the quirk for your device. (No kernel maintainer has acknowledged this bug report.)
It's not clear from the description what is the problem exactly? I have similar symptoms with "unknown main item tag 0x0" message after timeout. But my problem is that bluetooth keyboard disconnects on timeout (which is normal), but then, on the first key press it's just loss, while the keyboard reconnects successfully. It doesn't occurs on the same system with Windows 10 - the key doesn't lost on reconnect. I wonder if it can be the same problem.
I have the same issues with my bluetooth keybloard on 5.9.2-1.g4133ad1-default (Tumbleweed). hid-generic 0005:04CA:006C.0009: unknown main item tag 0x0 Very annoying.
Bug still present in 5.10.4-1-default
The bug is still here in 5.12.13 with asaus m-rbb93 logitech b370 mouse. After some time (unpredictable, can be few hours or few minutes) mouse pointer stops responding, though mouse appears conneceted in the bluetoothctl. > bluetoothctl Agent registered [Bluetooth Travel Mouse]# info Device 00:07:61:68:D2:9E (public) Name: Bluetooth Travel Mouse Alias: Bluetooth Travel Mouse Class: 0x00002580 Icon: input-mouse Paired: yes Trusted: yes Blocked: no Connected: yes WakeAllowed: yes LegacyPairing: no UUID: Human Interface Device... (00001124-0000-1000-8000-00805f9b34fb) UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb) Modalias: usb:v046DpB002d4809 journalctl and dmesg is silent when the mouse stops responding. Is there any other way to debug this? When mouse is first connected, dmesg has the message mentioned as the topic of this bug: [185307.429898] hid-generic 0005:046D:B002.002C: input,hidraw1: BLUETOOTH HID v48.09 Mouse [Bluetooth Travel Mouse] on dc:e9:94:7e:5f:86 [187430.340610] hid-generic 0005:046D:B002.002D: unknown main item tag 0x0 [187430.340668] input: Bluetooth Travel Mouse as /devices/pci0000:00/0000:00:08.1/0000:05:00.4/usb3/3-3/3-3:1.0/bluetooth/hci0/hci0:1/0005:046D:B002.002D/input/input104 (In reply to jbMacAZ from comment #5) > The issue was fixed for the Asus T100 (baytrail) 2-in-1 family. See this > commit. > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/ > commit/?id=c4c285da1ee18582ace366f07e56e355c20ebc49 which is in kernel 4.15. Is there a way to enable this system-wide without patching a kernel, for a quick test? I tried to add btusb.enable_autosuspend=n kernel paremeter: # cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-5.12.13-1-default root=UUID=ece1a448-6944-4f34-a61c-1742fde2ac3c splash=silent psi=1 nvidia-drm.modeset=1 btusb.enable_autosuspend=n quiet mitigations=auto # systool -v -m btusb Module = "btusb" Attributes: coresize = "69632" initsize = "0" initstate = "live" refcnt = "0" srcversion = "8EADE2557C147180496F74C" taint = "" uevent = <store method only> version = "0.8" Parameters: disable_scofix = "N" enable_autosuspend = "N" force_scofix = "N" reset = "Y" But this does not resolve the bug
"unknown main tag item 0x0" comes from the HID layer, it has nothing to do with Bluetooth or connection stability. It's usually a stray NUL character at the end of the HID descriptor which the kernel safely ignores but still logs. In my own driver development (xpadneo), I just shorten the HID descriptor by one byte if it ends with NUL because the devices I work with are known to NUL-terminate their HID descriptors. Maybe the kernel should do the same: If the last HID descriptor byte is a NUL-byte, it should simply shorten the HID descriptor by one byte, essentially cutting the offending byte off, and the message would be gone. Other than a log message, it has no consequences in the kernel, it comes from a completely different layer that's not related to Bluetooth at all.
Happens here with an Apple Magic Mouse A1296: kernel: magicmouse 0005:05AC:030D.000D: unknown main item tag 0x0 kernel: input: Maus as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/bluetooth/hci0/hci0:512/0005:05AC:030D.000D/input/input34 kernel: magicmouse 0005:05AC:030D.000D: input,hidraw4: BLUETOOTH HID v3.06 Mouse [Maus] on e4:70:b8:3f:cc:93 $ hwinfo --bluetooth 09: USB 00.0: 11500 Bluetooth Device [Created at usb.122] Unique ID: X7GA.GS0ueMFUyi1 Parent ID: k4bc.2DFUsyrieMD SysFS ID: /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0 SysFS BusID: 1-7:1.0 Hardware Class: bluetooth Model: "Intel Bluetooth wireless interface" Hotplug: USB Vendor: usb 0x8087 "Intel Corp." Device: usb 0x0a2b "Bluetooth wireless interface" Revision: "0.10" Driver: "btusb" Driver Modules: "btusb" Speed: 12 Mbps Module Alias: "usb:v8087p0A2Bd0010dcE0dsc01dp01icE0isc01ip01in00" Driver Info #0: Driver Status: btusb is active Driver Activation Cmd: "modprobe btusb" Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #14 (Hub)