-
Notifications
You must be signed in to change notification settings - Fork 184
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable ADB with GadgetFS devices #290
Merged
samueldr
merged 14 commits into
mobile-nixos:master
from
samueldr-wip:feature/gadgetfs-adb
Jan 31, 2021
Merged
Enable ADB with GadgetFS devices #290
samueldr
merged 14 commits into
mobile-nixos:master
from
samueldr-wip:feature/gadgetfs-adb
Jan 31, 2021
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- It was running too late. - Wasn't actually using `shellOnFail` config
The service and mount points are more of an implementation detail of the GadgetFS handling library and not an implementation detail of the init library. In turn, this means that we are decoupling this from the init, follow-up on the next commit...
(Though it may require fiddling with udev perms)
FunctionFS on GadgetFS requires this to happen in order: - (1) preparing the gadget - (2) preparing the function - (3) mounting the functionfs - (4) starting the daemon - (5) enabling the device Doing any of these steps in the wrong order *will* fail. You cannot mount functionfs if the function name hasn't been allocated yet. You cannot start the daemon without functionfs being mounted. You cannot enable the device without the daemon running on the USB endpoints. This is why the GadgetFS stuff here *has* to know about mounting the filesystem and starting the daemon. In fact, the generic library to be written to handle USB gadget mode **will** have to have that knowledge! The added TODOs are to be done when extracting as a standalone library.
Also warn if it could not be enabled.
Also warn if it could not be enabled.
samueldr
force-pushed
the
feature/gadgetfs-adb
branch
from
January 28, 2021 03:17
d1196dd
to
6baec7a
Compare
Hmm... the use of "more proper" USB identifiers is problematic. Pine doesn't have any (AFAIK). Which in turn means we're squatting into a well-known PID area. In turn, this means that there is no udev rules that properly configure the endpoints for things like ADB. Which in turn means that |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It happens that, with time, I learned enough to finally be able to tackle this problem.
With these changes,
adb
in stage-1 (and I expect the system) works with GadgetFS devices:While it doesn't seem needed, after all we have
rndis
working just fine, it is. See, sometimesrndis
is a big unknown variable that is hard to correctly guess the proper solution for. With these changes you can get insight into the device usingadb
, and gather the required knowledge to setuprndis
, if desired.Tested on
android_usb
)Cannot test on, due to hardware issues: