Summary:
As mentioned on telegram, there are some fundamental issues with bluetooth. The only approach I could get working was multiplexing: manually sending multiple streams of data over a single connection.
This is the description of that multiplexing protocol. I have an implementation of this protocol, but I'd first like some feedback to see if this is what we're going to use before finishing up those patches.
See the document itself for more details. I make the protocol forward-compatible, although I don't expect we will need ever that.
Test Plan: None, this is just a description.
Reviewers: #kde_connect, andyholmes, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: albertvaka, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D17987
Summary:
When android closes the payload socket (cancel share) calling m_socket.close() results
in a recursive call to onError eventually leading to a segmentation violation
Test Plan:
Install D16491, share a large file from desktop to android and cancel the share on Android through
the notification. kdeconnectd crashes almost 100% of the time. (It doesn't crash when it detects
a disconnect in sendNextPacket)
Reviewers: #kde_connect, nicolasfella
Reviewed By: #kde_connect, nicolasfella
Subscribers: kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D17628
Summary: If the identity packet is split across two packets, then save it until we get a notification that more data is available for reading over the bluetooth link.
Test Plan: Connect a phone and laptop over Bluetooth, and verify that both the phone and laptop are able to see each other, and that either side can start and successfully go through the pairing process.
Reviewers: #kde_connect, mtijink
Reviewed By: #kde_connect, mtijink
Subscribers: mtijink, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D17789
Summary:
Combine multiple upload jobs for files into a single KCompositeJob so only 1 notification will be shown
Includes changes introduced in D16279
Test Plan:
1. Share of multiple files is performed using 1 composite job
Setup:
- Select multiple (big) files in dolphin and share with an Android device
Result:
- The files will be transferred using 1 CompositeUploadJob and showing only 1 notification
2. Share of file while another share is already running adds job to existing composite job
Setup:
- Select multiple (big) files in dolphin and share with an Android device
- Share an additional file with the same Android device
Result:
- The files are all transferred using 1 CompositeUploadJob and showing only 1 notification
- The notification is updated after adding the last file
3. Other packets are transmitted as usual
Setup:
- Setup sharing desktop notification with device
- Share a big file with an Android device
- Generate a desktop notification (eg. sending or receiving an email)
Result:
- Notification packet is send immediately
Reviewers: #kde_connect, nicolasfella, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: albertvaka, apol, nicolasfella, broulik, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D17081
Summary:
Show progress when sending a file from the desktop
BUG: 355044
Test Plan:
Complete transfer:
-Right click on a big file in dolphin
-Select Send to xx via KDE Connect
-Open the Notifications widget and verify progress is shown correctly
Stop transfer:
-Right click on a big file in dolphin
-Select Send to xx via KDE Connect
-Open The Notifications widget and press the stop/kill button
-Observe that the file upload is stopped
Reviewers: #kde_connect, nicolasfella
Reviewed By: #kde_connect, nicolasfella
Subscribers: apol, broulik, nicolasfella, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D16279
Summary:
No need to emit newConnection in Server::incomingConnection because QTcpServer will emit it after incomingConnection returns
QTcpServer also already has a list of pending connections so use that
Test Plan: Send a file from desktop to android and observe that newConnection is only called once
Reviewers: #kde_connect, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D17009
Summary: Why cast sender() to server when we have m_server
Reviewers: #kde_connect, apol
Reviewed By: #kde_connect, apol
Subscribers: kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D16760
Summary: If the number of bytes received != m_size report failure and delete the partial file
Reviewers: #kde_connect, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D16778
Summary: I am open to discussion for whether this is desireable. The use-case is for moving NetworkPacket receive handling to a thread other than the one handling the rest of the device. In order to do this, we need to use a QtConnectionType::QueuedConnection. In order for that to work (with NetworkPackets), NetworkPacket has to be registered in the Metatype system.
Test Plan: Nothing should be functionally different from before
Reviewers: #kde_connect, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: albertvaka, apol, nicolasfella, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D16469
Summary: This is not a hugely important change. I noticed it while I was working on something else, and it seems like it ought to be this way
Test Plan: Nothing should be noticeably different
Reviewers: #kde_connect, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: apol, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D16468
Summary:
Main change is to use libkeepalive to wake up the system to ensure connections stay alive
Other minor changes are:
-Log daemon messages for debugging purposes
-Add way to forece refresh of device list
-Minor spec improvements
The keepalive changes certainly seem to help, not sure if it completely solves the problems
The logging changes are temporary, and I could use them locally, but they only affect sailfish users
Im not sure if the refresh method is correct, but seems to force the daemon to check for devices
Reviewers: #kde_connect, nicolasfella, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D15414
Summary:
This fixes receiving payloads using the bluetooth backend.
This looks like some bug in Qt, but I couldn't figure out what happens exactly (will report a bug though).
Test Plan: Receiving files now works!
Reviewers: #kde_connect, apol
Reviewed By: #kde_connect, apol
Subscribers: kdeconnect, nicolasfella, apol, #kde_connect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D12153
