USB backend

Wed Jul 29 19:44:13 UTC 2015

No, actually, I managed without! xD

I made a libusb hotplug thingy that scans every usb device and tries to
connect with it via the Android Accessory API. Every new device is also
handled once it is plugged in (or out). It works, but I ran into problems
integrating it into kdeconnect itself.

Where can I upload the UsbServer I made so we can discuss how to integrate
it? I tried to follow some guidelines regarding how providers and
devicelinks work. For now, this is all it does (I still need to write the
android part in java), it puts the phone into accessory mode :)

The transfers are capped for Android at 16384 unsigned chars, but will have
to write the Java part to test properly.
 Do you need to have a list of all Android vendor IDs for it to work? :S

On Mon, Jul 27, 2015 at 12:05 PM, Floris Stoica-Marcu <floris.sm at gmail.com>
wrote:

> Actually the pairinghandler works great since I use Libusb to pair them
> up. Any advice as to what is the best way to implement the vendor/product
> ids? So far I have only the list of vendor ids (bottom of page):
>
> http://developer.android.com/tools/device.html
>
> I also noticed that the phone has different product ids, depending on what
> usb mode it is set to.
>
> On 27 July 2015 at 20:15, Albert Vaca <albertvaka at gmail.com> wrote:
>
>> Cool!
>>
>> Note that we are refactoring some of the backends code, so we might need
>> to make some changes to what you are implementing before we can merge it.
>> Namely, we have split the pairing code into a "pairing handler" class, so
>> every backend can implement its own way to pair. It would be nice if you
>> could have a look at this branch with the changes [1] and see if they make
>> sense for you and for your new backend.
>>
>> https://github.com/grgvineet/kdeconnect-kde/tree/pairinghandler
>>
>>
>> On Mon, Jul 27, 2015 at 3:34 AM, Floris Stoica-Marcu <floris.sm at gmail.com
>> > wrote:
>>
>>> Yes, a socket implementation is more than possible. I looked over the
>>> current backends so it should function almost the same.
>>>
>>> You are right regarding the USB detection, it would be nice to get the
>>> connected android devices from Dolphin somehow. Currently for the testing I
>>> am doing I am providing the vendor id and pid manually. Weirdly enough the
>>> VendorID changes from time to time ... I have Samsung Galaxy S5 and
>>> sometimes the VID is 0x04e8, sometimes its 0x04E8.
>>>
>>> The good news is that the accesory API does not interfere with MTP, so
>>> you can have both at the same time.
>>>
>>> I'll get back with some sample code tomorrow!
>>>
>>> Floris.
>>>
>>>
>>> On 27 July 2015 at 03:47, Albert Vaca <albertvaka at gmail.com> wrote:
>>>
>>>> Users should not have debugging enabled on their phones, so the ADB
>>>> approach doesn't seem a good option. I have no idea about what you can do
>>>> with the Android accessories API, but it sounds better even if old phones
>>>> are not supported. Can you implement whatever protocol you like on top of
>>>> that API? Basically what we need is to open a socket between the PC and the
>>>> device. Do you think it can do that?
>>>>
>>>> And something related: right now when you connect your phone through
>>>> USB, we are not smart enough to know that the phone connected by USB and
>>>> the phone connected by KDE Connect are the same phone, and Dolphin displays
>>>> it twice. That is: you end up with two interfaces to send files, one that
>>>> works through MTP and another through KDE Connect. I think that's a bad
>>>> user experience and we should get to a point where we are able to show the
>>>> phone only once in Dolphin, and when the user wants to send a file we use
>>>> the better communication channel we have available (probably MTP). For me,
>>>> this would be the final goal for USB integration in KDE Connect :)
>>>>
>>>>
>>>>
>>>> On Sat, Jul 25, 2015 at 8:36 PM, Floris Stoica-Marcu <
>>>> floris.sm at gmail.com> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> So I've recently been experimenting with some USB connection methods
>>>>> for Android. I would like your opinion on what is best to implement for KDE
>>>>> Connect. I found two ways that could work, each with their own advantages
>>>>> and disadvantages:
>>>>>
>>>>> 1. An USB backend through adb ( would require the user to have it
>>>>> installed, but will work on most Android versions) [0]
>>>>> 2. An USB backend that takes advantage of the whole Android accessory
>>>>> API. Writing the PC stuff in libusb it is possible to essentially turn the
>>>>> whole computer into an Android accessory, that can transfer bytes and
>>>>> whatnot to and from the Android device. ( will work only on newer versions
>>>>> of Android, but the user will not have to install anything extra ) [1]
>>>>>
>>>>> Quick note on the method through adb, it also requires to have the
>>>>> device in usb-debugging mode. There is also the method of the custom usb
>>>>> driver, but I determined it to be far too fidgety (especially if you
>>>>> already have some drivers intalled).
>>>>>
>>>>> I will attach some resources on the topics:
>>>>> [0]
>>>>> http://qtcstation.com/2011/03/connecting-android-to-the-pc-over-usb/
>>>>> [1] http://source.android.com/accessories/custom.html
>>>>>
>>>>> What method would be the most convenient for KDE connect?
>>>>>
>>>>> Floris.
>>>>> --
>>>>> Stoica-Marcu "FlowRiser" Floris-Andrei
>>>>> floris.sm at gmail.com
>>>>>
>>>>> _______________________________________________
>>>>> KDEConnect mailing list
>>>>> KDEConnect at kde.org
>>>>> https://mail.kde.org/mailman/listinfo/kdeconnect
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Stoica-Marcu "FlowRiser" Floris-Andrei
>>> floris.sm at gmail.com
>>>
>>
>>
>
>
> --
> Stoica-Marcu "FlowRiser" Floris-Andrei
> floris.sm at gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20150729/04dedc19/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot_2015-07-29-22-35-15.png
Type: image/png
Size: 176659 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20150729/04dedc19/attachment-0001.png>