USB backend

Tue Jun 14 02:31:34 UTC 2016

Salut,

Vroiam sa te intreb de unde esti? Si unde studiezi?
Eu-s din Tg Mures si lucrez in Cluj.

O zi frumoasa,
Attila
On Jun 13, 2016 23:20, "Floris Stoica-Marcu" <floris.sm at gmail.com> wrote:

> Hello Albert,
>
> So nice to hear you are picking this up! Basically after you connect the
> two devices using the technique in my repo, it will just act like a very
> rudimentary socket that is able to write/read bytes in bulk using a
> FileStream (on the Android part). I do remember it was quite
> straightforward by using the Android guidelines for accessories to connect
> and to send/receive bytes [1].
>
> And I think what I got stuck upon was actually implementing it in the
> Android part of KdeConnect, since at that time you guys were in a
> restructuring of sorts (implementing SSL and stuff).
>
> I am currently finishing up my studies at Uni (one month to go!), so if
> you need any help after 10th of July I will be available :)
>
> [1] Android Accessory API:
> https://developer.android.com/guide/topics/connectivity/usb/accessory.html
>
> On 12 June 2016 at 14:37, Albert Vaca <albertvaka at gmail.com> wrote:
>
>> Picking this up again!
>>
>> I had a look again at both your code and the official Android Accessory
>> SDK. It seems that the Accessory SDK allows you to open a socket to talk
>> between the two ends. Your implementation using libusb is nice because we
>> don't need to depend on the Accessory SDK but doesn't provide that simple
>> socket abstraction. How can we communicate the two devices after connecting
>> them with your approach? I like the idea of using the USB cable when
>> possible to reach a device, and if we manage to abstract it to a simpe
>> socket it should be super easy to implement, but I don't see how to do it.
>>
>> Albert
>> On Jul 30, 2015 8:50 AM, "Floris Stoica-Marcu" <floris.sm at gmail.com>
>> wrote:
>>
>>> Awesome, so here is the link to the repo:
>>>
>>> https://github.com/SMFloris/qt-android-accessory
>>>
>>> Few mentions:
>>> 1. The device needs to be in some sort of transfer mode other than the
>>> install-mode (the one with the drivers for windows); MTP and USB 3.0 mode
>>> work fine
>>> 2. After putting the phone in accessory mode, it gets the vID-18d1
>>> (Google) and a *seemingly random* pID I am unsure what will happen if I
>>> connect 2 Samsung devices (one of them got drained), for example, because
>>> they might get the same pID after being in accessory mode. So our Device
>>> class should also include hardware addresses/ports together with original
>>> pIDs and vIDs
>>> 4. The code works for already connected devices as well!
>>> 5. I tested on the Galaxy S5, S2, an Allview P5 and a Serioux tablet;
>>> The two Galaxies had the exact same pID in their USB modes (6860 for MTP
>>> and USB 3.0). It should work with all Android devices with a supported API
>>> >= 10 (if we also use the support library, otherwise it is >= 12)
>>> 3. In order for the code to work, make sure you have at least
>>> libusb>=1.0.16
>>>
>>> On 29 July 2015 at 23:36, Albert Vaca <albertvaka at gmail.com> wrote:
>>>
>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Stoica-Marcu "FlowRiser" Floris-Andrei
>>> floris.sm at gmail.com
>>>
>>
>
>
> --
> Stoica-Marcu "FlowRiser" Floris-Andrei
> floris.sm at gmail.com
>
> _______________________________________________
> KDEConnect mailing list
> KDEConnect at kde.org
> https://mail.kde.org/mailman/listinfo/kdeconnect
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20160614/c5cdb77d/attachment-0001.html>