yashsingh1/xdaforums huggingface dataset:
[Nexus 4 Original Android Development] parkedraccoon:
From what I've tried it should. I have a Logitech F310, which has xbox input mode and shows up as a generic XBox pad. HOWEVER you need to follow this:

Download the modules from this post and extract the files to a folder.

In a terminal emulator, type the following commands

$ su
# cd [location]
# insmod ff-memless.ko
# insmod xpad.ko

*I need the hid-logitech file here, because I have a different controller. I also used gscript to make a shortcut for this (and also to manually enable/disable otg)

I'm not quite sure if you need it, but if it still doesn't work, check system/usr/keylayout and make sure you have Vendor_045e_Product_028e.kl. If you don't see it, copy the attached file, set permissions to rw-r--r-- and reboot and try again. You'll need to run #2 again every time you boot, this is why I use gscript.
[Nexus 4 Original Android Development] hellrokr:
thanks! i'll try this out when my phone comes. i'll ask you if i encounter any hiccups :);)
[Nexus 4 Original Android Development] vikas_toad:
So am i interpreting it correctly by assuming that automatic usb host would work if 5v is only provided to the voltage pins of the usb device (and not to phone) thus powering the usb device inturn powering the data pins connected to the phone inturn making the phone detect a propietary charger inturn automatically triggering the host mode? That way need of a diode would be eliminated to prevent charging...

Or do i still need to provide 5v to the voltage pins of the phone?

Another quickie,

So will generic usb gamepads like http://www.ebay.in/itm/BRAND-NEW-QU..._203&hash=item4d0bbc66ec&_uhb=1#ht_2493wt_689 work with this patch?
[Nexus 4 Original Android Development] ziddey:
No, charger type detection takes place after the initial charger detection.

Gamepads will work assuming the appropriate drivers are available. Read even just a few posts before yours... It doesn't look like much is built into the kernel, but you can build modules as you see fit. They are really beyond the realm of host mode support, but I will look into building some modules later on.

For now, I'm looking into the possibility of modularizing the otg modifications, but it's new territory for me, so it's going to take some time to figure out (if it's even possible/feasible).
[Nexus 4 Original Android Development] DirgeExtinction:
Take your time and best of luck. :) I would love for one day that all the N4 kernels have USB OTG mode.
[Nexus 4 Original Android Development] alfonzo1955:
The RTL2832 USB dongle doesn't work with it. The value of /sys/kernel/debug/msm_otg/mode changes from "none" to "host" for a brief moment when I plug it in, and that's it. When I run "echo host > /sys/kernel/debug/msm_otg/mode", the value does not change. I am running it as root.
[Nexus 4 Original Android Development] vikas_toad:
Finally done with the mod... usb sticks working fine..

next step.. making game pads work... as quoted , i understand that gamepads need modules to make them work,

how ever i doubt whether the generic ones(very cheap 5-10usd and look like ps2 controllers) need any extra modules as they work straightaway in pc (no drivers needed--except for rumble) and is detected as HID

will be getting a generic gamepad in a few days

perhaps you could help me with the modules(if needed) and how to go about with them ?

After a little diggin here and there... it seems linux handles gamepads using joydev.ko and there have been other devices that gained gamepad support by joydev.ko(along with the working usb-host mode that this patch has already achieved).. perhaps joydev.ko is all that is needed for gamepad support on nexus 4? ?

some of the devices that gained gamepad support with joydev.ko

http://xdaforums.com/showthread.php?p=11982604

http://www.slatedroid.com/topic/26640-usb-gamepad-working-with-novo-7a/

Also.. if this helps anything http://vrjuggler.org/docs/vrjuggler/2.0/configuration.guide/configuring_vr_juggler/apcs05.html

also, this is some sort of source for joydev.c from android 3.4 https://android.googlesource.com/kernel/common.git/+/android-3.4/drivers/input/joydev.c

and this is linux source 3.4 for arm architecture http://lxr.free-electrons.com/source/drivers/input/joydev.c?v=3.4

those were the drivers that make use of joydev kernel module, couldlnt find the actual joydev module though..

(EDIT: It seems the joydev kernel module is present in the linux kernel source and has to be compiled)

Or may be the module is included in the nexus 4 kernel and just needs drivers as as you said?

Above are the links for the drivers

and something pretty interesting

there are keylayouts for various controllers including ps3,xbox360 , some racing wheel etc and though they are wireless(and the racing wheels may be wired or wireless whatever i didnt check that),

what is interesting is the keylayout named "Vendor_046d_product_c216.kl"

open it up in a text editor and you'll realize that actually it is for "Logi tech Dual Action Controller" http://www.logitech.com/en-us/support/288?osid=14&bit=32

which is a wired one... (its a pretty old one and has the same keys as the playstation controller looking generic gamepads )

so the support is definitely there... just need to figure out how to enable it

just adding my 2 cents make things work

Meanwhile if someone would test a generic gamepad via usb otg with this kernel patch it would be very helpful

I seriously wonder why aren't other devs pitching in

(This was originally a 4 line post)
[Nexus 4 Original Android Development] vikas_toad:
Some more findings you might find helpful ziddey,http://xdaforums.com/showthread.php?t=1584850

it has various .ko and .kl files for various gamepads

The op states that hid-dr.ko and Vendor_0079_Product_0006.kl is needed for those no name chinese controllers(most probably the generic ones)

And the second post says that onlyVendor_0079_Product_0006.kl is needed..

Well that may be the case of asus tf101

http://xdaforums.com/showthread.php?t=1240278 this has the joydev.ko but for sgs2

Oh and i found this later on

http://modules.libres.ch/browse/linux/v3.4/arm/

That has all the .ko module files for linux kernel 3.4 arm architecture (including joydev.ko, hid-dr.ko,)

The above link only has the list,

so here are the sources

hid-dr.c http://lxr.free-electrons.com/source....c?v=3.4;a=arm

xpad.c http://lxr.free-electrons.com/source....c?v=3.4;a=arm

ff-memless.c http://lxr.free-electrons.com/source....c?v=3.4;a=arm

joydev.c http://lxr.free-electrons.com/source....c?v=3.4;a=arm

hid-logitech-dj.c http://lxr.free-electrons.com/source....c?v=3.4;a=arm

Well perhaps if you could compile the appropriate files(including joydev.ko if needed) for nexus 4 and that might be the solution for gamepads?

Eagerly waiting your response ziddey
[Nexus 4 Original Android Development] brolic925t:
Any way to have this patch on fauxs kernel?
[Nexus 4 Original Android Development] tarroyo:
If I have movies, music etc. that I downloaded on the N4 and want to transfer them to a flash drive which cable would I need? OTG Y or USB OTG?
[Nexus 4 Original Android Development] ritchea:
If all you want to do it transfer files to a flash drive, put them on pc then on the flash drive. If you want to run them on your N4 from the flash drive (or you do not have a pc), you are going to need the power supply in addition to the OTG connection. The Y cable seems to provide the simplest solution.
[Nexus 4 Original Android Development] tarroyo:
Thanx!
[Nexus 4 Original Android Development] hatyrei:
Hi can i download this script so i can mount my Nexus 4 as a usb device to my car? I have a 2013 Chevy Spark when i connect it it says usb device not recognize.... :P. I just wonder because it supports apple products without sd card too. so why it can;t support our Nexus 4 :( thanks.
[Nexus 4 Original Android Development] dexim:
That's not what this is for. This is for making your phone a USB host, so you can connect devices to it.

In your case, your car is the USB host. You need to make your phone's internal memory mount as a drive when connected to a USB host. (In simple terms, this thread is the opposite of what you are looking for.)
[Nexus 4 Original Android Development] ritchea:
moved reply to other hatyrei thread.
[Nexus 4 Original Android Development] ziddey:
2013.05.06 1634ET: ziddey-otg-005061634.zip Maintenance build. Based off Franco's current nightlies branch (#134?). Updated storage_list.xml to match current CM nightlites. Removed freshen flag to hopefully address issues with framework-res.apk not being patched (thanks sga999).

md5sum 4156ba603b373e20fd892c31ddc3a861

I was hoping to have gained some ground in terms of figuring out a way to create a kernel module to apply the msm_otg modifications, but am really out of my element. I've been exchanging emails with someone who has a whole lot more knowledge and may be able to provide some insight.

So for the time being, here's a release based on Franco's current nightlies branch, which I'm assuming is roughly #134. There seems to be a slight delay after pressing the power button, but I'm not seeing anything unusual in the logs. Will look into it in a bit.

Update: It looks like the issue might be with the current CM nightly, but I'm still doing more testing. It appears the autobrightness feature is broken, and is also causing the power button delay.

Update2: Well that's odd. The light sensor is broken with this build. I tested Franco's #134 and it works just fine. Looking into it now.

Update3: Seems to be a freak incident. Will keep an eye out but haven't been able to reproduce again.

Skip this release. Usb storage is broken.
[Nexus 4 Original Android Development] RussianBear:
Ziddey, the storage isn't getting updated in settings-storage. It just says "mount usb" when it's already mounted. I can access the drive via a root explorer, however. The apps don't see it either. Flashed your earlier release and it's working properly. Tried a few times (flashing newest, then older version) and got the same result.
[Nexus 4 Original Android Development] sga999:
Same here. There is no usbdisk0 (there is usbdisk, but it shows N/A in ES File Explorer). I know the framework-res.apk is being updated (now that freshen has been removed) because the string that is supposed to be "USB STORAGE" now changed to "ACCESSIBILITY CANCELED:". (This is to be expected with the incompatibility with framework-res.apk and strings.xml). Unlike RussianBear, I can't access the drive at all.

EDIT: Ziddey, I forgot to say thanks for updating to Franco's #134. That does seem to be his latest...for about a week.
[Nexus 4 Original Android Development] ziddey:
Oops. I started with a new ramdisk in case there were any changes since M1, and made a typo.

2013.05.06 1846ET: ziddey-otg-05061846.zip Fixed typo in last build's init.mako.rc that broke usb storage.

md5sum f50dc40c9515468d46c26731ac0cab34

As for the light sensor issue, it seems to have been a one time glitch. I haven't been able to reproduce it and am hoping it was just a freak event.
[Nexus 4 Original Android Development] sga999:
It's working well for me now. Thanks.
[Nexus 4 Original Android Development] ziddey:
And here are the updated modules ff-memless.ko, hid-logitech.ko, and xpad.ko.

modules.r134.zip c696786332314447f691e05dcef5b229
[Nexus 4 Original Android Development] RussianBear:
Amen to that. Thanks once again, Ziddey!
[Nexus 4 Original Android Development] wangtang:
it's working on aokp milestone rom

However, i just got 2 problems.

1. After used OTG, it's not working with external bettery charger. if i want to using external bettery, i have to charging with travel adapter first and then i can use external bettery.

2. On my storage didn't show "usb storage". it just show me one of warning message like this. Of course it's working well

5/6 patch is more stable than last patch

Thank you ziddey:laugh:
[Nexus 4 Original Android Development] vikas_toad:
hey can you please also compile hid-dr.ko ??

its needed for generic gamepads support, i have written a humongous post about it just one page back

source hid-dr.c : http://lxr.free-electrons.com/source/drivers/hid/hid-dr.c?v=3.4;a=arm

Thank you
[Nexus 4 Original Android Development] Wis76:
Thanks for the update! Now Touch Control works again. ^___^
[Nexus 4 Original Android Development] screenoff:
I have a HTC One X Plus that is rooted.

I have both a Non-Powered and a Powered USB OTG, which both work fine when the phone is booted up, I can read the USB fine but I am unsure how to read the USB when in Recovery mode.

I have tried both the latest International versions of TWRP and CWM Touch but I am unable to figure out how to access the USB in Recovery Mode.

The reason that I am wanting to do this is to be able have a number of different ROMS and other Utilities stored on the USB drive so that i do not have to use Sideload everytime that i format or do other various tasks.

How do I actually access the USB drive in Recovery ?

I have tried the Zipped patch but it wont run.

Thank you.
[Nexus 4 Original Android Development] ziddey:
modules-r134.zip 3e313d80950c68b3f6fdde8594288931

ff-memless.ko

hid-dr.ko

hid-logitech.ko

xpad.ko
[Nexus 4 Original Android Development] ziddey:
2013.05.07 1907ET: ziddey-otg-05071907.zip Should now patch precompiled storage_list.xml to address incorrect strings (Internal Storage/USB Storage).

md5sum 090123253162ab4264d533053e2441d1
[Nexus 4 Original Android Development] alfonzo1955:
I don't know why, but I can't manually set OTG mode. When I echo "host", the file does not change. Can someone please help me?
[Nexus 4 Original Android Development] ziddey:
Why are you setting the mode manually? The feature exists mostly for debugging purposes only. Check /sys/kernel/debug/msm_otg/otg_state. It should switch to a_wait_bcon (from b_idle) if you've switched to host mode without a device attached.
[Nexus 4 Original Android Development] alfonzo1955:
When I try to use my RTL2832, it switches from host to none and I can't change it back to host. otg_state goes from a_host to a_wait_bcon.
[Nexus 4 Original Android Development] sga999:
My "USB STORAGE" still says "ACCESSIBILITY CANCELED.". Should this be working for all roms? I'm on stock 4.2.2 still.
[Nexus 4 Original Android Development] ziddey:
Ahh, looks like a program I'm calling in the script doesn't exist in recovery. Looking into alternatives..
[Nexus 4 Original Android Development] ziddey:
2013.05.08 0051ET: ziddey-otg-05080051.zip Had to rewrite script due to reduced functionality of some busybox applets and other issues. Hopefully, it actually works now.

md5sum ce78c44796aed0d062f9bac4641d9782

I've done some limited testing and it seems to work. Let me know if it's still broken.
[Nexus 4 Original Android Development] sga999:
Gosh, this forum was down for many hours, I guess.

Yes, I tried executing parts of your otgmod.sh, and I had problems with both --complement option of cut, and also bc command. But there's something else I don't understand. It seems like you're looking at the storage_list.xml from the "copied apk", i.e. the one ending in .1. And you're expecting 46 or 48 as part of the offset for the internal and usb strings? I can see that those would be in YOUR storage_list.xml, but not the copied one. Maybe I'm misinterpreting something.

EDIT: Ziddey, sorry, ignore that...I was trying for a long time to post that to you, and now I see the one above mine where you've made changes. I'll try that one.

---------- Post added at 10:53 PM ---------- Previous post was at 10:29 PM ----------

When I click Settings-Storage, I get "Unfortunately, Settings has stopped". I'll try running parts of your script if you want me to.
[Nexus 4 Original Android Development] brolic925t:
Bump? What if I just put the files from fauxs kernel into the zip will it work as a faux otg patch?
[Nexus 4 Original Android Development] wangtang:
Today(05/08) patch works great.

Even fixed external battery problem.

Thank you ziddey. you really improve Nexus4's worth
[Nexus 4 Original Android Development] mhanis:
Ziddey, i have problem when mounting, they said usb storage is blank. I'm using Y-otg cable. Is it ROM problem?
[Nexus 4 Original Android Development] ziddey:
Thanks but I think you may be speaking too soon. Nothing was changed that would have restored compatibility with proprietary chargers. The only thing changed in this release is the update script. I will try to take a look at the code and see if there is a way to differentiate between an actual proprietary charger and a USB device soon.
[Nexus 4 Original Android Development] sga999:
ziddey, this got appended to another one of my posts, so I don't know if you saw it. I wrote this:

When I click Settings-Storage, I get "Unfortunately, Settings has stopped". I'll try running parts of your script if you want me to.
[Nexus 4 Original Android Development] ziddey:
Don't see a screenshot and am having trouble understanding what you mean. You're saying the USB drive is mounting but is blank? Or is it not mounting at all? It seems to be working fine for me. We're talking about a FAT32 partition? NTFS is not supported natively. Will look into it more tomorrow.
[Nexus 4 Original Android Development] mhanis:
http://db.tt/WjkzlhHS

http://db.tt/ThvG8RTD

http://db.tt/x2zHU1AF
[Nexus 4 Original Android Development] bestgmx:
is there any ways build by own instead buying OTG cable ?
[Nexus 4 Original Android Development] ziddey:
Damn. I'll have to take a better look tomorrow, and test with some different frameworks.

Basically, I compared two compiled modified storage_list.xml files (for different CM builds) in a hex editor and found a few different bytes. I found that the ones responsible for the storage strings were preceded by 08 00 00 01 (with 46 for storage_internal and 48 for storage_usb in the file included in the zip).

So the idea is to then pull the unmodded storage_list.xml and resources.arsc (contains the strings) to determine what to change 46 and 48 to. Assumedly, there is only going to be one 08 00 00 01 sequence, since the unmodified storage_list.xml doesn't have usb storage included, so we can find the proper hex value for storage_internal. Then, we dump all the strings in resources.arsc and find the distance between storage_internal and storage_usb. Adding this value in hex to the proper hex value for storage_internal should get us the value for storage_usb. Swapping these values into the modified xml should fix the strings.

However, I did find a few other bytes that varied between the two modded files. I was really hoping that they weren't critical, which is pretty stupid.. I'm assuming this discrepancy is what's causing your force close. I'll try to see if I can figure out how to properly alter those values tomorrow.
[Nexus 4 Original Android Development] EDV11:
Yep, this is happening to me too

Enviado desde mi Nexus 4
[Nexus 4 Original Android Development] sga999:
ziddey, I'll repeat part of what I said in post #299.

unzip -p framework-res.apk res/xml/storage_list.xml > storage_list.xml

internal=$(od -x storage_list.xml | cut -b 13-72 | tr '\n' ' ' | sed "s/ //g" | grep -o '00080100....' | head -1 | cut -b 11-12)

Those lines will set 'internal' to the offset that is in the backup apk (framework-res.apk.1). So this next compare is incorrect (for my rom):

if [ "$internal" -eq "48" ]; then

That compare won't work for either 48 or 46 because my internal and usb values are 0xe5 and 0xe7. And the high order byte of the offset is 04, not 05 which is in your storage_list.xml, so it seems like patching a single byte is not good enough.

Then since the compare will not be equal to 48, these lines will execute.

tr "\x08\x00\x00\x01\x46" "\x08\x00\x00\x01\x$internal" < res/xml/storage_list.xml > temp.xml

tr "\x08\x00\x00\x01\x48" "\x08\x00\x00\x01\x$usb" < temp.xml > res/xml/storage_list.xml

I think the offsets will now be wrong because you replaced the low-order byte but not the high-order. I'm guessing that causes Settings-Storage to crash.

EDIT: Yes, I patched your 05's to 04's in two places (just with my own tools, i.e. I didn't change your .zip file), and it works fine. So patching both high and low bytes will fix the problem. But I still don't know what your compare to 48 is all about. In your storage_list.xml, the first occurrence of 08000001 is for internal and it's 0x0546, the second is for usb and it's 0x0548. Won't they always occur in that order? If so, I don't see the need for a compare...but I'm sure you have a reason that I don't know about. (I haven't tried to figure out what that internal= line with the cut, sed, grep, etc. actually does).
[Nexus 4 Original Android Development] vikas_toad:
Thanks...

Will be testing and reporting soon
[Nexus 4 Original Android Development] RussianBear:
Mine does that sometimes. Try unplugging the drive and micro usb, then plugging them both again.

Ziddey, I've reverted back to April's build, as the newer one (haven't tried the 8th yet) wasn't properly working with my dash cam recordings. Will test done things out today.

Also, do you know why it doesn't detect the drive right away? Seems like I have to connect/disconnect it a few times before getting any detection.

Edit: my memory card converter is bad, no issues with a different one. Detects right away.
[Nexus 4 Original Android Development] wangtang:
Yes, you are right. After several times it doesn't charge with external battery any more.

I hope you will fix this problem soon.

Thanks ziddey:laugh:
[Nexus 4 Original Android Development] davebuk:
Afraid I am having the storage settings FC as well. I'm running stock firmware if that makes any difference?
[Nexus 4 Original Android Development] ziddey:
Oh wow, I overlooked that byte since it's 05 in all my test files.

Yes, I am unzipping the original storage_list.xml on purpose. I'm trying to extract what you've determined manually to be e5. Then, the original resources.arsc is analyzed to find the "distance" between the strings, storage_internal and storage_usb. In your case, the distance should be 2 since your storage_usb is e7.

As for `if [ "$internal" -eq "48" ]; then`, that's merely a safety check. Since the original value for usb in my xml is 48, if the new internal value is also 48, then the next tr will replace both instances of 48 with $usb. Not really likely anyone would ever run into such an issue, but I was covering my bases there.

Going to include the other byte now. Thanks for looking into it!

Sorry about my lack of testing everyone.
[Nexus 4 Original Android Development] RussianBear:
You're all good, man.I'm surprised none of the devs contacted you about this yet.
[Nexus 4 Original Android Development] sga999:
You're welcome...glad I could test it for you.

That 'internal=' line really blows my mind, and I'm going to try to understand it better (I know very little about all the commands in that line). I'm assuming you might have to cut 4 characters in that last part rather than 2. I look forward to seeing your changes.
[Nexus 4 Original Android Development] ziddey:
Nah, I'm sure there's a far better approach than what I've come up with. I'm about to upload another version to test, but I'm working out one (hopefully) final glitch.

$internal represents the two bytes for storage_internal in the rom's original framework.

od -x storage_list.xml | cut -b 13-72 | tr '\n' ' ' | sed "s/ //g" | grep -o '00080100....' | head -1 | cut -b 9-12

od -x storage_list.xml: hex dump (endianness...)

cut -b 13-72: trim the offset numbers at the beginning of each line

tr '\n' ' ': replace line breaks with spaces

sed "s/ //g": remove all spaces

grep -o '00080100....': find all instances of 00080100.... (. is wildcard, -o to only output 00080100....)

head -1: only want the first occurrence if there are multiple ones for some reason (shouldn't ever be)

cut -b 9-12: trim 00080100, leaving us with the two relevant bytes for storage_internal in the rom's original framework.

Right now, I'm working on an issue with the rare/unlikely event that $internal is something like 04ff. I'm assuming that $usb would then be something like 0501 (given a distance of 2). Otherwise, it seems to be working.