search

ADeadTrousers / twrp_device_Unihertz_Atom_LXL

Common device tree for the Unihertz Atom L and XL
Apache License 2.0
7 stars 3 forks source link

MTP isn't working as expected #2

Closed ADeadTrousers closed 1 year ago

ADeadTrousers commented 3 years ago

When MTP is enabled no connected device is shown on PC. Even worse: ADB is not working while MTP is enabled on phone.

ADeadTrousers commented 3 years ago

According to /tmp/recovery.log the error E:[MTP] could not open MTP driver, errno: 2 occurred. Found the corresponding lines in mtp_MtpServer.cpp. It looks like the MTP server tries to open /dev/mtp_usb but in TWRP the device does not exist. In Lineage the device exist though. My first guess would be a side effect from usb_otg but that works fine under Lineage alongside with MTP so why would it cause troubles in TWRP?

ADeadTrousers commented 3 years ago

Did a little bit of tinkering with init.recovery.usb.rc by combining all the necessary bits & pieces from init.rc, init.usb.rc, init.configfs.usb.rc and init.mt6771.usb.rc. Now the device /dev/mtp_usb exists. BUT The log now reads E:[MTP] Failed to start usb driver!. This happens in MtpServer.cpp right after the call of MtpDevHandle::start where a simple open command is used to connect to the device. According to dmesg this failed because of /dev/mtp_usb being busy. A little bit more tinkering in init.recovery.usb.rc I could get rid of the busy but still no success.

ADeadTrousers commented 3 years ago

e19bf8322e0042248fd65144fa34d643439a2ed3 Pros:

Cons:

ADeadTrousers commented 3 years ago

According to the kernel log the mtp-server just stops after initializing the devices to show:

[   25.783467]  (0)[435:recovery]mtp_open
[   25.784048]  (0)[435:recovery]mtp_open
[   25.784062]  (0)[435:recovery]MTP, <mtp_open(), 1722> BUSY
[   25.784087]  (0)[435:recovery]mtp_release
[   25.794208]  (0)[435:recovery]mtp_open

open > busy > release > open ... That looks like my patch for a busy mtp device

[   25.794249]  (0)[435:recovery]MTP, <mtp_read(), 798> in
[   25.794249] , skip<0>
[   25.794351]  (0)[48:kworker/0:1]MTP, <do_monitor_work(), 1802> IN <1 0 0 0 0 0 0 0 0 >
[   25.794370]  (0)[48:kworker/0:1]MTP, <do_monitor_work(), 1807> OUT <0 0 0 0 0 0 0 0 0 >
[   25.794589]  (0)[97:kworker/u16:1]USB_BOOST, <boost_work(), 293> id:0, begin of work
[   25.794622]  (1)[5:kworker/u16:0]USB_BOOST, <boost_work(), 293> id:1, begin of work
[   25.794834]  (2)[234:kworker/u16:2]USB_BOOST, <boost_work(), 293> id:2, begin of work
[   25.795371]  (4)[435:recovery]MTP, <protocol_dump(), 134> H<10 10020001 0>
[   25.795461]  (4)[435:recovery]MTP, <protocol_dump(), 134> H<c 20010003 0>
[   25.795484]  (4)[435:recovery]MTP, <mtp_read(), 798> in
[   25.795484] , skip<0>
[   25.795594]  (4)[435:recovery]MTP, <protocol_dump(), 134> H<c 10010001 1>
[   25.795709]  (4)[435:recovery]MTP, <protocol_dump(), 134> H<155 10010002 1>
[   25.795725]  (4)[435:recovery]MTP, <protocol_dump(), 134> H<c 20010003 1>
[   25.795754]  (4)[435:recovery]MTP, <mtp_read(), 798> in
[   25.795754] , skip<0>
[   25.795858]  (4)[435:recovery]MTP, <protocol_dump(), 134> H<14 98020001 2>
[   25.795888]  (4)[435:recovery]MTP, <protocol_dump(), 134> H<1e 98020002 2>
[   25.795903]  (4)[435:recovery]MTP, <protocol_dump(), 134> H<c 20010003 2>
[   25.795915]  (4)[435:recovery]MTP, <mtp_read(), 798> in
[   25.795915] , skip<0>
[   25.795997]  (4)[435:recovery]MTP, <protocol_dump(), 134> H<14 98020001 3>
[   25.796023]  (4)[435:recovery]MTP, <mtp_read(), 798> in
[   25.796023] , skip<0>
[   25.796120]  (4)[435:recovery]MTP, <protocol_dump(), 134> H<14 98020001 4>
[   25.796972]  (0)[97:kworker/u16:1][Power/PPM] (0x80)(-1)(0)(0-7)(0)(0)(4)(4) (0)(0)(4)(4) 
[   25.951329]  (0)[453:recovery]mtp_release

Some reads, some dumps... looks like it's beginning to serve data onto mtp. But in the end there is a small nondescript release and that's where the mtp-server stops never to be mentioned again later in the log. Normally a "server" is started as a thread to run in the background and should wait for work to do. But here something is forcing it to shut down prematurely and without any trace whatsoever.

ADeadTrousers commented 3 years ago

Comparing all settings under /config/usb_gadget in LOS and TWRP to get the missing pieces didn't help at all 7b597a184d12bf84eba95a699d0e0f5e960c341a I also removed my patch to fix the E:[MTP] Failed to start usb driver! as I just found out that the mtpserver thread is on auto restart to overcome usb state changes. So it's already circumventing busy mtp devices. In dmesg this can be seen too as the first try fails and some time later it succeeds like in my previous comment. But still no data is shown on the client side of mtp. It's still behaving like a "busy" device and fails after a timeout.

ADeadTrousers commented 3 years ago

Tried the suggested debugging step according to https://wiki.debian.org/mtp mtp-detect returns this:

libmtp version: 1.1.17

Listing raw device(s)
Device 0 (VID=0e8d and PID=201d) is a MediaTek Inc Elephone P8000.
   Found 1 device(s):
   MediaTek Inc: Elephone P8000 (0e8d:201d) @ bus 3, dev 59
Attempting to connect device(s)
error returned by libusb_claim_interface() = -6LIBMTP PANIC: Unable to initialize device
Unable to open raw device 0
OK.
ADeadTrousers commented 3 years ago

After letting TWRP autolock itself after a while mtp-detect returns this:

libmtp version: 1.1.17

Listing raw device(s)
Device 0 (VID=0e8d and PID=201d) is a MediaTek Inc Elephone P8000.
   Found 1 device(s):
   MediaTek Inc: Elephone P8000 (0e8d:201d) @ bus 3, dev 60
Attempting to connect device(s)
PTP_ERROR_IO: failed to open session, trying again after resetting USB interface
LIBMTP libusb: Attempt to reset device

It's also not able to finish and I had to CTRL+C it. So it is somehow "connected" to the lock-state of the phone. As suggested in https://bbs.archlinux.org/viewtopic.php?id=254808 I tried to prevent mtp from autoload with a udev rule (https://askubuntu.com/questions/868098/disable-automount-of-a-specific-mtp-device) but that kept the device in a load-unload-cycle (flashing icon in the side panel)

ADeadTrousers commented 3 years ago

You got to be kidding me... Under Windows MTP is working fine. Either from TWRP or LOS the files are readable. Even if the screen autolocks. BUT Under Linux MTP only works from LOS. So it's an OS problem not a device problem.

ADeadTrousers commented 1 year ago

With all the changes I did in #6 it also seems to have fixed the MTP problem under Linux.