Related
(I really struggled with where to post this. Although much work and effort went into debugging unique Z5-specific issues, this is based on prior work so I put it here instead of in "original"; also, I would be very surprised if this didn't apply cleanly and work across the entire Z5 family, not just the Compact, but it might not apply beyond the Z5 so it doesn't make sense to put it in the cross-platform forum, which means I had to pick ONE Z5 family forum to post in. I've only tested on Compact, so I guess it goes here for now.)
I am attaching a set of kernel patches that will allow Z5 users to put their phone's USB port into host mode while simultaneously also allowing the phone to take a charge. In this scenario, the USB device(s) connected to the phone are not getting power from the phone like they normally would in a standard "OTG" scenario, but are sharing with the phone whatever power source is being used to charge the phone.
Acknowledgements:
HUGE thanks...
...to @ziddey for his original patch that he developed for the Nexus 4 which was the inspiration behind all of this,
...to @sollapse for being the first to successfully implement ACA support in the DWC3 driver,
...and to @Phoenix Wright for further refining that code
The patches presented here are based largely off of Phoenix Wright's work.
Background:
I used a Nexus 4 for a long time, and grew accustomed to being able to do this with my Nexus thanks to @ziddey's extremely clever hack. (My personal use-case is a phone dock in my car which both charges the phone and connects it to a USB sound card, which in turn is fed into the auxiliary input of my car's stereo head unit.) In fact, the modification ziddey came up with was both so effective and minimally-invasive that the changes were -- until relatively recently -- easy to apply to just about any Snapdragon-based device (even ones with fully-functioning OTG support, which the Nexus 4 didn'thave), since many of them shared a common USB core, and thus also shared drivers.
I was disappointed to discover upon receiving my Z5 Compact that although for some odd reason that venerable old Snapdragon USB driver was enabled in Sony's kernel's build .config, it wasn't actually being used by the hardware...I patched up the kernel, compiled it, flashed it, and the behavior of the USB port didn't change. Turns out all of the more recent Snapdragons use a new USB 3/SuperSpeed-capable core by Synopsys, part of their DesignWare series, and this core uses an entirely different driver called DWC3. And unlike the older driver, this new one does not implement support for so-called USB "accessory charging adapters" or ACAs (typically vendor-proprietary powered USB hubs that do exactly what we want: charge the phone while putting it in host mode), so in-built support for ACAs couldn't be exploited in the DWC3 driver the way that it had been in the old driver.
Fortunately, @sollapse rose to meet the challenge and whipped up some basic ACA support for the DWC3 driver included in the kernel source tree for the OnePlus One. I took what was largely a re-write of this, done by @Phoenix Wright, and essentially ported that version over to the Z5 kernel while also making some other changes and additions along the way.
Use:
Disclaimer: I cannot be held responsible if any harm should come to you or your phone on account of using these software modifications.
This was developed and tested against the Sony copyleft sources for the kernel that shipped with the last release of Lollipop for the Z5 series (32.0.A.6.200). I plan to also work on versions for the Marshmallow and Nougat kernel releases as well, but wanted to start with something as close to what I was porting from as possible and just deal with one variable at a time. Chances are good that very little changed in the USB drivers in later Z5 kernels anyway. I have also to-date only tried to apply this to an otherwise stock Sony source tree, and running on the stock Sony Lollipop ROM.
This isn't how ACAs are strictly meant to work on a device that officially supports them, but when it comes to this patch, to enable or disable "ACA mode", you need to either pass a certain parameter (aca_enable, should be set to 'Y') to the driver (dwc3) at initialization (during boot / on the kernel command line, so 'dwc3.aca_enable=Y'), or toggle the parameter after boot using sysfs (e.g. 'echo N > /sys/module/dwc3/parameters/aca_enable'). For write access to sysfs, you have to be root, so keep that in mind if you have a requirement to be able to toggle this on and off without a reboot.
Enabling ACA mode merely changes the behavior of the driver when the ID pin/pin 5 on the micro-USB cable is grounded (OTG cable), which indicates to the phone that it should switch to host mode. With ACA mode enabled, it basically doesn't engage the USB host voltage bus regulator and instead activates the battery charging circuitry; however, just like "normal" USB host mode, it still requires an actual OTG cable to work, UNLIKE ziddey's original patch. What this means is that if you want to plug, say, a thumb drive into your phone without having to also supply an external power source, you need to set 'aca_enable' back to 'N' first before this will work again.
Sometimes it is not possible to use an OTG cable in certain situations; for example, there is no way I am going to first cut out and then cut open the non-OTG micro-USB plug from my $80 Proclip car mount in order to turn it into a proper OTG cable. For these situations, ziddey's ingenious idea -- borne out of necessity by the broken ID_GND detection on the Nexus 4 -- of triggering host mode based on the type of charging adapter detected by the phone is extremely useful, and so I implemented a similar feature: by additionally setting 'prop_chg_aca_enable' to 'Y', the driver will switch to USB host mode if a so-called "proprietary" charging source is detected (which is apparently what the phone interprets the voltage injected with a USB Y-cable as).
'prop_chg_aca_enable' will have no effect if 'aca_enable' is not also toggled on. I split it out into a separate option, though, because for reasons I haven't had the time to hunt down yet, the charger detection toggle seems (based on extremely limited testing) to make the use of an OTG cable less reliable...sometimes it works, sometimes it engages the host mode but not the battery charger, sometimes it does neither. So if you already use an OTG cable with your particular set-up, I recommend you leave 'prop_chg_aca_enable' off.
Finally, as most of you surely know, the Z5 series (and the Z3+/Z4 before it) introduced a new coverless micro-USB port along with a new requirement that you the user must manually initiate a scan for attached USB gadgets in order for the port to switch over to host mode; presumably they did this so that they could keep the IP68 water ingress protection rating despite the change to a coverless port. Miraculously, when aca_enable is on, because the phone is accepting a charge instead of delivering power in this scenario, there is (in theory) no additional risk from water exposure in this mode and yet you also do NOT need to hit "Detect USB Device" on your phone before you can use the USB device...as long as both external power and a USB device are present on the cable at the moment you plug it in. If you don't have a USB device plugged into your Y-cable, only power, then the device will not be detected later. If you have a need to work around this, you can set 'no_device_timeout_enable' to 'N', which will keep the host controller on-line and engaged for as long as you have a powered OTG cable plugged in.
If you want to *really* live life on the edge, you can also set the 'force_id_polling_on' parameter of the 'qpnp_smbcharger_extension' driver to 'Y' in order to completely disable the need for tapping on "Detect USB Devices" for "normal" OTG mode.
Oh, one more thing I forgot: if you are supplying power through an OTG cable (with ID pin grounded), then you need to set 'dwc3_msm.force_float_on_bsv=N' in order to work around a change Sony made to the driver that causes it to treat powered OTG cables as if they are non-OTG. I don't know why they did this (perhaps just to further reduce the risk of water damage on account of the open port under certain circumstances?), but I added a toggle that bypasses their change.
In summary, here are all of the various driver/module options I have decided to supply to my own kernel at boot time; at a minimum #1 and #4 are mandatory when using a OTG cable and #4 and #5 are mandatory when using a non-OTG cable:
dwc3_msm.force_float_on_bsv=N
(disables Sony "innovation" that prevents a powered OTG cable from switching controller into host mode)
qpnp_smbcharger_extension.force_id_polling_on=Y
(disables the need for "Detect USB Devices" under normal OTG use -- NOTE this could reduce the integrity of the water protection!! Use with caution!)
dwc3.no_device_timeout_enable=N
(disables host mode timeout in the event controller does not detect a device)
dwc3.aca_enable=Y
(enables the new "ACA mode" which allows for the exclusive use of powered OTG cables at the expense of normal OTG use)
dwc3.prop_chg_aca_enable=Y
(additionally allows USB host mode to be triggered by a non-OTG powered Y-cable that also has a USB device attached)
I hope others find this useful, while at the same time I also hope that our USB-C future will eventually end the need for us to dabble in such hackery.
-- Nathan
Nice work! Just to let you know, I made some final changes to the patch before submitting it to SultanXDA there: https://forum.xda-developers.com/showpost.php?p=64784909&postcount=8403 (I think there was an issue with kernel panics in certain circumstances which was fixed by a msleep(), maybe something else too).
Phoenix Wright said:
Nice work! Just to let you know, I made some final changes to the patch before submitting it to SultanXDA there:
Click to expand...
Click to collapse
Thanks! My version of the patch was based off of the final post you made to sollapse's thread, which I'll call your patch #1. I just downloaded the version of the patch you linked to (#2), and diff'd a copy of the Sultan dwc3_otg.c patched with #1 against a copy patched with #2, and this is the only difference I found:
Code:
@@ -1048,6 +1044,11 @@
phy->state = OTG_STATE_A_HOST;
/* Wait, as host must be enabled after power */
if (ID_MODE == ID_A) {
acaenabled = 0;
+ /* If B_SESS_VLD went off already, proceed to enable host */
+ if (test_bit(B_SESS_VLD, &dotg->inputs)) {
+ work = 1;
+ break;
+ }
/* Ensure there's no charger before suspending */
msleep(200);
if (!dotg->ext_xceiv->bsv)
pm_runtime_put_sync(phy->dev);
} else {
...and I had actually added a single line to that 'if' block already that set work=1 indiscriminately (which you can see in my patch). (As I recall, more often than not after hitting the A_IDLE case, there would be no additional external event to trigger the workqueue again after state was set to A_HOST, which meant that OTG_STATE_A_HOST case block would never actually get executed.) It probably would be more correct for me to test for BSV before forcing another workqueue loop, so I'll try making that change and re-testing. I haven't experienced any ill effects in day-to-day use, though.
Is there a reason why you are checking BSV state twice and in two different ways here (checking the B_SESS_VLD bit in dotg.inputs, and also directly checking dotg.ext_xceiv.bsv)? Are you checking dotg.ext_xceiv.bsv directly because there is a chance that dwc3_ext_event_notify() hasn't been called by the transceiver driver yet for some reason to update the state machine inputs? What about simplifying things here down to a single test, like so?:
Code:
phy->state = OTG_STATE_A_HOST;
/* Wait, as host must be enabled after power */
if (ID_MODE == ID_A) {
acaenabled = 0;
/* If B_SESS_VLD went off already, proceed to enable host */
if (test_bit(B_SESS_VLD, &dotg->inputs)) {
work = 1;
break;
} else {
/* Ensure there's no charger before suspending */
msleep(200);
pm_runtime_put_sync(phy->dev);
}
} else {
(or substitute in "if (dotg->ext_xceiv->bsv)" for the call to test_bit() if you think that is more appropriate for some reason?)
Thanks again,
-- Nathan
nlra said:
Thanks! My version of the patch was based off of the final post you made to sollapse's thread, which I'll call your patch #1. I just downloaded the version of the patch you linked to (#2), and diff'd a copy of the Sultan dwc3_otg.c patched with #1 against a copy patched with #2, and this is the only difference I found:
Code:
@@ -1048,6 +1044,11 @@
phy->state = OTG_STATE_A_HOST;
/* Wait, as host must be enabled after power */
if (ID_MODE == ID_A) {
acaenabled = 0;
+ /* If B_SESS_VLD went off already, proceed to enable host */
+ if (test_bit(B_SESS_VLD, &dotg->inputs)) {
+ work = 1;
+ break;
+ }
/* Ensure there's no charger before suspending */
msleep(200);
if (!dotg->ext_xceiv->bsv)
pm_runtime_put_sync(phy->dev);
} else {
...and I had actually added a single line to that 'if' block already that set work=1 indiscriminately (which you can see in my patch). (As I recall, more often than not after hitting the A_IDLE case, there would be no additional external event to trigger the workqueue again after state was set to A_HOST, which meant that OTG_STATE_A_HOST case block would never actually get executed.) It probably would be more correct for me to test for BSV before forcing another workqueue loop, so I'll try making that change and re-testing. I haven't experienced any ill effects in day-to-day use, though.
Is there a reason why you are checking BSV state twice and in two different ways here (checking the B_SESS_VLD bit in dotg.inputs, and also directly checking dotg.ext_xceiv.bsv)? Are you checking dotg.ext_xceiv.bsv directly because there is a chance that dwc3_ext_event_notify() hasn't been called by the transceiver driver yet for some reason to update the state machine inputs? What about simplifying things here down to a single test, like so?:
Code:
phy->state = OTG_STATE_A_HOST;
/* Wait, as host must be enabled after power */
if (ID_MODE == ID_A) {
acaenabled = 0;
/* If B_SESS_VLD went off already, proceed to enable host */
if (test_bit(B_SESS_VLD, &dotg->inputs)) {
work = 1;
break;
} else {
/* Ensure there's no charger before suspending */
msleep(200);
pm_runtime_put_sync(phy->dev);
}
} else {
(or substitute in "if (dotg->ext_xceiv->bsv)" for the call to test_bit() if you think that is more appropriate for some reason?)
Thanks again,
-- Nathan
Click to expand...
Click to collapse
A lot of time has passed, but if I'm not mistaken, on the OPO, in some circumstances (II think if you removed the otg-y cable quickly or something like that), dwc3_ext_event_notify() would be called (to signal that power was removed) after the device was suspended leading to a kernel panic (I did a lot of tests with the "extreme" cases, like removing the cables quickly). So the msleep is to make sure that it didn't happen (in such cases, the device is then suspended by the next invocation of that state machine if I'm not mistaken, in the "case OTG_STATE_A_HOST:", in the part below the "/* Charger has been removed */" comment). So the changes you proposed wouldn't work, as the msleep + direct check are there to tell if the state machine is going to be called again just after that.
Phoenix Wright said:
[...] on the OPO, in some circumstances (II think if you removed the otg-y cable quickly or something like that), dwc3_ext_event_notify() would be called (to signal that power was removed) after the device was suspended leading to a kernel panic (I did a lot of tests with the "extreme" cases, like removing the cables quickly). So the msleep is to make sure that it didn't happen (in such cases, the device is then suspended by the next invocation of that state machine if I'm not mistaken, in the "case OTG_STATE_A_HOST:", in the part below the "/* Charger has been removed */" comment). So the changes you proposed wouldn't work, as the msleep + direct check are there to tell if the state machine is going to be called again just after that.
Click to expand...
Click to collapse
Gotcha, thanks; makes perfect sense. I'm not sure that the same thing is necessarily happening on the Z5...it uses a different battery charge controller than the 1+1 and in fact I ripped out a lot of the 1+1-specific workarounds when preparing my version of the patch. (I still need to do more testing, but in fact I'd say there are some instances where BSV is actually not being detected properly on this platform, which could explain my initial findings...there is a debugfs file exposed where you can check current BSV detection state, but even when phone is getting power it almost always shows "0".)
Nevertheless, I ran some tests:
1. With work=1 set explicitly every time (my addition to your code for my original version of the path), everything with a powered OTG cable and aca_enable=Y worked fine for me.
2. With that removed, it almost never engaged the battery charger, though host mode almost always kicked in.
3. After adding work=1 only if B_SESS_VLD bit was set, working functionality for powered OTG cables was restored (again, as long as my new prop_chg_aca_enable=N).
So I have updated the patch to check for that bit before forcing another workqueue loop, which I believe is "more correct".
Thanks again,
-- Nathan
Hm sorry I gonna sound like a total noob but everyone starts out somewhere. The *.diff file is for a ROM to be compiled? Its not supposed to be flashed with TWRP or such? Or is it just a file to be overwritten in the system files?
Just today I made myself an OTG cable with charging function and was scratching my head why it's not charging.
tarsonis666 said:
Hm sorry I gonna sound like a total noob but everyone starts out somewhere. The *.diff file is for a ROM to be compiled? Its not supposed to be flashed with TWRP or such? Or is it just a file to be overwritten in the system files?
Just today I made myself an OTG cable with charging function and was scratching my head why it's not charging.
Click to expand...
Click to collapse
You are correct, this file is used to patch the kernel (not the ROM) source and then compile the kernel binaries.
Files you flash in TWRP usually end in ".zip" or ".img".
// DevelLevel
Hey. Has anyone compiled a kernel with this patch applied? I'm a total noob when it comes to Linux and I'm really struggling with compiling a kernel, let alone applying patches to it . I would be really grateful if someone could attach a ready kernel image.
Adamell0 said:
Hey. Has anyone compiled a kernel with this patch applied? I'm a total noob when it comes to Linux and I'm really struggling with compiling a kernel, let alone applying patches to it . I would be really grateful if someone could attach a ready kernel image.
Click to expand...
Click to collapse
Sorry, haven't hung out around here in a while...
What specific phone model do you have, and what firmware version are you using? If it is something in the Z5 family (regular/Compact/Premium) and otherwise stock Sony firmware, let me know which model and f/w version and I can probably whip something up.
If it's some other phone model, no guarantees. If Z5 with third-party AOSP-based firmware, also no guarantees but more likely than not may be possible.
nlra said:
Sorry, haven't hung out around here in a while...
What specific phone model do you have, and what firmware version are you using? If it is something in the Z5 family (regular/Compact/Premium) and otherwise stock Sony firmware, let me know which model and f/w version and I can probably whip something up.
If it's some other phone model, no guarantees. If Z5 with third-party AOSP-based firmware, also no guarantees but more likely than not may be possible.
Click to expand...
Click to collapse
Thanks for your response. I have Sony Xperia Z5 Compact model E5823 with Android 7.1.1., kernel version is 3.10.84-perf-g99119bc.
Adamell0 said:
Thanks for your response. I have Sony Xperia Z5 Compact model E5823 with Android 7.1.1., kernel version is 3.10.84-perf-g99119bc.
Click to expand...
Click to collapse
Gotcha; I should be able to help with this, but what I need is the Sony ROM version, not the kernel version. Can I assume that you're running the latest (last) version of 7.1.1 released for the Z5c, 32.4.A.1.54? (At this point I'd be surprised if you were running anything older, but I'm going to be pulling the kernel sources direct from Sony for the firmware version that matches what you're running, which is why I need to be sure. In all likelihood, though, even if you are running slightly older ROM, since you're already on 7.1.1, the odds of a kernel built from the latest sources not working with your ROM are likely slim-to-none.)
And you already have the bootloader unlocked on your Z5c, yes?
EDIT: -g99119bc is what is shown as the suffix on the kernel version from 32.4.A.1.54 in screenshots of "About phone" all over the internet for the Z5 series, so I'm moving forward with this assumption.
nlra said:
Gotcha; I should be able to help with this, but what I need is the Sony ROM version, not the kernel version. Can I assume that you're running the latest (last) version of 7.1.1 released for the Z5c, 32.4.A.1.54? (At this point I'd be surprised if you were running anything older, but I'm going to be pulling the kernel sources direct from Sony for the firmware version that matches what you're running, which is why I need to be sure. In all likelihood, though, even if you are running slightly older ROM, since you're already on 7.1.1, the odds of a kernel built from the latest sources not working with your ROM are likely slim-to-none.)
And you already have the bootloader unlocked on your Z5c, yes?
EDIT: -g99119bc is what is shown as the suffix on the kernel version from 32.4.A.1.54 in screenshots of "About phone" all over the internet for the Z5 series, so I'm moving forward with this assumption.
Click to expand...
Click to collapse
I'm running exactly the version you mentioned: 32.4.A.1.54. As far as unlocking bootloader goes it is still on my "to do" list, but for that I assume that the tutorial on Sony website will suffice.
Adamell0 said:
I'm running exactly the version you mentioned: 32.4.A.1.54. As far as unlocking bootloader goes it is still on my "to do" list, but for that I assume that the tutorial on Sony website will suffice.
Click to expand...
Click to collapse
I would advise you to not just blindly unlock the bootloader on your Z5c if you haven't done so already. Doing so on the Z5c is irreversible and has permanent consequences unless you prepare in advance / take necessary precautions. (Side note: it's because of stuff like this that I've learned to always search and read up on any potential pitfalls when it comes to doing bootloader unlocks on specific models of phones before just jumping right in!!! Sony is not entirely forthcoming in their warnings on their site about what you lose when you unlock!)
The "necessary precautions" involve backing up what is called the TA partition of the phone before unlocking the bootloader. When you unlock the bootloader, the phone zeroes out all of the DRM keys stored in this sector that are unique to your particular phone (not phone model, your specific unit! if you lose them you can never get them back! and you can't take copies of keys from another Z5c and flash them to your phone unless you want a permanent brick that will never power back on again!). So best to back this up beforehand, both so that you have the option of returning to COMPLETE stock in the future if you so desire (re-lock bootloader, etc.), but also so that you can reflash the keys back to TA while retaining the unlocked bootloader, having the best of both worlds.
Unfortunately, this is a bit of a pain to do, admittedly, since TA partition is normally heavily guarded. It's supposed to be impossible to access, but a bug in older firmwares can be exploited to gain access to it even with a locked bootloader. So this means you have to actually downgrade back to Android 6.0 Marshmallow *just temporarily*, long enough to make a backup of the TA partition. After that, you can re-upgrade back to 7.1 Nougat and proceed with bootloader unlock.
If you decide not to go to the trouble, that's fine, but at least you will be making an informed decision in advance, rather than only finding out about what you lost after it's gone, robbing you of choice.
Link to TA backup utility: https://forum.xda-developers.com/t/universal-dirtycow-based-ta-backup-v2.3514236/
To downgrade, you'll need to get yourself a copy of Flashtool and a Sony Z5c Marshmallow ROM file; I can provide links to these in a PM if you want to go down this path. The firmware download is nearly 3 gigs, just FYI.
nlra said:
To downgrade, you'll need to get yourself a copy of Flashtool and a Sony Z5c Marshmallow ROM file; I can provide links to these in a PM if you want to go down this path. The firmware download is nearly 3 gigs, just FYI.
Click to expand...
Click to collapse
Please PM me those links if it's not a problem, while the phone is just one of many laying in my drawers having options is always a good thing .
Adamell0 said:
Please PM me those links if it's not a problem, while the phone is just one of many laying in my drawers having options is always a good thing .
Click to expand...
Click to collapse
Check your PM for links and general overview of how to accomplish downgrade/TA backup/upgrade.
Your kernel is also ready, tested, and attached.
Note that this is just the raw kernel with OTG patches included. If you end up backing your TA partition up, you will want to patch this kernel image with the latest version of rootkernel (which adds additional patches to restore functionality lost after bootloader unlock, but are not patches that require a kernel re-compile) and then flash that version.
Also, just in case it wasn't clear in the original post, these patches do not allow you to seamlessly use both traditional non-powered OTG as well as powered OTG...it's one or the other. Non-powered OTG will stop working, and OTG/host mode will only be possible if a power source is also applied. It is possible to disable the powered OTG mode and revert to regular non-powered mode, but it has to be done with a terminal command, and it will return back to powered-only OTG mode after the phone is rebooted.
You're a power user. Can the Google Pixel 2 keep up? Rate this thread to express how "healthy" the development scene is for the Google Pixel 2. A higher rating indicates available root methods, kernels, and custom ROMs.
Then, drop a comment if you have anything to add!
How in the hell does Google let their devices languish in locked bootloader prison with carriers anymore? Why don't they give us the ability to root the phone if we're developers? You'd think you could just jump right in and unlock your bootloader on the Google Store purchased ones (unlocked ones - not Verizon trash) except they don't provide a cable TO CONNECT TO YOUR PC WTF WHY AM I YELLING
Wartickler said:
How in the hell does Google let their devices languish in locked bootloader prison with carriers anymore? Why don't they give us the ability to root the phone if we're developers? You'd think you could just jump right in and unlock your bootloader on the Google Store purchased ones (unlocked ones - not Verizon trash) except they don't provide a cable TO CONNECT TO YOUR PC WTF WHY AM I YELLING
Click to expand...
Click to collapse
am i missing something? i got my pixel 2 from google store, and unlocked / rooted it easily the same day i received it thanks to awesome members here at XDA
it also included the necessary USB-C cable (and adapter to connect to type A usb ports)
Dev strength
xdaninja said:
it also included the necessary USB-C cable (and adapter to connect to type A usb ports)
Click to expand...
Click to collapse
The cable I got was USB-C to USB-C to plug into the phone and the charging brick. The adapter I got was USB-C male/USB-A female so you could attach it to an old phone and transfer contacts. You telling me you got a cable/adapter that let you connect your new phone to your PC?? I'm even more pissed off if that's the case...poor distribution QA on top of the other issues too?!
Wartickler said:
The cable I got was USB-C to USB-C to plug into the phone and the charging brick. The adapter I got was USB-C male/USB-A female so you could attach it to an old phone and transfer contacts. You telling me you got a cable/adapter that let you connect your new phone to your PC?? I'm even more pissed off if that's the case...poor distribution QA on top of the other issues too?!
Click to expand...
Click to collapse
I received the same as you. I used the cable from my moto z2, not sure how it could have come with anything different than what we received.
Yes Google should have included a USB C to USB A male vs female for sure.
Wartickler said:
The cable I got was USB-C to USB-C to plug into the phone and the charging brick. The adapter I got was USB-C male/USB-A female so you could attach it to an old phone and transfer contacts. You telling me you got a cable/adapter that let you connect your new phone to your PC?? I'm even more pissed off if that's the case...poor distribution QA on top of the other issues too?!
Click to expand...
Click to collapse
So Google is now responsible for you having a PC without the proper connections to plug your phone in?
Or are they responsible for you not being able to order a Micro USB to USB C adapter for a few bucks?
Which one is it I wonder...
kendong2 said:
So Google is now responsible for you having a PC without the proper connections to plug your phone in?
Or are they responsible for you not being able to order a Micro USB to USB C adapter for a few bucks?
Click to expand...
Click to collapse
I really want you to be saying this in a sarcastic tone, but since this is the internet and I can't read tone I'm just going to fly into a rage instead.
Are you seriously suggesting that once the pixel 2 comes out everyone on the planet immediately gained the ability to connect USB-C straight to their computers? Or is it that you are seriously suggesting that it is somehow nonsensical to at least include an extra adapter that mates this new cable type to everyone's existing computer connections? Yes we can purchase a crap-ton of adapters that get us from the phone to the ISS but for the minimal cost of this simple connection type and for the cost I paid I would expect that I would be able to connect my development machine to this device in the exact same fashion I've been able to connect EVERY OTHER DEVICE I'VE EVER HAD. They've all been able to connect to my PC out of the box. This is the first time I've opened a new device box and been at a loss for how to immediately get to working on it. Somehow I believe this was an oversight on the part of Google.
Wartickler said:
I really want you to be saying this in a sarcastic tone, but since this is the internet and I can't read tone I'm just going to fly into a rage instead.
Are you seriously suggesting that once the pixel 2 comes out everyone on the planet immediately gained the ability to connect USB-C straight to their computers? Or is it that you are seriously suggesting that it is somehow nonsensical to at least include an extra adapter that mates this new cable type to everyone's existing computer connections? Yes we can purchase a crap-ton of adapters that get us from the phone to the ISS but for the minimal cost of this simple connection type and for the cost I paid I would expect that I would be able to connect my development machine to this device in the exact same fashion I've been able to connect EVERY OTHER DEVICE I'VE EVER HAD. They've all been able to connect to my PC out of the box. This is the first time I've opened a new device box and been at a loss for how to immediately get to working on it. Somehow I believe this was an oversight on the part of Google.
Click to expand...
Click to collapse
Sure sure. Totally an oversight on the part of Google that you did not check which accessoires come with the phone, totally agree.
BTW, what do you think of the included headset? I think the volume is much too low, I can't hear anything. On the other hand, I never had the cables twisted yet!
kendong2 said:
BTW, what do you think of the included headset? I think the volume is much too low...
Click to expand...
Click to collapse
I... :crying: :silly: ... I'm dead.
My 200 dollar Acer laptop has a USB C port and the provided cable works fine for me. USB C is the modern standard that everyone is moving to. Is it that unreasonable to think that Google would provide cabling for the modern standard that most manufacturers are adopting?
I can't be more happy with this phone.
The only thing I'd improve is to have 4 years of Android updates instead of 3.
In development they will always be on the top because of the open binaries / developers previews etc.
However....I think that over the last years security became a top priority and now a lot of people don't open the boot loader. Even Google disabled android pay when you open it.
And the price is not in favour neither. I think Google needs to release a budget Pixel at lower price...something like 400-450$.
Theres the kernels and some homebrew ROMs.
Feels like this device is hard to work on.
TWRP now fails to decrypt after the February update.
A/B partition seems hard to support so theres no official custom ROMs for Pixel 2.
So far this phone is not what I would recommend for the serial flashers and customizers.
Just a normal phone for normal users.
I see development at Linage, at AICP for our device.
GApps are now available for Android 8.1. Many changes had to be made because of project Treble.
There is development, but for now many ppl look into things on their own and not as collective.
bland.life said:
A/B partition seems hard to support so theres no official custom ROMs for Pixel 2.
Click to expand...
Click to collapse
It's something we came up with at Citibank in about 1989 - update to an unused part of storage. If it works, point whatever is using that part of the firmware at the update and use the place the old version sat as the next update space. The update crashed right on the last byte? No problem. You haven't repointed to it, so it's just empty space until the next try. Better than a bricked phone because the battery died right at the end of an update. It's about time Google caught up to the late 80s. (Yes, that was sarcasm.) My only complaint is the SD card - I have to carry an adapter around with me, and keep the SD card and adapter in my pocket. 128GB internal and 256GB external would have been nice. (I already have about 50GB used, and that's with only one TWRP backup.)
Maybe it's time to flash a kernel with speed adjustment, although it seems to be idling around 430-450MHz.
Hey!
This is my first thread I've ever created, so don't be too harsh on me
As far as I know, the new Android 10 includes a so called "desktop mode". So you can connect a compatible device via USB to an external screen. I think thats pretty cool and samsung already implemented this idea from the S8 upwards with Samsung Dex.
I understand that this needs USB 3.1, but the Motorola G7 Plus only has USB 2.0!
According to the datasheet of the build-in Snapdragon 636 processor, it does support USB 3.1!
So here comes the question: Is it possible to "activate" the required functionality in order to use the desktop mode?
So like changing a few things inside the root files (Like you can activate for example OTG)?
If not, is the hardware build that way, that it just doesn't have the data-lines?
And also, if all of that doesn't work, you surely saw such USB 2.0 to HDMI adapter, which do work on older computers, but do they might work with Android 10 connected to otg?
It would be really cool if something of that might work.
Thanks for your response!
TimTheDev said:
Hey!
This is my first thread I've ever created, so don't be too harsh on me
As far as I know, the new Android 10 includes a so called "desktop mode". So you can connect a compatible device via USB to an external screen. I think thats pretty cool and samsung already implemented this idea from the S8 upwards with Samsung Dex.
I understand that this needs USB 3.1, but the Motorola G7 Plus only has USB 2.0!
According to the datasheet of the build-in Snapdragon 636 processor, it does support USB 3.1!
So here comes the question: Is it possible to "activate" the required functionality in order to use the desktop mode?
So like changing a few things inside the root files (Like you can activate for example OTG)?
If not, is the hardware build that way, that it just doesn't have the data-lines?
And also, if all of that doesn't work, you surely saw such USB 2.0 to HDMI adapter, which do work on older computers, but do they might work with Android 10 connected to otg?
It would be really cool if something of that might work.
Thanks for your response!
Click to expand...
Click to collapse
Unfortunately this device does not support MHL so usb to HDMI dongles do not work. Apparently moto hasn't supported MHL for some time .
digitaljeff said:
Unfortunately this device does not support MHL so usb to HDMI dongles do not work. Apparently moto hasn't supported MHL for some time .
Click to expand...
Click to collapse
Thanks for your answer. But I knew that before. I am trying to finde some "workarounds" for this, because I do really like this phone!
Found a solution
So, after a bit of research, I found a solution to add external screens to any OTG compatible Android phone!
There are so called "DisplayLink adapters" and those seem to be compatible with any Android phone that supports OTG.
After installing the official app "DisplayLink Presenter", you should be able to get everything working.
I din't tested it yet, but I hope that this will help someone in the future.
I've tried a USB-C hub with HDMI as well as a screen with a USB-C connector, which both work on my laptop. I don't expect anything to work, but did anyone try the USB-HDMI converters that were reported to work on F1 a while ago?
Having a low-latency video output would be a dream come true.
It dont work, i saw a video review before buying the poco X3 .... only lg, samsung, huawei flagships do that...
Sadly I wanted to mirror Snes and PSone emulators to TV with a USB-C/HDMI output dongle and play with my Dualshock 4.. but not with poco X3
Was wondering if the DisplayLink adapters work: https://forum.xda-developers.com/showpost.php?p=80746715&postcount=53 - as I know the other cables don't.
The standard is called MHL, and I don't think poco x3 supports it :/
NHL =no
USB c audio adapter /dac =no
YES, video out is possible on the POCOPHONE X3 NFC! )
Since it's my first post, I was prevented from posting outside links. Whenever there was a link, you will now read 'google it'
You read it right, fellers. :angel:
DisplayLink is the name of the magic. Let's break it down:
1. Acquire any of the many DisplayLink enabled dongles or desktop versions. Products at the link:
google it
2. Acquire a USB-A to USB-C OTG adapter like this one:
google it
3. Download and install (no-root required!) the android app "DisplayLink Presenter" in your Poco X3 from:
google it
4. If you've already installed the app and already got your dongle
- plug the adapter's USB-A female end to the dongle's USB_A male.
-plug the cable from your HDMI monitor/TV to the dongle.
-plug the adapter's USB-C end to your X3.
5. Give it a coupla seconds ... Magic! There pops up the same image on both your phone and your TV/monitor! It's a window from the DisplayLink Presenter app. Plug and play, no need to open the app. Close it out, turn your phone sideways and enjoy the picture. Hook up a BT keyboard/mouse and you're good to go.
6. YouTube, Netflix, Vimeo all run with no problem. Games work, apps work, PowerPoint presentations work. Word works. Browsing works.
7. Desktop mode doesn't work. Charging simultaneously doesn't work (with this set up, but there is workaround...). Audio embedded in PP presentation may glitch at times.
That's it, me frends. Enjoy your POCOPHONE X3 NFC mirrored image, with no lag, in the full glory of a large monitor/TV, to the delight of your eyes!
P.S.: And for those interested in going wireless, check this one out:
google Hyper Mirror
Peace.
Just an explanation for you, I've done a truck load of research? on this, while I was deciding what phone to buy.
USB Type C have different types just as USBs do. So USBs went from 1 to 3; USB Type C have both 2 and 3, then thunderbolt, etc.
Essentially, what Xiaomi have done, is use the USB2 internals within the newer Type C connectors. So we get OTG but no video out.
This also means we don't have any more than 480Mbps data transfer speed.
USB3 is 5GB/s, USB3.1 is 10GB/s.
They are actually call them USB2 Type C/USB3 Type C. I honestly don't think a lot of places selling adapters, cables, etc. actually understand what they are selling as they label them all as Type C.
The solution to this, as above, is Displaylink, or equivalent, which I believe are still all Displaylink underneath.
Soooo what you end up with is a nightmare, a lot of people might think it's not worth the headache and carting around everything, especially if you are prone to losing things.
The simplest way to put it is that you need a USB2 Type C OTG cable, which connects from Poco X3 to an adapter (Displaylink/Wavelink/etc.), and a HDMI cable, which connects from the adapter to monitor.
There are other options, depending on how much you want to spend.
The only thing I haven't been able to figure out 100% is whether or not the adaptors can take the lowly USB2 480mbps speed and convert it into 4k. My brain says no way, but due to not finding any people that have used the more expensive adapters, I don't have an actual answer.
If any of this is wrong, let me know, it's only what I've been able to figure out on my own, and funny enough, it's actually more difficult to find than you'd think. Especially when you didn't know what you are starting off from.
Okay so I've found an 'in the meantime' solution that might suit some people. I haven't worked out all the kinks yet, but it does work.
You might have heard of Genymotion, well it's not that. Genymotion who produce Genymotion do a range of applications for android and one of them is called scrcpy.
If you look up 'genymotion scrcpy' the github link should be the first result.
A lot of people seem to dismiss it as not worth even using, I have no idea why, it's very easy to setup and use. It comes up quite often in XDA as well.
You install it on your PC, connect your phone, and then a mirror of your phone comes up on your desktop. It appears to be fully functional, I downloaded a game of the sorts that I play, and it worked despite the rending issues. I've also played some video that I recorded, no issues at all playing that.
I do have some rendering issues but I'm pretty sure that's an individual thing, I use MXLinux, and I know I have a java issue (as in personal setup, not MXLinux), the errors that are displayed in the terminal as it was running all relate to java.
I am still working through all of the possible solutions with the 'video out' converters and adapters, hopefully before too long, I'll be able to actually show you a working example, as I know that there aren't any out there at present, or not that I've seen anyway. And seeing it working is completely different to someone just saying that they have it working in a comment, with no offer of proof that they have.
I use an app called "vysor" on all my android phones. All you need to do is just download the pc app and follow instructions. Basically you just plug your phone to pc like you will transfer data or charge it. And usb debugging must be enabled. When you enable usb debugging and connect your phone to pc, Vysor will install latest android app and that is all. Sounds will come from the phone so i suggest you use a pair of speakers or earphones.
gsser said:
I use an app called "vysor" on all my android phones. All you need to do is just download the pc app and follow instructions. Basically you just plug your phone to pc like you will transfer data or charge it. And usb debugging must be enabled. When you enable usb debugging and connect your phone to pc, Vysor will install latest android app and that is all. Sounds will come from the phone so i suggest you use a pair of speakers or earphones.
Click to expand...
Click to collapse
That's the same as MirrorLink used by cheap anything Java that advertises screen mirroring. Used it on a low end Linux machine via browser, lag and distortion, worse than screencast for me
Edit: the native Linux appimage worked well enough,but is limited to 1 Mbps and the full version is rather pricey 40USD. I'm the end,you still need a machine running, not just a single cable solution. Might be worth it for some, maybe try a month first to see how well it works for you
And vysor does not have input options from the machine to android, (MirrorLink does I think) so you'll need extra BT peripherals for input.
edit2: have to enable USB input emulation in Dev settings for KB/M to work. And a free alternative exists, its called "scrcpy", with identical functionality, no need for App on android. Vysor is just an overpriced GUI for a free app imho, probably targeted at Apple users
What about a USB to VGA cable? Will it work?
Guys, bad news?
This is not yet supported on Poco X3. But there was a problem when I updated the software on this device. My X3 immediately went dark after that, I was quite alarmed because this is my new phone when I won the competition to play stickman fighter with my friends. What should I do now?
Hello everyone,
Im trying to connect my phone (redmi note 10 pro MFF edition (europe)) with a rj45 cable to avoid wifi signal in my house. In my old samsung its connected directly, but with the xiaomi nothing happen, I dont find the option for ethernet neither.
Did any one try this ? Its just a software problem ( MIUI system) or more hardware. Since im still waiting to unlock my bootloader, Cannot try with a custom room to see if the problem persevere.
Thank you all for the feedback
any feedback ?
I do not have the Redmi Note 10 Pro, but some general questions:
1. Did you disable Wifi and enable Airplane mode?
2. Which adapter did you use?
I disabled the wifi and enable the airplane mode, but nothing change.
I use this adapter https://www.amazon.fr/gp/product/B07CR79XM7/ref=ppx_yo_dt_b_asin_title_o07_s00?ie=UTF8&psc=1, work as charm on my old samsung.
The issue is that in miui we dont have any ethernet interface to configurate the dhcp or other stuff.
The issue is that in miui we dont have any ethernet interface to configurate the dhcp or other stuff.
Click to expand...
Click to collapse
I thought the issue was that you had no connection. I have no idea about the MiUI. So if the issue is that you get no connection these might be some obstacles:
I found a discussion (for the Redmi Note 8/Pro/8T) on the mi forum (https://c.mi.com/thread-3003395-3-1.html) where a person describes that he thinks the issue might be the chipset. Your ethernet adapter uses the 8152B chipset, but he says that it seems like you would need an adapter with a AX88179 chipset. An ethernet adapter that supports the AX88179 chipset is the https://plugable.com/products/usbc-e1000/.
Another user in the same discussion says that it works for him with the j5create adapter (https://c.mi.com/oc/thread-3003395-1-0.html), although he states that nothing indicates that he is connected. (For some reason I didn't find any information on their website about what chipset their adapter uses, so we don't know for sure if the chipset is the issue.)
But let me re-emphasize that I do not know whether that really is the issue or whether it works with one of these adapter. So be aware of that.
If the ethernet is still not working the issue might be that the kernel wasn't configured for Ethernet over USB. You can find a lot more information about these things here: https://android.stackexchange.com/questions/225643/how-to-make-ethernet-work-on-android-over-otg
If you actually decide to buy a new ethernet adapter, please let me/us know whether it worked.
Thank you Ponyo71 for this intersting feedback,
I think its myabe a doubel raison : first hardware and secone software.
I get the same issue with my mibox 3, she dont regonis all the usb rj45 adapter, only the ugreen worked and another 2$ adapter that I get from discountshop.
the software raison is the only part that we can modify easly, I know that xiaomi reduce alot of option from android to optimise the battery or to not show that the chipset used is very powerfull for some specific utilisation. nad since the chipset used for wifi and BT probably is the same that manage the ethernet.
The xiaomi coast cheap, Its's normal that they bypass some non essentiel used option. More, i think if it's a option htaht only less than 5% of people use, they will supress it from miui to save and manage the battery.
Anyway, Now im back to samsung, no more xiaomi for me
Seems like it really is the chipset, since the ugreen adapter uses the AX88179 chipset. And apparently it works with your MiBox 3. So I guess it really is your ethernet adapter and not the software, although I can’t say for sure.
In this case, we will get at least the ethernet configuration but disabled. in MIUI we dont have any ethernet parameter. The software has a part of the problem
Yeah, seems like MiUI has no configuration options for Ethernet.