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/
On 15.07.2015 10:52, [email protected] wrote:
> Oddly (or perhaps not) these 'funny' packets show up more frequently if I
> exercise the LEDs
> --
> root@blind-fury:/sys/class/leds/0005:054C:0268.0002::sony1#
> echo heartbeat > trigger
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 reference this is seen with Bluez git, kernel 4.1rc7 on Xubuntu 15.04.
> I am unable to use 4.2 as there's another bug affecting me.
> I did not see this on 3.19 (stock kernel for system), but will recheck later.
> Simon
For me it was no less than entirety of bluez5 and kernel 3.x series, if
I recall.
On 15.07.2015 10:29, Bastien Nocera wrote:
> On Wed, 2015-07-15 at 01:38 +0500, Sergey Kondakov wrote:
> ...
>
> 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?
Which illustrates my point exactly.
> Whatever contributions you might have made in the past, or will in the
> future, insulting people's work will only get you so far.
>
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.
On Wed, 2015-07-15 at 01:38 +0500, Sergey Kondakov wrote:
>
<snip>
> On 14.07.2015 16:32, Bastien Nocera wrote:
> > ...
> > Did you re-read your original mail? Are you genuinely still
> > wondering
> > why you didn't receive an answer?
>
> I'm not your psychologist, girlfriend or a telepath for figuring out
> what magic words are to your liking.
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 gave pretty detailed description
> with all the tech info available.
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 you still managed to miss twice,
Which I didn't read, maybe?
> 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.
>
Whatever contributions you might have made in the past, or will in the
future, insulting people's work will only get you so far.
On 14.07.2015 21:54, [email protected] wrote:
>
> 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?
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.
> 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).
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.
>
> The multi-touch/many-axis stuff is a pain, but the linux-input list is the
> place to discuss that...
> Simon
Yeah, probably. I thought maybe BT stack has some special input handling
for BT input devices.
On 14.07.2015 16:32, Bastien Nocera wrote:
> ...
> Did you re-read your original mail? Are you genuinely still wondering
> why you didn't receive an answer?
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.
>> Details are in
>> http://article.gmane.org/gmane.linux.bluez.kernel/62305
> 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
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).
>> Also, this kernel patch or a better alternative still hasn't been
>> applied and that's no good:
>> https://patchwork.kernel.org/patch/1075972/
The multi-touch/many-axis stuff is a pain, but the linux-input list is the
place to discuss that...
Simon
On Tue, 2015-07-14 at 12:28 +0500, Sergey Kondakov wrote:
> 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.
Did you re-read your original mail? Are you genuinely still wondering
why you didn't receive an answer?
> 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/
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.