Review Request 122174: Add initial bluetooth backend implementation.
Saikrishna Arcot
saiarcot895 at gmail.com
Sun Mar 1 22:22:00 UTC 2015
> On March 1, 2015, 8:20 p.m., Albert Vaca Cintora wrote:
> > I'm writting this using the virtual keyboard on my phone, connected using bluetooth :)
> >
> > It took about 10 seconds for the device to appear in the device list in system settings (and I had to press refresh a couple times), but after that it works perfectly :D Reconnection works fine as well after restarting the computer, and I didn't have the problem with the pairing status not being saved that you say. Maybe this was a bug in the frameworks branch and it has been fixed already. (I have finally installed Plasma 5, so now I will be actively maintaining the frameworks branch and I hope we will catch all these bugs :)
> >
> > Some of the latest changes in the code required me to change a bit the code for your patch to compile. I have commited it with my changes to the branch "bluetooth" for both Android and KDE, so we can keep improving it from here.
> >
> > What needs to be implemented now? This is almost done! :D Payloads are missing, what else?
Thanks, Albert.
Regarding the pairing status, the configuration file was, for some reason, owned by root, so the changes were never saved. This has been fixed.
Browsing the filesystem doesn't work, as the plugin tries to open up a network port, but there might not be a direct connection through the wifi network. One possible solution might be to listen on that SSH port and transmit what is sent through the bluetooth channel and send it out through another port on the other side, but I don't know if that would be possible. If so, network connection sharing might also work. That being said, though, Dolphin seems to have an option to browse the remote filesystem over SSH, so this might not be a major issue.
Another change that might need to be made is to adjust the timeouts on the Android side. If we see that all paired devices are connected, then instead of sleeping for just 15 seconds, sleeping for 30 or even 60 seconds might be a better idea in terms of battery life. I don't see this being too much of a problem on the laptop/desktop side, as bluetooth activity is likely to represent a smaller percentage of battery use.
Finally, we might want to add some way to select what devices to attempt connecting to (for both KDE and Android). For example, if there is a bluetooth headset device also connected, then the current code will try connecting to that as well, which will cause unnecessary bluetooth traffic and might slow down the existing connection.
- Saikrishna
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122174/#review76838
-----------------------------------------------------------
On March 1, 2015, 8:18 p.m., Saikrishna Arcot wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122174/
> -----------------------------------------------------------
>
> (Updated March 1, 2015, 8:18 p.m.)
>
>
> Review request for kdeconnect.
>
>
> Repository: kdeconnect-kde
>
>
> Description
> -------
>
> Add initial bluetooth backend implementation.
>
> This is based on the frameworks branch.
>
> The `getPairedDevices()` method in the link provider class uses D-Bus to get the list of paired devices, since Qt doesn't have a method giving that information. As a result, that part of the code only works on Linux.
>
>
> Diffs
> -----
>
> CMakeLists.txt 5b916d929dfa3f3304a8ac84e7ef6c19f9aa4663
> core/CMakeLists.txt 17209b1a801b33d99e31a4b19eac45df2fa6fe02
> core/backends/bluetooth/CMakeLists.txt PRE-CREATION
> core/backends/bluetooth/bluetoothdevicelink.h PRE-CREATION
> core/backends/bluetooth/bluetoothdevicelink.cpp PRE-CREATION
> core/backends/bluetooth/bluetoothlinkprovider.h PRE-CREATION
> core/backends/bluetooth/bluetoothlinkprovider.cpp PRE-CREATION
> core/backends/devicelinereader.h PRE-CREATION
> core/backends/devicelinereader.cpp PRE-CREATION
> core/daemon.cpp 57548e5a671b7694125e733db06a58eebbadd264
>
> Diff: https://git.reviewboard.kde.org/r/122174/diff/
>
>
> Testing
> -------
>
> KDE Connect runs, and the bluetooth service gets published in the SDP (service discovery protocol), which other devices use to determine what services are available.
>
> For me, sending a pair request from KDE to Android results in KDE Connect crashing on Android. It seems it's because the VIBRATE permission is necessary, which I've added on the Android side. In addition, the pairing data doesn't seem to be stored on the KDE side. Not sure if I'm missing something or not.
>
> # Android as client and KDE as server
>
> ## BlueZ 4 and Qt 5.3
>
> My Android (4.1.2) sees the KDE connect service and tries to connect to it, but fails most of the time. Sometimes, it succeeds and creates a connection. I haven't been able to find out why it's failing the rest of the time. Newer versions of Android (4.2 and higher) might have better luck, since the Bluetooth code was changed.
>
> When it does connect, one time, I was able to pair the devices together (from my Android), and was able to send a ping, use the touchpad, and control my media player from my Android.
>
> ## BlueZ 4 and Qt 5.4
>
> Not tested.
>
> ## BlueZ 5 and Qt 5.4
>
> My Android sees and at least tries to connect to the KDE connect service. Sometimes, it's successful, sometimes, it fails.
>
> # Android as server and KDE as client (all versions)
>
> I was able to successfully connect to the Android and use it.
>
>
> Thanks,
>
> Saikrishna Arcot
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20150301/2e5b14ca/attachment.html>
More information about the KDEConnect
mailing list