Menu
▾
▴
1 Attachments
#1492 Android: Kyocera Event
This is a fairly generic (I think) low-end android phone. When I put it into MTP mode, mtp-detect reports:
libmtp version: 1.1.10
Listing raw device(s)
Device 0 (VID=0482 and PID=0591) is UNKNOWN in libmtp v1.1.10.
Please report this VID/PID and the device model to the libmtp development team
Found 1 device(s):
0482:0591 @ bus 2, dev 12
Attempting to connect device(s)
ignoring libusb_claim_interface() = -6PTP_ERROR_IO: failed to open session, trying again after resetting USB interface
LIBMTP libusb: Attempt to reset device
inep: usb_get_endpoint_status(): No such device
outep: usb_get_endpoint_status(): No such device
libusb_open() failed!: No such file or directory
LIBMTP PANIC: Could not init USB on second attempt
Unable to open raw device 0
OK.
This turns off MTP on the phone. When I turn it back on and run lsusb -v, I get the attached report.
Other possibly relevant information: The GNOME file browser thinks its a USB Modem when it's in MTP mode, but allows me to access the storage, but it doesn't match what I see when I put it in storage device mode instead of MTP mode. (I deleted a bunch of files in storage device mode, and they appeared to still be there when I switched to MTP mode.) All very wonky.
Any more information I can provide, I'll be happy to do so. I am willing to build and install from source if necessary (running Debian GNU/Linux).
Discussion
Anonymous
added to git for 1.1.11 release, thanks!
(the id is added in music-players.h, and to get userlevel device access it should be in the udev or hwdb rules of the mtp package)
Hi, I cherry-picked the patch and applied it to debian's latest 1.1.10 package (so I could make sure the udev stuff was installed properly). It still gets a LIBMTP PANIC. Should I reopen this bug or start a new one? (Or is there some issue with using 1.1.10?)
My suspicion (based on a wild-ass guess) is that it has something to do with the system initially identifying the device as a modem. Perhaps it needs another flag, like DEVICE_FLAG_UNLOAD_DRIVER? I can try that, but I don't have much (any) experience with the libmtp code, so I may need help/advice on testing/debugging.
$ mtp-detect
libmtp version: 1.1.10
Listing raw device(s)
Device 0 (VID=0482 and PID=0591) is a Kyocera Event.
Found 1 device(s):
Kyocera: Event (0482:0591) @ bus 2, dev 30
Attempting to connect device(s)
ignoring libusb_claim_interface() = -6PTP_ERROR_IO: failed to open session, trying again after resetting USB interface
LIBMTP libusb: Attempt to reset device
inep: usb_get_endpoint_status(): No such device
outep: usb_get_endpoint_status(): No such device
libusb_open() failed!: No such device
LIBMTP PANIC: Could not init USB on second attempt
Unable to open raw device 0
OK.
$ grep -A1 Event /lib/udev/rules.d/69-libmtp.rules
Kyocera Event
ATTR{idVendor}=="0482", ATTR{idProduct}=="0591", SYMLINK+="libmtp-%k", MODE="660", GROUP="audio", ENV{ID_MTP_DEVICE}="1", ENV{ID_MEDIA_PLAYER}="1"
Oops, there's supposed to be a hash sign before the "Kyocera Event" in that last message. Apparently that's some special markup flag on here...
it must have reconnected after that open session.
does it work as root?
is there anything in "dmesg" about the device reconnecting?
Running as root does not seem to change anything.
When I initially plug the phone in (in charge-only mode), dmesg gets a 14-line stanza about detecting a USB storage device. I can run mtp-detect at that point, and it says no (mtp) devices detected. When I switch the phone to MTP mode, I get a shorter 7-line stanza in dmesg saying the device has disconnected, and a new device has been found. This time, it's not called a USB storage device, which is why the stanza is much shorter.
Now, when I run mtp-detect as root, I get a four-line stanza in dmesg (first line is highlighted):
[ 1044.663073] usb 6-3: usbfs: process 2663 (mtp-detect) did not claim interface 0 before use
[ 1044.775673] usb 6-3: reset high-speed USB device number 6 using ehci-pci
[ 1044.908014] usb 6-3: device firmware changed
[ 1044.909212] usb 6-3: USB disconnect, device number 6
Then the phone returns to charge-only mode, and I get a repeat of the first stanza (USB storage device detected, etc.) in dmesg.
SImilarly, if I go into rhythmbox, and set the phone to MTP mode, a device icon appears (this is new behavior since updating the library). When I click on the device icon, though, it simply disappears, and in dmesg, I see exactly the same thing as when running mtp-detect, except that the highlighted line warning "did not claim interface" is absent.
(I didn't try running rhythmbox as root—I don't know if I trust it that much.)
Of course, my goal is to have the phone work in rhythmbox the way my old, dying mp3 player did.
The problem may be that when you attempt to reset this device, it stops being an MTP device? I've been digging through the code a little, but I'm not quite sure how to test this hypothesis yet.
it has troubles connection, and thinks a usb reset will help, but then it goes back to the other mode (charging mode). rythmbox is doing the same thing as mtp-detect via libmtp, resetting the device which makes it disappear from the mtp radar :/
Well, I made some progress today. I realized that Gnome is using libmtp, so, on a hunch, I tried rebooting my system, and then, instead of logging into Gnome, I went to the console and ran mtp-detect, and it worked! But! When it was done, it turned off mtp mode on the device, so when I re-ran it, it said no mtp devices found.
One step forward, one step back... :)
I'm going to stick it on a debugger and see if I can pin down where and how it is turning off mtp mode. I suspect, as you say, that it's doing a usb reset somewhere, and I hope that this turns out to be an unnecessary reset, so we can somehow tell the system to skip it for this device. (Although there aren't many device feature bits left, are there? Never mind. We'll figure something out.)
Ok, I've still got at least two problems, but only one of them is yours. The other seems to be related to Gnome. Running under xfce, things are happier. And I certainly can't expect you to worry about Gnome bugs.
However, for mpt-detect resetting the device, I was finally able to get the FORCE_RESET flag disabled. It turns out that the code sets all the ANDROID_BUG flags if it detects and android device. Whether or not the device is known and has its own flags. This is a problem. I hacked around it by changing the definition of the ANDROID_BUG flagset, but obviously that's not a long term solution. What I would suggest is setting the ANDROID_BUG flags only if the device is an unknown android device, and otherwise using the flags associated with the device. Then we can set the Kyocera Event to have all the other flags, but not the FORCE_RESET one. I might be able to make a patch, but I haven't quite figured out how to do all of this yet.
(Of course, there may be other android devices that react badly to the forced reset, and nobody's bothered to report it because they don't realize it's a problem. I didn't until I started trying to figure out why rhythmbox wasn't seeing the device.)
yeah, the big problem is that we do not know for which devices this was introduced and why... and retesting all is not possible.
I applied a & ~DEVICE_FLAG_FORCE_RESET_ON_CLOSE
to the Kyocera event flags
I tried that myself, but it gets overridden in libmtp.c:
else if (is_android) { /* * If bugs are fixed in later versions, test on tmpext->major, tmpext->min or */ ptp_usb->rawdevice.device_entry.device_flags |= DEVICE_FLAGS_ANDROID_BUGS; LIBMTP_INFO("Android device detected, assigning default bug flags\n"); }That needs to be modified to say "else if (is_android && !is_known_device())" so that devices which are in the database don't get their flags overridden. Unfortunately, I don't know how to implement "is_known_device()" or even if there is such a function available already.
Either that, or, as the code suggests, test on the versions. I do believe that the mode switching (between mtp-mode and usb-storage mode) is a feature of more recent versions of android.