Reaching out again for serious bug in sixaxis plugin

Since both my attempts, in kernel bugzilla and here, were ignored and you still don't have your own bugtracker I repeat my plea from previously with plugin's authors CCed in hope that bug's existence at least would be acknowledged.

Details are in http://article.gmane.org/gmane.linux.bluez.kernel/62305
Moreover, this livecd is almost identical to my running system which is based on it, so it may be used to reproduce the glitch (antimicro, jstest and evtest should help):
http://sourceforge.net/projects/hackeurs-sans-frontieres/files/0.8.1%20-%20The%20White%20Devil/Linux%20Live%20-%20HSF%20-%200.8.1_20150708.iso/download
If it could not be reproduce I'm afraid it may be a bug in handling my BT controller.

Also, this kernel patch or a better alternative still hasn't been applied and that's no good: https://patchwork.kernel.org/patch/1075972/

Did you re-read your original mail? Are you genuinely still wondering why you didn't receive an answer?

The device is connected correctly via Bluetooth. Then the bug is in the device's input driver, which you could probably also see when it's connected via USB. The right forum for this is the linux-input mailing -list.

As the original poster stated that this DOES NOT occur with a USB connection, it does kind of point to a Bluetooth problem (or maybe with device itself). Has anyone been able to replicate?

My suggestion would be to display/capture the hidraw interface and see if the missing data is present there. This can be done as root with --

$ hexdump -v -e '49/1 "%02x " "\n"' < /dev/hidraw0
--

The '49' is the byte count, and might be wrong (working from memory).

The multi-touch/many-axis stuff is a pain, but the linux-input list is the place to discuss that...
Simon

Indeed. And don't forget that it doesn't occur under Windows either. Or at least I wasn't able to detect such. The BT dongle used is of quite questionable quality and DS3 itself is quite old. But no direct signs of malfunction on their part. And if it's software issue someone should have stumbled upon it already. So it's quite mysterious.

Now that's the real answer !
I tried that and seen this one odd line in the middle about the time that stick axises have spiked with bogus values:
01 00 00 00 00 00 79 7f 7b 7f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 05 16 ff be 00 1b 33 af 77 01 c0 00 02 ea 01 90 01 e6 01 01 00 00 00 00 00 79 7f 7b 7f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 05 16 ff be 00 1b 33 af 77 01 c0 00 02 e9 01 90 01 e7 01 01 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 79 7f 7b 7f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 05 16 ff be 00 1b 33 af 77 01 c0 00 02 e9 01 8f 01 e7 01 01 00 00 00 00 00 79 7f 7b 7f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 05 16 ff be 00 1b 33 af 77 01 c0 00 02 ea 01 90 01 e6 01

No idea what that means.

Yeah, probably. I thought maybe BT stack has some special input handling for BT input devices.

I'm not your psychologist, girlfriend or a telepath for figuring out what magic words are to your liking. I gave pretty detailed description with all the tech info available. Which you still managed to miss twice, as was pointed above.
So seeing your behaviour I'm not wondering anymore but advising to read things at least once. Or get a bug tracker.

<snip>

For reference, you said:
"
It's unbelievable
how much bullshit one has to hoop over just to officially complain on it. No wonder that bluez userspace always has been one of most broken, unfinished, unreliable, un-userfriendly pieces of FOSS code ever. Or maybe it's all inherited from Bluetooth® mess of a standard and it's destined to suck.
"

I skipped over the "technically accurate, all information provided technical description" to the "who gives a crap what this guy says, I'm not going to help him anyway".

Which I didn't read, maybe?

Whatever contributions you might have made in the past, or will in the future, insulting people's work will only get you so far.

Tried that but with usb-host instead of heartbeat (which I don't have) and wiggling mouse (which triggers the led). At first it's gone crazy with 2-4 the frequency but when I tried to repeat it latter it was about the same as always... still pretty frequent, every 10-30 seconds. Sometimes 2 in short burst (1-5 seconds) with bigger pause.

For me it was no less than entirety of bluez5 and kernel 3.x series, if I recall.

Which illustrates my point exactly.

Ignoring glitches will diminish your work, hurt all users and make it look for everyone precisely in a way that I described.

Imagine what happened when distributions started to move (openSUSE at least) bluez4->bluez5 while it didn't have any GUI whatsoever and was still quite new... with no place to even properly complain (of course distributions would send you to upstream and do nothing themselves). "Wanna use some BT ? Better tech-up and go on a quest !" Some (again, openSUSE) even still disable sixaxis plugin in their packages. And properly rebuilding packages for binary distributions is a pain. "Wanna play some games ? Screw you !"
BT support in all OSes seem to be treated with afterthought. Windows even didn't have its own bluetooth stack until recently, I think. I applaud any efforts to do it properly for Linux but your own attitude don't exactly make it any easier either.

And BT standard itself is a mess that breaks OSI, you can't deny that. Actually, seeing how any serious wireless devices use a helper device (usually USB transponder with direct USB connection emulation) for transporting their data (gaming mouses, pro-headphones, "hdmi video transmitters") makes me think that if someone would come up with userspace drivers that would replace usual USB emulation methods for those and allow getting and sending data directly from user's wifi card in a secure, defined and standardized (preferably by IEEE) way then BT may go obsolete altogether. Such implementation may even be completely data link (or even network) neutral for compatibility with any underlying networking type.