At some point we had a filesystem showing Google Search results as query results in Tracker search dialog, so I’m not worried about the flexibility of our filesystem interface. And if it’s not flexible enough we can always extend it.
Yes, there are or at least were some known issues with the libusb port to Haiku. You may have to dig into the libusb code and make some improvements there.
Good to hear. I’ll develop some ideas on this when the basic stuff works. Most problems would be tied to being designed to be a 1 device to 1 device protocol, so all would have to wait and be locked while you do file transfers and so.
Already in the works, stopped because other reasons and the normal season celebration(s), but yes, i have my customized libusb version from haikuports to fix the problems. Solving that bugs would be a benefict for all, not only this “project”.
I’m pretty sure i can replicate the “unexpected” behavior in a small helloworld sample, so it’s just matter of time and send changes to the upstream code.
After digging and tweaking all the libusb code until I understand what happens under the hood, seems like there’s one background thread in Haiku libusb code that hangs, and i cannot solve it.
From [Libusb github], line 85:
if (ioctl(fRawFD, B_USB_RAW_COMMAND_CONTROL_TRANSFER, &command, sizeof(command)) ||
So this thread get stuck in limbo whenever i access a VMware usb device/hub from Haiku libusb (works ok with real devices & haiku usb devices).
Since i wont probably ever need VmWare hardware to do this, i can use the vmware vendor ID and skip those, but i dont know if this kind of libusb behavior has side effects for future uses (other than mines).
Btw, native usb kit seem to work on getting this info OK, when i call “listusb” with verbose output 
Any ideas?
Hi,
I wonder how you end up running that code on a vmware device. My understanding is that you would first check to identify if the device is indeed MTP compliant (checking device and/or interface class, or at worse, device and vendor ID), and only then start communicating with the device.
However, there should be a timeout for this if the device does not reply. The native USB kit is not doing things much differently, but it seems the subtle details matter. One could compare libusb and native USBkit by running similar test programs through strace, to see what is different in the called ioctls.
Haiku run in a vmware machine, has exported (At least) 2 virtual devices for hubs. I run the same example that’s provided in libusb examples that dumps a list for all the usb devices present in the system, like haiku listusb -v , and it freezes.
That would be the case, but manufactures dont comply to the interface (usb) class. Huawei phone doesnt for example, stating propietary vendor class (0xFF) where it should be… image (0x06) IIRC.
Note that the libusb example doesnt communicate with the device, apart of sending control transfer requests (ioctl in this case).
There is, in the libusb code, on each synchronous operation. For information requests in control transfers is 1000ms. It is the case of the “bug” on the ioctl that i mentioned, which is called when the timeout happens to handle it, pop from the usb transfer from a queue and so on. But as the background thread hangs, the notification to libusb doesnt happen. I suspect there is some unknown behavior on the vmware machine part, which could be checked against libvirt/qemu or virtualbox.
Guess that’s the only complete option to solve it, thanks for the tips and rethinking.
On my part, I did what i mentioned, ignoring vmware vendor devices, and all was ok, even with “stock” libusb from haikudepot 
I think listusb will not use raw control transfers, but higher level ioctls, letting the kernel side parts do more of the work. At least getting all descriptors should be possible this way, and I don’t think listusb needs to do any more than that.
I had freezes happen also with other devices, so we are likely doing something out of spec and not handling the problems correctly. The ioctl shound not hang this way, it should timeout eventually, at least.
Oh yeah, my bad. I meant usb transfer of Control type (as in control, bulk/interrupt, isochron.). The library is indeed able to get all the descriptors (hence why I can filter out some vendor by VendorID), and the usb endpoints from there.
With the endpoints you can operate ok. I think i found some “corner cases” like reading from a device endpoint without data available, which has the same behaviour, transfer not being handled ok after cancelling by the timeout.
We’ll figure out with new uses of the lib(s).
Improved the alpha a little:
Added a params lib +usage, plus scan feature:
Added file listing as in ls command:
File download by specifying full path to file (veeeeery time consuming if your folder has a lot of files, like Whatsapp, cause mtp has to poll each file to fetch the name):
File download by handle/object ID, which works much faster because it’s like having a direct access to a file pointer:
No file upload yet 
, still in the works.
Still working with my device & hardcoded values, until I find a way to configure another device easily from the scan values and/or probe devices to ease the process.
Need to polish this a little with other of my devices before involving the iPhones :P.
I created a ticket for the USB stall/freeze: https://dev.haiku-os.org/ticket/14835#ticket
Can you confirm you get the same or a similar error in the syslog when it happens?
Not the same output (that error text / code) iirc, but the same behavior. Frozen status after a cancelled transfer (by timeout).
The libusb debug says that the transfer was cancelled, yet you end in a libusb loop with 60sec timeout.
Gonna redo when nearby my Haiku VM host machine to doublecheck the syslog output.
I finally took the decision of going ahead with the tool, and put some effort on “cleaning the code” before going public .
Here it is, with a core codebase that I operate from a main file. With some tweaks it might be exported as a shared object lib and be called from non-gui apps, or python code.
There’s no upload feature yet, cause of the refactorization 
Any comment/suggestion and testing results is really appreciated.
It contains a Makefile file, so running make is enough to get the lib working, asuming you have the Haiku packages: libusb , libusb_devel. Tested ok on 64bits Beta.
To solve the not-everyhone-has-my-huawei problem, I made the code read the values from a simple ini format file, which for Haiku should work in one of this folders:
./mumtp.ini
/boot/home/config/settings/mumtp/mumtp.ini
The binary has an argument that creates a dummy file for you in the current dir, so you dont need to look any further for a sample file.
To know the values, simply run a scan procedure:
./mumtp --scan
./mumtp --createconf
<<Fill your values>>
To download files and show every file on your device , you need to set “Transfer files” as the USB mode when plugged on a PC. If you pick “Transfer images”, you may get it working, but the available files would be less (image folders only)
I have no iPhone devices at hand to test, but reading on the internet, i saw that to let any program to sync to the device you need to allow the PC you have your device plugged to, using a setting called “Trust this computer”. Further info on this topic after testing the library is much appreciated.
Didnt work when tested on a real iphone. Work needs to be done.
Official apple support info link
Replying to myself to say that this doesnt work (yet) on Iphones.
Got a chance to temporary have an used Iphone 4, so i was able to plug it into a Linux pc and enabled the “Trust this computer” option, without success (storage syncing was not ok / refused on the protocol side).
Good news is that I can use the device to test myself, apart from the android ones.
Hi Pahefu
I’m surprised there’s not been more interest in this which kinda tells me that most people are still running Haiku in a VM and so likely don’t need something like this.
I’m keen to see if I can get this to work but its not building for me under the latest nightly
g++ -c ".//fileWriter.cpp" -g -O0 -std=c++11 -Wall -o ./Debug/fileWriter.cpp.o -I. -I.
.//fileWriter.cpp: In member function 'bool FileWriter::OpenFile(const char*, int, const char*)':
.//fileWriter.cpp:27:31: error: ordered comparison of pointer with integer zero ('FILE*' and 'int')
27 | fileOpen = (fd>0);
| ~~^~
Makefile:144: recipe for target 'Debug/fileWriter.cpp.o' failed
make: *** [Debug/fileWriter.cpp.o] Error 1
Thanks for working on this!
You can do the following change in fileWriter.cpp:27:
- fileOpen = (fd>0);
+ fileOpen = (fd!=0);
thanks for posting the fix.
i was going to write it, but have no pc around and very busy too.
Thanks for that single op fix Diver! Indeed, with that one change mumtp builds and I have got its ls command working.
The phone I’m testing with has an SD card slot too which usually gets mounted alongside its internal memory. Does mumtp support mounting MicroSD cards over MTP yet? Would it be hard to add?
Your notes say that uploading files isn’t current supported? Could you please give an example command for copying a file from the phone onto the local disk please?
It would also be good to see the GH Readme updated with the instructions when you find the time.
Thanks Pahefu have a great Christmas!
not sure on sdcard support. it’s more like what the android os shows through mtp tham what you could achieve.
file upload was out of the scope back in the day and the code remained like that since Feb 2019, since i didnt code more for it or Haiku in general.
download to your pc by path or mtp handle it’s shown and explained above on the parrot image post
probably better than my present self could explain.
I reverted my install to an updated b3 (ie latest stable) Haiku install today. mumtp builds fine after applying the patch but I get a KDL if I try to run a mumtp --ls command.
It looks like I’ll have to return to running the nightlies to try the mumtp get command.
I updated my Haiku back to the latest master/nightly packages which got mumtps ls command working again but I haven’t had any luck in copying a file using:
./mumtp --get=/path/to/file.ext
When I try that I get:
[Error] Failed to download file by name: ‘/path/to/file.ext’ . Error code: 12
/path/to/file.ext is a file known to exist on the device by using --ls=
I have tried photograbber which claims to support PTP but it crashes for me under nightly and b3.
EDIT
Turns out I don’t need mumtp. There is a working Haiku GUI app for MTP called android_file_transfer.