Media Transfer Protocol MTP (SOLVED)

[01micko]

@01Micko: Did you test from Slacko64 or Slacko?

Both

Another question for anyone

• Has this advanced far enough along to be a PET?

Thanks in advance

Not yet.

[gcmartin]

Questions for @01Micko

• Is your MTP generalized for any MTP device?
  ---->OR<----
• Would it help if everyone who has a MTP device forward their IDs somewhere so that mounting could occur by deviceID?
• Wondering too, what would happen at mount times when you mount, say, both of your wife's devices (namely the Note and the Tab), simultaneously?

I can't help as I have a NOTE as well. But rest of the community can forward deviceID, I'm sure.

[gcmartin]

Wondering
Would this addition mount older cell phones, say, Motorola RaZr, etc?

If so, this would eliminate the need for specialize Windows programs to transfer information.

Hummm???

[01micko]

Should be able to auto generate specific rules for a device as it is plugged. So no need of stats.

It should work with most mtp based phones I guess, I don't know if its android specific. Maybe not.

Many older phones mount as mass storage anyway. Before I had GingerBread on the old sammy and it just appeared on the desktop as a usb device. Mounted easily.

[smokey01]

Thanks for this.

It works great on Slacko64.

I tried it in FatDog-611, not so good although it did work. A rule had to be created each time. It did not automatically detect the device. It didn't identify my Samsung Galaxy S4 but allowed me to transfer, play and view files nevertheless.

A much needed piece of software.

[Ted Dog]

smokey could you host this for whatever reason cant download this from Ts host.

[smokey01]

Have you tried right clicking and save file as.

Here they are: http://www.smokey01.com/software/system

[gcmartin]

This would be interesting to see if an iPhone or iPad would mount in any distro which uses this protocol.
Anyone have an iPhone they are willing to attach to a PUP?

[Billtoo]

Thanks for this.

It works great on Slacko64.

I tried it in FatDog-611, not so good although it did work. A rule had to be created each time. It did not automatically detect the device. It didn't identify my Samsung Galaxy S4 but allowed me to transfer, play and view files nevertheless.

A much needed piece of software.

I tried the pets in Slacko64 and they work with my nexus 7.

[01micko]

Ok

Many thanks to can8v for alpha testing, helping build the program really, and bringing this to our attention.

Here is revamped testing (usual warnings) version, prettied up the gui and tried to make it "smarter" [ ].

Known issues

• doesn't work right in FatDog64
  works in carolina but takes 20 - 30 seconds for device to become available, it's a kernel thing I think
  pupcamera may pop up or even break. I have a work around in there to combat that but the udev rule for that needs fixing
  not tested, but likely will NOT work in wary, might work in racy, even quirky
  probably other bugs

The program groks dmesg for your device info and translates that to a udev rule for automount. A unique rule is needed for each device.. I hope I've taken the pain out of that. Some samsung devices use identical rules. Possibly the same with HTC, Sony etc. Doesn't work with iFone (different protocol), don't know about Windose Phone. There is a status icon for unmounting, not required but highly recommended. Make sure you get the right version!!! i486 for all normal pups and x86_64 for slacko64 and LHP. May even work in other OS if gtkdialog is installed.

Also .. get go-mtpfs from tempestuous' post . Again.. get the right architecture!

Sources for the status icon are attached too.

Have fun!

EDIT: New main package from here

[can8v]

@01mick0
I grabbed a HTC EVO 4G 3D running 4.0.3. The program detected it and describes it as an "HTC Android_Phone", but the id number is blank and when the udev rule is created the number is blank their as well, so then autodetection did not work. I used lsusb to get the id for this phone, then manually added the vendor id and product id to the udev rule after that auto detection works. Just an FYI not sure if you had come across any devices that you were unable to detect the vendor id or product id for. I have tested four other devices (outside of the one I did our initial test with) successfully.

[01micko]

I will need dmesg output from devices which expose bugs in the program.
Right after plugging the device run:

Code: Select all

dmesg | tail -n6

[tempestuous]

Would it help if everyone who has a MTP device forward their IDs somewhere so that mounting could occur by deviceID?

Should be able to auto generate specific rules for a device as it is plugged. So no need of stats.
...
The program groks dmesg for your device info and translates that to a udev rule for automount. A unique rule is needed for each device.

As I mentioned earlier, gnomad2 has a udev rule (69-libmtp.rules) which contains a comprehensive list of MTP devices -
http://www.murga-linux.com/puppy/viewto ... 645#752645
Would it help to use this instead of trying to auto-generate a udev rule? The auto-generation process, as I understand it, is somewhat flawed because it seems to assume that whatever device the user plugs in is actually MTP-compatible? At least with a predefined set of device ID's, MTP-compatibility is absolute.

Note that the Note and the Tab mount under the same rule ...
... you can see the same device ID but different serial number for Note and Tab

Yes, as I reported in the gnomad2 forum thread, Samsung product ID 0x6860 is a generic identifier for smart-devices in "MTP" mode.

Note that the Note and the Tab mount under the same rule.. sadly pupcamera pops up with those too

This depends on how the device reports itself to the operating system, as found in -
/sys/class/usb_device/*/device/*/bInterfaceClass
The udev rule which responds to this is /etc/udev/rules.d/88-puppy-autodetect.rules
Something worth considering is that anyone who consciously installs go-mtpfs would probably want to disable Pcamera's auto-launch. So it would be easy to have my dotpet, or your dotpet, delete or shift 88-puppy-autodetect.rules, thus disabling it.

This would be interesting to see if an iPhone or iPad would mount in any distro which uses this protocol.

Sorry, but I laughed when I read this - MTP is Microsoft's proprietary protocol. There's no way Apple would use it!
iPod/iPhone/iPad use their own complex communication protocol, for which I provided gtkpod & associated libraries -
http://www.murga-linux.com/puppy/viewtopic.php?t=59183
Unfortunately at this present time these latest i-devices are unsupported - gen5 iPhone, gen4 iPod Touch, gen3 iPad, gen6 Nano.


I see that people here seem to prefer the convention of using /mnt/MTPdevice instead of my original suggestion of /root/MTP
so I have repackaged my dotpets with this directory, and uploaded them to a different location -
http://www.smokey01.com/tempestuous/go- ... 130628.pet
http://www.smokey01.com/tempestuous/go- ... -64bit.pet
I have also updated my earlier instructions to include the /mnt/MTPdevice mountpoint.

[Ted Dog]

Have you tried right clicking and save file as.

Here they are: http://www.smokey01.com/software/system

do not have save as option on android firefox.

[Ted Dog]

cool works on fatdog64 with multiple do you want mount popups.. Can live with that... for now. Can ditch the need for windows finally when it comes to this phone.

[01micko]

Should be able to auto generate specific rules for a device as it is plugged. So no need of stats.
...
The program groks dmesg for your device info and translates that to a udev rule for automount. A unique rule is needed for each device.

As I mentioned earlier, gnomad2 has a udev rule (69-libmtp.rules) which contains a comprehensive list of MTP devices -
http://www.murga-linux.com/puppy/viewto ... 645#752645
Would it help to use this instead of trying to auto-generate a udev rule?

As we all know Puppy is cut down, not that the file is overkill, its only 99k, and will probably be smaller once I figure out an algorithm to "puppyfy" .. that is, replace everything after the vendor and device ids with stuff puppy understands, I wont be doing that manually to 1000+ lines.

The auto-generation process, as I understand it, is somewhat flawed because it seems to assume that whatever device the user plugs in is actually MTP-compatible? At least with a predefined set of device ID's, MTP-compatibility is absolute.

Well it does rely on some user knowledge of their device, either they know its MTP or android. I have designed the program to be very maintainable so adding in support for a good set of udev rules is feasible and keeping the feature of being able to add your own makes it future proof.

Also, that file, after some study has revealed to me some possibilities to consider for adjustments to the 88-puppy-autodetect.rules (pupcamera bug) which generally accepts anything that has some sort of filesystem as a camera!

[tempestuous]

that file, after some study has revealed to me some possibilities to consider for adjustments to the 88-puppy-autodetect.rules (pupcamera bug) which generally accepts anything that has some sort of filesystem as a camera!

Well that's a positive thing, and it seems you understand the PupCamera stuff better than I, but let me point out (if you don't know it already) that udev rule is looking for an InterfaceClass value of "6" or an InterfaceSubClass value of "1".
When I plug in my Huawei Android phone, PupCamera does not auto-launch. So out of interest I looked at the InterfaceClass value - it's "08" and my InterfaceSubClass value is "06".

[Moose On The Loose]

When I plug in my Huawei Android phone, PupCamera does not auto-launch. So out of interest I looked at the InterfaceClass value - it's "08" and my InterfaceSubClass value is "06".

Since the method of interfacing cameras is discussed here, I will pop in to explain what I was thinking about in that area.

From the user's point of view, a camera is a thing that has some files on it. In this case, they just happen to be photos. When the camera is plugged in, the situation should be the same as for when a USB memory stick is plugged in. An icon should appear on the desktop and an device should appear in pmount.

Windows users often unplug and then replug a device to get the popup dialog to reappear. I think this is a model that should not be followed. It is always met with an "oh yeah I have to ... sigh" sort of feeling.

I have found that with the new users I have introduced to puppy, going to the menu to do something seems to be about at the limit of what they are willing to do before they say "I give up" and just assume Linux can't do that. The icon for the memory stick seems to be met with a bit of surprise and something along the "that's easy" to the "that's great" scale. I have seen more than one person be annoyed at the popup for a memory stick on Windows. The OS demanding it be told "right now" what you want done with something instead of doing what it is told seems to be the root of this reaction. At first I thought that perhaps it was related to the fact that unexpected popup windows on a Microsoft machine often are tails of disaster, but this seems not to be the case. It is annoyance and not fear that is at work.

Some folks who use Win-8 have the annoyance factor rise to the point where there is an element of fear. Win-8 does something that interrupts the flow of the user to the point of fear. It has the concept of the "mouse gesture" that causes a popup. The example user was editing a document and got almost to the point of abandoning it because when he was moving the mouse, he made "gestures". This is an extreme form of the popup demanding that the user do what the OS demands of him/her but it is only different in scale and not in type.

[can8v]

I see that people here seem to prefer the convention of using /mnt/MTPdevice instead of my original suggestion of /root/MTP
so I have repackaged my dotpets with this directory, and uploaded them to a different location -
www.smokey01.com/tempestuous/go-mtpfs-20130628.pet
http://www.smokey01.com/tempestuous/go- ... -64bit.pet
I have also updated my earlier instructions to include the /mnt/MTPdevice mountpoint.

@Tempestuous
I simply deleted the /root/MTP directory and used /mnt/MTPdevice, as I thought it might be a little more intuitive to mount my device in the /mnt directory where all the other devices (ie. HDDs, CDs, DVDs, memory cards, Flash drives, etc) are mounted. Ultimately though, I don't really care for /mnt/MTPdevice either I think a device specific named mount directory is approapriate, ie. /mnt/Nexus7 or /mnt/SamsungGalaxy. In Lubuntu I got a very friendly /media/(Nexus 7). Yes with a space. Still I would like to see that, less the space. I am working on that later today. My personal preference is to not have the go-mtpfs package create a mount directory at all. I think however, it is a very small issue and you should do what you like. My preference is just that a preference. I say it is your package, so your preference should be what matters.

[01micko]

From the user's point of view, a camera is a thing that has some files on it. In this case, they just happen to be photos. When the camera is plugged in, the situation should be the same as for when a USB memory stick is plugged in. An icon should appear on the desktop and an device should appear in pmount.

Interesting. Since neither cameras nor mtp devices are mounted as block devices its probably a bit out of the scope of pmount. I like the desktop icon idea.

There lies a problem though. With rox its easy enough to make a roxapp and plant that on the desktop near the drive icons (for mtp or camera) however this doesn't address other DE's which are becoming very popular in puplets (lxpup, carolina etc). I am a fan of .desktop files which rox can handle as well but not in the same manner or as simply as pcmanfm or thunar and friends. The reason I digress is that rox development has been stalled for a number of years and soon enough it probably wont even work so in woof we plan to support other FMs/DEs.

------------------------------------------------------------------------------------------------------------

I adjusted the 69-libmtp.rules supplied by tempestuous with a simple sed operation

Code: Select all

sed -i 's|SYMLINK.*|ACTION=="add"\, RUN\+="\/usr\/sbin\/pupautodetect android\-device"|g' ./69-libmtp.rules

I deleted my android rules file, inserted 69-libmtp.rules and reloaded the udev rules and all 4 of my test devices worked. I'm going to try a hack with the 88-puppy-autodetect.rules which should exclude everything in 69-libmtp.rules and iOS devices. I do have one to test.

------------------------------------------------------------------------------------------------------------

EDIT:

No go with the 88-puppy-autodetect.rules, its too general and to rewrite with all available cameras would be a nightmare.

Well that's a positive thing, and it seems you understand the PupCamera stuff better than I, but let me point out (if you don't know it already) that udev rule is looking for an InterfaceClass value of "6" or an InterfaceSubClass value of "1".
When I plug in my Huawei Android phone, PupCamera does not auto-launch. So out of interest I looked at the InterfaceClass value - it's "08" and my InterfaceSubClass value is "06".

Yes. Unfortunately a lot of Samsung devices have the InterfaceClass value of "6" and InterfaceSubClass of "1".

Code: Select all

# lsusb -d 04e8:6860 -v | grep bInterface #Samsung Galaxy Tab 3
      bInterfaceNumber        0
      bInterfaceClass         6 Imaging ##################
      bInterfaceSubClass      1 Still Image Capture ##############
      bInterfaceProtocol      1 Picture Transfer Protocol (PIMA 15470) 
      bInterfaceNumber        0
      bInterfaceClass         6 Imaging
      bInterfaceSubClass      1 Still Image Capture
      bInterfaceProtocol      1 Picture Transfer Protocol (PIMA 15470)
      bInterfaceCount         2
      bInterfaceNumber        1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      1 AT-commands (v.25ter)
      bInterfaceNumber        2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 

I don't want to cripple pupcamera, so as a work around, that should be fine, I can add this to the top of /usr/sbin/pupcamera :

Code: Select all

PIDOFMTP=`pidof mtpdevice`
[ "$PIDOFMTP" ] && exit # exits if mtpdevice process starts to tame udev rule 88-puppy-autodetect.rules