https://bugzilla.kernel.org/show_bug.cgi?id=60824 --- Comment #70 from Mikhail Novosyolov (m.novosyolov@xxxxxxxxxxxx) --- (In reply to Sergey Kondakov from comment #69) > It's detectable but the only device I tested it was Sony DualShock 4 which > acts as master that connects PC to itself which uses "sixaxis" hacks in > bluez. And, in the end, it was a failure: DS4 does not want to pass input > data and then promptly shuts itself off after "pairing". It does work under > Windows® with that dongle but on Linux I had to resort to old BT 2.1 one. Thanks for clearyfying. > The more important thing is "fixup" parameter patches that allow to at > select hacks per device and at least figure out what it needs without > recompiling and rebooting kernel every time. But, apparently, BT maintainer > is not interested in BT stack being as robust and easy to test as USB either. +1, it would be very good if users who do not know how to build kernels could easily participate in testing different hacks for hardware that they have. For example, I came to this bug because a user of the distro package of kernel which I am maintaining asked how he can build the kernel with that patch (https://forum.rosalinux.ru/viewtopic.php?t=10066) I had to read this bug and then just tell the user that I do not see sense in spending time to test this patch (include it into the package, build it, give him instructions how to install the build). Nobody benefits from the fact that an owner of hardware is not able to participate in hardware enablement in the kernel. On the other hand, opportunity to make such hacks in the kernel module config by the user may lead to that kernel will not have many needed hacks out of the box, users will just copy-paste device-specific solutions from the internet, then somebody will add them to e.g. systemd's hwdb. It is not good when some device-specific options are hard-coded in the driver and some are in other places like systemd's hwdb. -- You are receiving this mail because: You are the assignee for the bug.
