| |||||||||||||
NautilusNautilusPosted May 16, 2012 1:04 UTC (Wed) by corbet (editor, #1)In reply to: Tasting the Ice Cream Sandwich by khc Parent article: Tasting the Ice Cream Sandwich nautilus-3.5.1-1.fc18.x86_64. You need at least libmtp; you might also need newer udev rules for it to work right. My understanding is that libmtp has to hard-code every device it knows about, which seems like a rather sad situation; you may need a relatively recent version of that too for things to work.
(Log in to post comments)
Nautilus Posted May 16, 2012 11:12 UTC (Wed) by asn (subscriber, #62311) [Link]
CyanogenMod 9 still has the good old USB Mass Storage support. You need an overlay for it and define the lun0 file correctly and it will work as in gingerbread.
Nautilus Posted May 17, 2012 6:33 UTC (Thu) by AndreE (subscriber, #60148) [Link]
How does this work for the Galaxy Nexus? What file system is reported to the OS?
Nautilus Posted May 18, 2012 9:08 UTC (Fri) by jamesh (guest, #1159) [Link]
Presumably it would be a loopback FAT32 file system stored on the flash, which the phone would have to unmount when switching on mass storage mode.
While MTP might be a little more cumbersome to use, it does have the benefit that both the phone and your desktop can access the file system concurrently. That seems like reason enough to concentrate on making the MTP user experience as good as possible rather than trying to hack UMS support back in.
Nautilus Posted May 16, 2012 19:21 UTC (Wed) by linusw (subscriber, #40300) [Link]
Nope, it does not hardcode every device. Rather it nowadays does exactly what Windows does and ask the device if it happens to be MTP.
If you're using a recent libmtp packaged by some sane person, the udev script (Fedora: /lib/udev/rules.d/69-libmtp.rules) will probe unknown devices using "mtp-probe". If the outcome is positive it is tagged as a music player and MTP device, then other udev scripts elevates that to be accessed by the desktop user. libmtp will autodetect the default Android stack and assign bug avoidance flags to cope with it.
The problems are not so much with libmtp really. Userspace has to hog devices after detecting an MTP compliant device and use libmtp or libgphoto2 to talk to it, here somewhere the problems start, since the desktop programs are not designed to share MTP resources in a good way.
The biggest problem is probably that absolutely noone is working on a common approach to supporting a wide variety of MTP devices on Linux, end-to-end. We basically need the pulseaudio rewrite of the user-facing and desktop integration parts.
MTPFS Posted May 16, 2012 20:48 UTC (Wed) by nybble41 (subscriber, #55106) [Link]
My problems with mtpfs, which may have been addressed in the year or so since I switch to syncing my Xoom tablet over my WiFi network, were: (a) it would get very slow and use a lot of memory when transferring large numbers of files, e.g. my music collection; and (b) due to the media-centric nature of the protocol, files wouldn't always end up where I put them. Copy a music file into a specific directory, look at the directory--it's empty. Instead, the file shows up classified by its tags under a different directory entirely.
I fixed the second issue for myself by editing mtpfs and simply stripping out all the media type detection code, so that everything was treated as a normal file. That's probably not a general solution, though.
MTPFS Posted May 17, 2012 19:34 UTC (Thu) by linusw (subscriber, #40300) [Link]
The problem here is basically that Android took MTP, which was intended for transferring media files, and made it a generic file transfer protocol. It's sort of trying to hit a nail with a screwdriver.
What USB needs is a real transactional file transfer class, think of FTP over USB.
MTP was convenient to used because the Windows Explorer used it natively, but has created a problem for Mac and Linux users, since these OS:es aren't natively designed for MTP.
MTPFS Posted May 17, 2012 20:09 UTC (Thu) by nybble41 (subscriber, #55106) [Link]
> What USB needs is a real transactional file transfer class, think of FTP over USB.
I was thinking more along the lines of SMB/CIFS over USB (with optional UNIX extensions), but the principle is the same. Take a decent network filesystem protocol, adapt it for point-to-point use over a single, arbitrary, byte-oriented channel, standardize users, groups, and permissions, and then layer it over USB.
One nice thing about using SMB/CIFS would be that it could be implemented for most current operating systems with a simple USB-to-IP proxy and existing network filesystem drivers.
FTP (or WebDAV) would probably work just as well; I'm just not sure about potential protocol limitations. I've never known anyone to use FTP as a network filesystem protocol.
MTPFS Posted May 17, 2012 20:30 UTC (Thu) by jimparis (subscriber, #38647) [Link]
> One nice thing about using SMB/CIFS would be that it could be implemented for most current operating systems with a simple USB-to-IP proxy and existing network filesystem drivers.
You could even do it with no added PC software -- have your phone be a USB RNDIS interface that runs a DHCP server, and run a SMB/CIFS fileserver with all the right discovery stuff that makes it just show up in your normal network browser. I'm surprised they're not doing this.
MTPFS Posted May 17, 2012 21:51 UTC (Thu) by nybble41 (subscriber, #55106) [Link]
>> One nice thing about using SMB/CIFS would be that it could be implemented for most current operating systems with a simple USB-to-IP proxy and existing network filesystem drivers.
> You could even do it with no added PC software -- have your phone be a USB RNDIS interface that runs a DHCP server, and run a SMB/CIFS fileserver with all the right discovery stuff that makes it just show up in your normal network browser.
That assumes your PC is set up to automatically establish links over arbitrary USB network adapters, which seems like a rather insecure default. The USB-to-IP proxy in my proposal would only allow the device to present a restricted SMB host on a private, non-routable address range; it wouldn't be able to choose its address or access other services on the host PC.
Even ignoring the security aspects, I believe desktop Linux setups, at least with NetworkManager, normally prefer wired network connections over WiFi, and I wouldn't want my WiFi-connected laptop to disconnect from the Internet every time I plug in my tablet or smartphone.
IIRC, on Windows it chooses the faster network as the default route, unless you configure the metrics manually; depending on speed of the main network, the result may depend on whether the device shows up as a 100 Mbps or 1000 Mbps adapter. In the latter case (necessary to max out the USB at 480 Mbps) it could even cause issues for 100 Mbps LANs, which are still common, much less WiFi at anywhere from 12 to 300 Mbps.
MTPFS Posted May 18, 2012 11:08 UTC (Fri) by tialaramex (subscriber, #21167) [Link]
The default behaviour for most desktop systems is in fact to assume that the USB network device leads to the Internet, and further, if there is no better route to the Internet in use already that you plugged it in because you want to use it and so it should be configured and made ready to use.
(Obviously policy might prohibit non-superusers from having this functionality on a company machine for example)
But you are correct that a built-in Ethernet device will be preferred most often if it's available. However we live in the Future™ and even when some other device is the preferred route to the Internet, link-local services should work over alternative devices. So, at least in theory, mDNS advertising a shared drive over a USB device would make it show up and be accessible.
Of course since nobody does this today it probably wouldn't actually work right out of the box if you tried it. But all the components exist, getting it to work is just a matter of polish.
MTPFS Posted May 18, 2012 15:45 UTC (Fri) by nybble41 (subscriber, #55106) [Link]
> But you are correct that a built-in Ethernet device will be preferred most often if it's available.
Actually, my concern was just the opposite: that the built-in Ethernet or WiFi adapter might _not_ be preferred over the USB connection, which can only access this one device. Link-local access to the device will probably work just fine, but if the system selects that adapter as the default route there will be unfortunate side effects for the user's LAN/Internet connection.
> Of course since nobody does this today it probably wouldn't actually work right out of the box if you tried it.
That was my point. Sure, all the pieces are there, but the reason for making it an RNDIS interface to begin with was to avoid the need for any extra software. If you have to reconfigure the system or add special support for such devices, you might as well just include the more secure filesharing-only USB-to-IP proxy I originally suggested.
|
|||||||||||||