USB backend

[Albert Vaca]

Either post a review board with the code [1] or push it to a github repo
and send the link.

[1] http://reviewboard.kde.org/

On Wed, Jul 29, 2015 at 12:44 PM, Floris Stoica-Marcu <floris.sm at gmail.com>
wrote:

> 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/59623400/attachment.html>