Hi Mike, please do not top post on this mailing list. > I could be wrong, but my understanding of that option is that it > simply pushes the joystick interpretation into userspace, allowing > BlueZ 5 to coexist wit other tools that manage the specifics of a > particular joystick or other device. > > This isn't what I want. I like that the sixaxis has first-class > support including auto-pairing, under modern BlueZ. But I want to > understand better what the intended disconnection behaviour is, and if > there's room to make it do something that would be a better fit for > the needs of those developing and using low-cost robotics. > > To be clear, most users using a Bluetooth gamepad are doing so from > the other side of the living room— they will never encounter the > proposed disconnection behaviours. But for users controlling mobile > robots, it would be helpful to have something a bit most rational than > simply repeating the most recent command. the UserspaceHID option means that the transport is done in userspace. The interpretation of HID packets is still done via the kernel HID subsystem. It is purely the transport that moved from kernel space into userspace. This means actually that userspace can keep the HID device / input device actively while it tries to re-connect the transport. Our current kernel implementation does not allow this since the transport and the HID device are bundled together. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
