yashsingh1/xdaforums huggingface dataset:
[Nexus 4 Original Android Development] sga999:
ziddey, this response is premature because I don't have anything to give you yet. But I wanted to answer some of what you asked right away.

I do not have "Enable fast USB charge" checked in Franco's app.

When I said I have had problems when USB storage is mounted, I should have said when it is INITIALLY mounted after a reboot. Just as you said, I could leave it on all night after getting it to mount, and there would be no issues. But I'm just talking about the "double plug" requirement...it happens to me "all the time" (I'll tell you more below). I had decided that was just the way it was going to work, so I didn't say much after I gave you that log I was "happy" with plugging it in again and seeing it work.

Unfortunately, I have too many variables in my testing. I think one of my very first posts mentioned that my flash drive seemed to work better than my micro sd card (in a card reader adapter).(maybe it was to Captain, not you). But I want to use the micro sd card, so I bought 3 more adapters from eBay! The results are almost always the same with all 4 card readers.....I boot, plug it in, nothing, plug it in again, works. When I say 'almost', I mean that once in a blue moon, just one of them will work the first time after booting.

However, I just tried the flash drive, and with 4 reboots, it has worked 4 times. Certainly not proof that it will always work, but a pretty good indicator. And I did it with both the proprietary charger (just trying one of two tonight) and with the standard wall charger.

I did have a cable problem before, but I ordered 2 different types of y-cables, and I'm confident they are both working fine.

Is there something I'm missing about what order to plug things in? I always have the device plugged into the cable first, power already plugged also, then I plug the cable into the phone.

So....I'll read your post more carefully, but I wanted to let you know where I'm at right now. After you've read all of the above, maybe you're not interested in a log at all! I mean, if I end up telling you that the flash drive works the first time every time, with proprietary charger or not, do you still want to see something? If so, maybe you can pick a specific case from all the ones I've described.

I'm still having the problem where the "Available" space just shows "Available" instead of the amount of free space. I've never seen this work yet. This happens with either the flash drive or the micro sd card. If I use those with a Samsung Galaxy Tab 2 7.0, the available space shows perfectly on both. This occurs even when I build the framework-res.apk myself, so it's not about your patch. I have no idea what this could be. I haven't seen any other posts about this. It's not a big deal, but I'm a curious cat and would sure like to know what's causing it.

EDIT: None of the tests tonight were ever getting power from the laptop. I don't know if that's interesting to you or not.
[Nexus 4 Original Android Development] ziddey:
Ah, I should clarify. Your external charger only has the potential to be "proprietary" when you plug it directly into the phone. Hooking it up to a y-cable or equivalent will isolate the data pins of the charger.

The test build was to try to fix normal use of such chargers.

As for the USB drives not being detected on the first plug, that's not something I've seen with any of my devices, so a log would definitely help.

Powering the USB device before connecting to the phone should always work. In the past, I've been able to connect the phone first as well (it detects as an sdp charger i.e. computer) but switches to host mode after the device is plugged in (it detects a brief loss of power so it redetects the charger type). I did streamline the code a little (something went awry with my github and I haven't been able to commit the new changes) but I'll run through it since it might be causing this scenario to no longer work.

That's really strange about it not displaying the storage space, especially since you're compiling storage_list.xml against your own framework. I haven't seen that with any if my drives. You said you tried out Paranoid Android at one point. Did it work then? Or maybe someone else running either stock or PA can chime in about if it's working for them. I'm assuming you're working with FAT32? Have you tried reformatting the drive? Multiple partitions or just one?
[Nexus 4 Original Android Development] sga999:
Okay, ziddey, sorry I missed the point about proprietary. I'm sure you've figured it out by now that I am not a hardware person. I have a math degree and was a programmer for 30 years, and of course, there's always some hardware involved in that. But not even close to being enough to understand what you're doing here!

So now I tried the same situation as when I gave you the log before. I just used a standard charging cable, getting power from the power bank, plugged into the phone. I can plug and unplug forever, and there's no charge occurring. Then I plug into the wall charger, it charges. Then I plug back into the power bank, it now charges. So do you need a log to show this, even though it is the same thing I gave you before?

And....you want a second log for the case where I have the y-cable hooked up and I have to double plug in order for the device to mount?

And both of these logs should be the dmesg type, not logcat, right?

With regard to the available space problem, both the flash drive and the micro sd card are FAT32, single partition. The flash drive has been reformatted, but not the micro sd card. I did try PA at one point....probably when I was trying to figure out things about framework-res.apk. I'm pretty sure that it did not show the space properly, but I won't swear to it. I can always try PA again sometime soon.
[Nexus 4 Original Android Development] ziddey:
I was trying to address the issue with proprietary chargers in the test build. But if it's still not working, I'm curious to see if the logs are any different.

Yes, I'd love a log of when you have to double plug to get your USB drive to detect.

How about plugging into a computer or wall adapter? Do you need to double plug for that or does it work normally?

Yes, dmesg logs please when you get the chance. I'm going to bed now but I'll see if anything sticks out tomorrow.
[Nexus 4 Original Android Development] sga999:
For the double plug problem, I need to double plug for all of them, i.e. power bank, computer, and wall charger. That log may come later tonight, but it might be tomorrow.

But for starters, here's the dmesg of the power bank not charging the phone. I don't think this log looks much different from the last time, but I didn't look at it that much. The sequence was plug in cable into phone (no charge), unplug, plug in again (still no charge), unplug.

EDIT: It's the next day, and I think this one isn't good. last_kmsg way seems to be the right way. See latest post below with kmsg_nocharge.txt. It does look different from before.
[Nexus 4 Original Android Development] sga999:
UPDATE: Gosh, I'm terrible with these logs. On that first one, I did the sequence of plugging, unplugging. Then I got the log by doing adbwireless/adb connect, adb shell, dmesg > /sdcard/dmesg.txt. It seemed to look similar to my log from a couple of months ago, so I thought I was doing it right. (I should have called that one something like dmesg_nocharge.txt, but it's dmesg.txt).

But then I went on to the next test. I left the power bank out of this one and used the laptop for power, just to make it simpler to read (maybe). The sequence was plug it in, no mount, unplug, plug it in again, now it mounted. I did the same steps as before to get the dmesg. But it only had about 4 seconds worth in it, and nothing looked interesting. I had read in some thread that you can get dmesg from /proc/kmsg or /proc/last_kmsg. The former had no data, but the latter did. So I looked at that, and it didn't look good either. So I rebooted, then looked at /proc/last_kmsg again. Now it seemed to match what I had done during that test.

So....that's the one I'm adding here....called dmesg_doubleplug.txt. I did try to read more about the "right way" to get dmesg, but there are so many things to read, each saying something different. I think you may have told me to use terminal emulator. That would indicate I should get it right while it's being created. Yet that log didn't seem good on this 2nd test, while the /proc/last_kmsg after rebooting looks better.

Sorry to ramble....getting late.

Here is an interesting difference between plugging the first and 2nd time....

failure:

[ 118.656860] hub 2-0:1.0: unable to enumerate USB device on port 1

success:

[ 132.621551] usb 2-1: New USB device found, idVendor=14cd, idProduct=121f
[Nexus 4 Original Android Development] forcedairinduction:
I'm eternaly grateful for the otg hack ziddey. Works perfectly except I can't install roms from zips saved on memory stick, I have to copy them to the phone first as zips, then flash. Is there a way around this or am I being a knob??

Cheers
[Nexus 4 Original Android Development] sga999:
Okay, here's the last_kmsg for the no charge problem with the power bank. Sorry for the missteps. It looks similar to the double plug problem, i.e. both are "unable to enumerate".

[ 420.826110] hub 2-0:1.0: unable to enumerate USB device on port 1
[Nexus 4 Original Android Development] sga999:
EDIT: And here's another that shows two failed attempts to charge with a good attempt after connecting to the wall charger.
[Nexus 4 Original Android Development] ziddey:
That's extremely puzzling. It looks almost as if verbose usb debugging messaging isn't enabled. But it is the right test kernel, and I just verified that it is.. Maybe it logs differently for last_kmsg?

Since you're able to use wireless adb, try this:

Clear the buffer first

# cat /proc/kmsg

Log events for first test

# cat /proc/kmsg > 1_pb_plug.log

Plug powerbank

CTRL-C

Log events for unplug

# cat /proc/kmsg > 2_pb_unplug.log

Unplug powerbank

CTRL-C

etc..

All that said, you can probably help a whole lot more directly. I've never dealt with a u32 variable before (32bit unsigned int?), but I was hoping to still be able to compare it against regular ints:

u32 pc;
...
pc = readl_relaxed(USB_PORTSC);
pr_debug("portsc = %x\n", pc);
...
if (pc == 80001805)
...

Or would I need to typecast 80001805 with (u32)? It compiles without warnings or errors. I'll check against a known portsc myself in a sec. Still waking up.

edit: Doh, looks like pc is hex (%x). Going to try changing the if condition to pc == 0x80001805.

edit: Yep, that worked. Here's an updated test. Again, this doesn't address the double plug issue, but does aim to fix proprietary charger compatibility (again, assuming all proprietary chargers will result in portsc register of 80001805).

ziddey-otg-05111504.zip
[Nexus 4 Original Android Development] ziddey:
Recoveries are completely independent units from the kernel/ROM. Maybe I'll look into creating a modded recovery in the future.
[Nexus 4 Original Android Development] sga999:
ziddey, I was trying to get more logs as you suggested and was having trouble getting the first one. I followed your steps exactly and then realized I needed CTRL-C after the clear step. I should have been thinking rather than following blindly. But this stuff just seems to give me big headaches, so I thought I better do what you said.

Anyway, now I see your edits and that you have something new. I'll try it soon. I was going to asking you about no 0x or x or whatever, but I was getting the logs first. As far as my coding ability, I did mostly assembly language programming and some C. It also has been 13 years since I did any programming at all! So I'm not going to be very good at looking at this. In fact, I pondered that 'expr' stuff in your otgmod.sh for a while, and I still don't understand lots of that script syntax. I have very little unix/linux/ubuntu knowledge. So....that being said, if I have examples in front of me, I can work my way through it and figure things out eventually. Feel free to ask me, and I'll help if I can.

I'll get you more logs soon.

EDIT: Well, if it works, you don't want logs, right?

---------- Post added at 01:16 PM ---------- Previous post was at 01:04 PM ----------

Just tried it and no luck. Before I get logs, I just wanted to make sure you don't see anything else obvious that you might want to fix first.
[Nexus 4 Original Android Development] sga999:
Here's a log of just plugging into the power bank. I see the 80001805 stuff. Let me know if you need the unplug or more steps.
[Nexus 4 Original Android Development] RussianBear:
Sga, have you tried a different usb media? I've had the same exact issue with one of the usb card readers. Tried a different one and everything is ok now.
[Nexus 4 Original Android Development] sga999:
As I said in one of my posts, I have tried 4 of them!
[Nexus 4 Original Android Development] sga999:
Now that you got me on the right track to getting good dmesg logs (clearing /proc/kmsg first, etc.), I got a better one of the "double problem" with the micro sd card. I'm plugging it into the laptop, not the power bank. So why does 80001805 appear here?

Here are a few lines from the first time I plug into the laptop and it fails:

<7>[ 189.409545] hub 2-0:1.0: port 1: status 0101 change 0001

<7>[ 189.509460] hub 2-0:1.0: state 7 ports 1 chg 0002 evt 0000

<7>[ 189.509490] hub 2-0:1.0: port 1, status 0101, change 0000, 12 Mb/s

<7>[ 189.564544] portsc = 80001805

<6>[ 189.564544] ***UNFORCING USB HOST MODE WITH CHARGING - PROPRIETARY CHARGER DETECTED***

Here is the good case when I plug into the laptop and USB storage is mounted:

<7>[ 230.559631] hub 2-0:1.0: port 1: status 0101 change 0001

<7>[ 230.647247] msm_hsic_host msm_hsic_host: msm_hsic_wakeup_irq: hsic remote wakeup interrupt 335 cnt: 42, 0

<7>[ 230.647277] msm_hsic_host msm_hsic_host: EHCI runtime resume

<7>[ 230.647399] msm_hsic_host msm_hsic_host: HSIC-USB exited from low power mode

Here are the full logs that contain those lines.
[Nexus 4 Original Android Development] Gia90:
I was using the stock ROM...

I tried falshing back the stock kernel but the issue was still there...

I ended up flashing another ROM..

Thank you for your precise answer btw :)
[Nexus 4 Original Android Development] sga999:
ziddey, I managed to fix the "Available" problem by commenting one line in StorageVolumePreferenceCategory.smali (or .class for the java file) in Settings.apk. It is related to something about the state of the device mounted. Too hard to explain here.

What I can't understand is why others don't have this same problem. Would you possibly have a different Settings.apk on your other rom? I did try Paranoid Android yesterday, and the same problem occurred. At that time, I hadn't gotten very far into this, so I didn't look at that Settings.apk. And it is probably the same since I had the same problem with it and the stock rom (I'm on stock 4.2.2 most of the time).

Is there anyone else reading this who is using stock rom? If so, do you get an accurate amount for the "Available" under USB STORAGE? Or do you only get a heading with Available and the result is also Available (in smaller font)? What I'm guessing is that most people with stock rom never saw this section at all until ziddey changed the zip command to leave out the -f (and that was a very recent change) Since there was no USB STORAGE section, they certainly weren't seeing my problem!

Ziddey, maybe you have no interest, but can you install the stock rom and see what you see?

I don't know why it works on other roms. Ziddey, I really doubt that it's different, but can you put the Settings.apk from your rom on a server? If it turns out to be identical to mine, then for some reason, the "mount state" must be different for me than for you. (This happens on both micro sd cards and a flash drive).

Here are just a few lines of the code, and I've indicated which line I commented out to make it work. I'm showing the java code, just to make it easier to read, but I actually had to comment the smali code. Gosh, that's painful.

private void updatePreferencesFromState()

{

if (mVolume != null)

{

mMountTogglePreference.setEnabled(true);

String s = mStorageManager.getVolumeState(mVolume.getPath());

if (!"mounted_ro".equals(s))

{

mItemAvailable.setSummary(0x7f0b0302);	// this is the line sga999 commented

} else

{

mItemAvailable.setSummary(0x7f0b0303);

if (mFormatPreference != null)

removePreference(mFormatPreference);

}

if (!"mounted".equals(s) && !"mounted_ro".equals(s))

{

if (!"unmounted".equals(s) && !"nofs".equals(s) && !"unmountable".equals(s))

{ .........
[Nexus 4 Original Android Development] EDV11:
I haven't checked that. I'll do it later when I get to the office and I'll let you know. I'm on stock ROM

Enviado desde mi Nexus 4
[Nexus 4 Original Android Development] sga999:
Thanks, that would be great! I'd really love for someone else to say they're seeing this same problem.
[Nexus 4 Original Android Development] ziddey:
Good ol' CM: https://github.com/CyanogenMod/andr...mmit/8b2940c92ac593f44337401b4737dd186fe24345
[Nexus 4 Original Android Development] sga999:
Well, I haven't looked at that code closely, but the description doesn't seem to match my problem. Mine has nothing to do with misc amount being duplicated in internal. But since your rom is working, maybe something in all of those lines does address my problem. But it's not obvious with a quick glance at the code.

I posted about this over a month ago, and no one said they had this problem. Again, if it's only on stock (and PA for me), then it must be because they weren't seeing the USB STORAGE section at all. Or they just weren't looking.
[Nexus 4 Original Android Development] ziddey:
sga999, I looked at microbad.txt. The problem occurs after the job of detecting and switching to host mode is done. The sequence goes:

charger detected (PMIC: BSV set)

proprietary charger type detected -> force host+charger bit (***FORCING...ID_A**** message)

otg work code responds to ID_A bit and switches to host mode (b_idle work -> !id || id_A -> a_idle work -> ... -> a_wait_bcon -> ... a_host)

a_wait_bcon is when the A device (host phone) is waiting for a B device (client usb drive in this case) to connect.

The problem is that the host and client do not communicate properly, as witnessed by the non-stop "detected XactErr len 0/8" messages. This boils down to a bad connection or a faulty/failing usb drive, cable, or hopefully not the host itself.

Did you say that one of your usb drives works every time? Maybe that drive makes a better connection with the otg cable than your other devices?

microgood.txt shows exactly what's supposed to happen.
[Nexus 4 Original Android Development] ziddey:
Yes, the description up top is not relevant, but this is:

That commit is the only difference between CM code and AOSP. I'm imagining your code got all inverted from the decompile.
[Nexus 4 Original Android Development] sga999:
ziddey, now I do think that part about title, not summary will fix it...that's exactly at the same spot where I commented the single line.

As far as the "double plug" problem, it may be that a flash drive always works the first time. But I haven't done enough testing to prove that. With the micro sd card in 4 different adapters, the result is always the same. Fails the first, works the next. I'll read your comments more tomorrow. But off the top of my head, I would think it would be more random if it's a problem between the cable and the many micro sd adapters.

Did you learn anything else about the issue with not charging with the power bank?
[Nexus 4 Original Android Development] ziddey:
I'm going to look into it more tomorrow. It's not so much an "issue" (since that's the intent) but rather that there needs to be a way differentiate between a real proprietary charger and a usb device. The mod hijacks a proprietary charger detection and forces host mode. Charging is then disabled until usb device enumeration (by design). The problem is that a proprietary charger is not a usb device; it's simply outputting a fixed voltage on the data pins, so enumeration will obviously fail (same errors as you're getting when the usb drive isn't detecting properly). For the time being, I'm looking into using the portsc register to throw the controller back to peripheral mode and enable charging. It's absolutely not ideal, but it's a stop-gap until I can figure out how to differentiate the two during the charger type detection. Right now, I'm relying on simply setting the appropriate bits and letting the subsequent "work order" handle everything, but it seems that it's not being completed. So since it's a stop-gap anyway, I might just directly call the associated functions to disable host mode.
[Nexus 4 Original Android Development] EDV11:
I can confirm I'm seeing the same as you do. Under USB storage, it comes with Available and available below that.
[Nexus 4 Original Android Development] EDV11:
Here is the screenshot

Enviado desde mi Nexus 4
[Nexus 4 Original Android Development] sga999:
Thanks for confirming. It's finally nice to know I'm not alone!
[Nexus 4 Original Android Development] ritchea:
I don't have that problem, but I did have to revert my XenonHD rom from latest version (9) to version 8 as my storage devices would not show up. I got a notification that USB drive had been mounted but also that it had 0 content. It's not important to me to have that newer version, but the dev team did emphasize that it was a total new, from-scratch build so something was changed.
[Nexus 4 Original Android Development] ziddey:
Oh wow, I just noticed a nasty bug with the current hack. I didn't realize the case for a wall charger (USB_DCP_CHARGER) falls through to USB_PROPRIETARY_CHARGER, which is being used to trigger host mode. This causes the device to switch to host mode, drop back out, and then get in a suspended mode. This makes it look like the charger keeps cutting out in rapid succession, resulting in a failure to properly charge. I'm still working on some other problems, but here's an interim release to restore proper charging with a wall charger. Also addressed is the delay in disabling host mode, which is currently introducing/exaggerating some new issues. For the mean time, don't attach/detach devices while the otg cable is connected to the phone, and there shouldn't be a problem.

otg_boot_r3.img: http://d-h.st/vST
[Nexus 4 Original Android Development] pcsjx:
In fact the framework you modified can only work on CM 10.1 up to 0311 version. After the 0312 the file was updated. Using your file will lead to a lot of problems. And the kernel is based on Franco r80. It seems to be a little old.
[Nexus 4 Original Android Development] sga999:
The #80 is ziddey's own numbering system for his builds. I think he said it is currently based on Franco #93.