My ongoing experiences with my Linux laptop and this time, Bluetooth.

One of the observations I had written earlier, about the Linux laptop I name ‘Klystron’, illustrated in depth that it has issues with its Realtek chip-set, that provides it with both WiFi and Bluetooth connectivity, presumably providing both through the same physical antennae.

> BTW, have Linux developers ever discovered, that this chip is meant to have two antennae, which the laptop was built with, and that the drivers are supposed to switch back and forth, to whichever antenna was giving the best signal at any moment? I.e., that with the lid open, one antenna should be used, while with the lid closed, the second antenna should be used? I just thought I’d mention it as a segway… <

The Bluetooth functionality of this chip-set, on my Linux configuration, does not seem to work at all. And so something which I have done, which some people might find odd, is to buy a Bluetooth-dongle, to put that in a USB-port on the side, and then to pair my external mouse.

Actually, this has only worked on a second attempt, with a second BT dongle. I had given up on the first BT dongle, thinking that that dongle must somehow have been incompatible with the Bluetooth Stack in some way, failing consistently on both my Debian / Jessie / 8 systems. And I had erroneously come to that conclusion, even after the same, first dongle worked fine, on a Debian / Squeeze / 7 laptop.

The actual user-space software works fine, even telling me that the newer, better, $5 dongle detects the Realtek chip with its antenna only 20cm away (where it’s inside the attached laptop), and with my neighbor’s sound-bar detected upstairs from my flat… For another day.

I know that my ( “Logitech M557″ ) BT mouse works fine, because I can pair it easily with my tablet(s).

There is a bit of a trick, that will finally enable the Debian / Jessie laptop to pair with the same mouse. I need to use the GUI normally, to tell it to pair, while the mouse is in pairing mode, at which point the GUI shows activity for a few seconds, and the data-exchange-bars just seem to cease, and the mouse next stays in pairing mode, with its own blue LED still flashing rapidly, waiting to pair.

What seems to go wrong, is that after Linux has established a pairing, Linux fails to send a signal to the mouse, that it should switch from pairing-mode, to usage-mode, so that its LED extinguishes.

The way I found this out, was to wait after the data-exchange-bars in the Linux GUI vanish, where that mouse still has its Paired and Trusted icons, until the mouse ‘decides on its own’ to exit pairing mode, as if pairing has been unsuccessful – i.e. I waited for pairing-mode to time out on the mouse.

And then what followed, was that the mouse works, and that the GUI shows me that data is being exchanged steadily. After I have done this, the pairing is successful and apparently stable! :-D

What this also tells me, is that I could have kept using the old dongle… :-( But then again, the new dongle has USB 4, which the old one didn’t! :-)

Yay!

BTW, This is a kind of BT mouse, that does not require we pair using a PIN. The GUI has a separate button for that.

Dirk

 

Klystron, Kernel Update a Success

The laptop which I name ‘Klystron’, received a Kernel Update on July 7. This brought its kernel version to 4.4.0-30-generic as far as I can tell.

Prior to this update, one of the problems the laptop was still experiencing, was due to its Realtek WiFi chip-set, and the kernel module ‘RTL8723BE’. It had a malfunction in how it was connecting to my WiFi, which should have set in twice again, since July 7, according to earlier observations I had made. This bug had become quite predictable.

But since the latest kernel update, this malfunction has not been taking place anymore.

So I would say, that this kernel update was a huge, welcome success.

A separate question I have not yet answered, was whether its Suspend Behavior has also been corrected. This will be slightly more complicated for me to test, because as the above posting suggests, I had adapted a script, which seems to correct it. If the problem had been resolved in the kernel update, my script would simply not do anything. And the end result would remain, that the problem is not apparent.

In order to see whether the kernel update actually resolved that issue, I would first need to disable my script, and then try a few Suspend Cycles, since this problem was also not taking place with 100% consistency.

I have not yet committed myself to doing that.

Dirk

 

Klystron Kernel Update

My Linux laptop named ‘Klystron‘ is still fully subscribed to the “Kanotix” repositories. As the reader may recall, Kanotix is a slightly customized version of Debian Linux, that is KDE-based, and that is maintained by a group of developer-experts who I trust implicitly.

Being subscribed to their specific repositories and configuration details has as one advantage, that periodic kernel updates are fed to me, via package manager.

As I came home from camping yesterday, on July 7, I also rebooted this laptop, and saw that indeed, a kernel update was being offered, which I immediately installed. So that laptop now has kernel version ‘4.4.0-30-generic‘, or so my /boot directory would seem to say.

One problem that I was experiencing with that laptop since before camping, was some subtle WiFi issue which I could no longer pinpoint. I had written, that its ability to use the hardware encryption offered by the (kernel module ‘RTL8723BE’) chip-set seemed to work fine. But there were some other problems with the WiFi.

I would like to be able to report, when and if that issue has been resolved completely. But since Klystron has only been running on kernel version 4.4.0-30-generic for one day, it is still far too soon to call out a victory. I will continue to observe the behavior of that laptop for the next little while, and give further comment on it later. So far its behavior looks good.

Dirk

 

My WiFi connection has been stable, for 1 day and 13 hours.

On my newly set-up laptop ‘Klystron’ I had reported This Problem with the stability of the WiFi chip-set. Well since that posting, that laptop has been able to stay idle – and connected – for 1 day and 13 hours, without disconnecting. And, I have downloaded lengthy hundreds of megabytes – and sometimes gigabytes – of software packages, without any further interruptions.

Thus, even if there is still a problem with my Pidgin client sometimes disconnecting with a “Ping Timeout”, this problem should be external to the behavior of the WiFi kernel module now, and may even have something to do with policies from the IRC chat room, such as ‘No More Than 1 Nick Per User Logged On At Once’ ?

Dirk