Subject: Re: PSA: How to mirror Android onto your PC using scrcpy & adb over Wi-Fi

On 10/05/2026 04:02, Maria Sophia wrote:

PSA:
How to mirror modern Android onto your PC using scrcpy & adb over Wi-Fi (Works on Android 11 and up)

Windows or Linux, this mirrors your phone on your PC monitor two feet tall. (The keyboard, mouse, clipboard, speakers all mirror Android over Wi-Fi).

1. Connect your phone to the LAN
2. Longpress the Wireless Debugging tile at the top of your homescreen
3. Note the "IP address & Port", for example
a. IP address (e.g., 192.168.1.2)
b. Connection Port (e.g., 46003)
3. Tap "Pair device with pairing code" to get another port & pairing code
a. IP address (e.g., 192.168.1.2)
b. Pairing Port (e.g., 40005)
c. Pairing code (e.g., 450824)
4. Pair & connect:
adb pair 192.168.1.2:40005 450824
adb connect 192.168.1.2:46003
5. Run scrcpy without leaving an unusable console behind:
Windows: scrcpy-noconsole.vbs (see below)
Linux: mirror (see below)

6. That mirrors Android on your monitor while using the PC mouse, keyboard,
speakers & clipboard to control the device full-height on your monitor.

For Linux, this mirrors Android thereafter without the console locking up:
alias mirror ='scrcpy --keyboard=sdk --always-on-top &'

This is the default Windows scrcpy-noconsole.vbs shipped with scrcpy.
strCommand = "cmd /c scrcpy.exe"
For Each Arg In WScript.Arguments
strCommand = strCommand & " """ & replace(Arg, """", """""""""") & """"
Next
CreateObject("Wscript.Shell").Run strCommand, 0, false

I modified it slightly to reduce one step when using the Android keyboard.
' strCommand = "cmd /c scrcpy.exe"
strCommand = "cmd /c scrcpy.exe --keyboard=sdk --always-on-top"
For Each Arg In WScript.Arguments
strCommand = strCommand & " """ & replace(Arg, """", """""""""") & """"
Next
CreateObject("Wscript.Shell").Run strCommand, 0, false

There is minor one-time setup, such as turning on Developer Options in the phone to enable "USB debugging" & "Wireless debugging" & adding the wireless-debugging tile which you do only once in the life of the phone.

Note once you have paired a device, you usually only need the adb connect command in the future, especially with a static IP address.
adb connect
scrcpy-noconsole.vbs (for Windows)
mirror (for Linux

There are, of course, a billion options, but this is a quickie for all.
And there is the old-school way of using adb connect 192.168.1.2:5555

Help - I'm lost!

I can get as far as #3 and can get IP address, port and pairing code

But I don't understand #4 - Pair and connect
Where are the adb pair and adb connect commands entered - on the phone
(if so where?) or on the PC (if so where). My PC doesn't seem to
understand the command 'adb' when entered at a command prompt!

--
Cheers,
Roger

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: PSA: How to mirror Android onto your PC using scrcpy & adb over Wi-Fi

On Sun, 10 May 2026 20:01:23 -0600
Maria Sophia <mariasophia@comprehension.com> wrote:

Maria Sophia wrote:

There are, of course, a billion options, but this is a quickie for all.
And there is the old-school way of using adb connect 192.168.1.2:5555

If you're tapping on your phone while at your desk, you're not efficient.

There are three ways to connect your phone to your PC to control it from
the PC (& which can makes the phone as tall & as wide as your monitor is).

1. Wi-Fi
2. USB
3. Hybrid USB + Wi-Fi

We covered the Wi-Fi steps prior, which work only on Android 11+.

The USB method is the simplest (and most reliable) overall.
a. Connect the phone to the PC via USB

a.1. find the USB driver. discover it needs a newer os than you have.
cry.
discover it keeps trying to load something that it can't find
when you try to charge the phone from your PC EVERY TIME
DNAMHIKT.

b. adb devices
c. scrcpy --always-on-top --full-screen --stay-awake --keyboard=sdk

For all Android versions, including older Android, there's a half-and-half
a. Connect the phone to the PC via USB
b. adb tcpip 5555
c. adb connect 192.168.1.2:5555
d. scrcpy --always-on-top --full-screen --stay-awake --keyboard=sdk

In my humblest of opinions, if you're at your PC, there's no reason to
touch the phone in order to do whatever it is that you want to do with it.

Note there are a billion scrcpy options, so those are just examples.

--
Bah, and indeed Humbug.

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: PSA: How to mirror Android onto your PC using scrcpy & adb over Wi-Fi

On Tue, 12 May 2026 13:00:47 +0100, Kerr-Mudd, John wrote:

a.1. find the USB driver. discover it needs a newer os than you have.
cry.

Doesn?t your OS have a proper USB stack built-in?

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: PSA: How to mirror Android onto your PC using scrcpy & adb over Wi-Fi

On Wed, 5/13/2026 12:37 AM, Lawrence D?Oliveiro wrote:

On Tue, 12 May 2026 13:00:47 +0100, Kerr-Mudd, John wrote:

a.1. find the USB driver. discover it needs a newer os than you have.
cry.

Doesn?t your OS have a proper USB stack built-in?

Does every USB device follow standards ?
The answer is NO. There is at least one device
family that "just did what it felt like".

USB also has two code points for "custom". It's
always had that. If such a device shows up, then
the driver must be included by the company selling it.

The other drivers are Class drivers and include a
set of quirks. Both Linux and Windows do that. Gather up all
the crappy, close to standard devices, any behavioral
quirks are captured in code. If your eTron or Fresco host
misbehaves, there is code for that. You will notice for
some of the SmartPhones, the manufacturer didn't even
get their hands dirty, and MCCI wrote the driver under
contract. MCCI even wrote the driver for some of the
Asmedia chips (various USB hosts, who knows, even the
USB4 stuff might be like that now).

The smartphone is a USB OTG interface, capable of acting
as a host or as a peripheral. What I've been able to
ascertain by looking at the drivers, is they look
like they might be for that purpose, for dealing with
an OTG device. It's a framework driver of some sort
(a wrapper to be used by a developer to package their goods),
and likely in WinXP era, those drivers were there
for a reason, now they might be getting close to being
Intel-style "null" drivers (add a text string to your
Device Manager display).

A person using UsbTreeView may be able to look
at the config space of their SmartPhone and tell
you more. I don't have a SmartPhone so cannot comment
further on what is in there.

https://www.uwe-sieber.de/usbtreeview_e.html

To give some idea of the <cough> status of Microsoft Windows,
Microsoft rewrote the Bluetooth stack from scratch. This
was at least partially intended to flush third party Bluetooth
stacks out of the system. For example, TCP/IP over Bluetooth,
might not have been working two or three years ago, but it works
now (you can do ICS over it). You no longer have to use the
FTP-like protocol of Fsquirt to transfer a file (which is a
cross-platform thing). I can have a 75KB/sec networking stack
over Bluetooth now. That's an example of a protocol stack that
has grown over a fair number of years. The progress was
relatively slow.

At the current time, Microsoft is "containerizing" drivers,
the OS is three dimensional, you can have drivers crashing
now, you can't even tell it is happening (there is no
"kernel panic"). Only by looking at a log can you see
"something has a problem". RealTek NICs are handled this
way, and NVidia video drivers too.

Since the NVidia driver was claimed to cause 30% of the BSODs,
that's why it was one of the first to be containerized. And that number,
might be from 10-15 years ago, rather than being the number for
today.

At the same time, driver installers which are exploit surfaces,
are being pruned out by Windows Defender. Defender for example,
told me to remove an Asus AISuite driver (which would be an older one,
and it was only there because the Asus installer did not remove it
on package removal). I removed that by hand no problem. That has the
equivalent of a "GiveIO.sys" type driver, I thought that had changed
to an ACPI method at one point, which was supposed to improve the safety of it. A recent "victim" was the "pssmount driver" of Macrium, which got
identified as a risk (that driver should be used when Macrium mounts
an .mrimg file for random access of the files inside).

Two of the print driver ecosystems are frameworks now. Manufacturers
"fit" their printers into the framework, it's supposed to make
it easier to handle new printers, without "300MB of a zillion
custom .dll and .sys", with malformed registry entries inserted
by HP. Some of that has been cleaned up.

There are multiple fronts in the driver space, and people
are still doing useful work on the subject.

Paul


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: PSA: How to mirror Android onto your PC using scrcpy & adb over Wi-Fi

On Wed, 13 May 2026 05:08:35 -0400
Paul <nospam@needed.invalid> wrote:

On Wed, 5/13/2026 12:37 AM, Lawrence D?Oliveiro wrote:

On Tue, 12 May 2026 13:00:47 +0100, Kerr-Mudd, John wrote:

a.1. find the USB driver. discover it needs a newer os than you have.
cry.

Doesn?t your OS have a proper USB stack built-in?

Does every USB device follow standards ?
The answer is NO. There is at least one device
family that "just did what it felt like".

USB also has two code points for "custom". It's
always had that. If such a device shows up, then
the driver must be included by the company selling it.

The other drivers are Class drivers and include a
set of quirks. Both Linux and Windows do that. Gather up all
the crappy, close to standard devices, any behavioral
quirks are captured in code. If your eTron or Fresco host
misbehaves, there is code for that. You will notice for
some of the SmartPhones, the manufacturer didn't even
get their hands dirty, and MCCI wrote the driver under
contract. MCCI even wrote the driver for some of the
Asmedia chips (various USB hosts, who knows, even the
USB4 stuff might be like that now).

The smartphone is a USB OTG interface, capable of acting
as a host or as a peripheral. What I've been able to
ascertain by looking at the drivers, is they look
like they might be for that purpose, for dealing with
an OTG device. It's a framework driver of some sort
(a wrapper to be used by a developer to package their goods),
and likely in WinXP era, those drivers were there
for a reason, now they might be getting close to being
Intel-style "null" drivers (add a text string to your
Device Manager display).

A person using UsbTreeView may be able to look
at the config space of their SmartPhone and tell
you more. I don't have a SmartPhone so cannot comment
further on what is in there.

https://www.uwe-sieber.de/usbtreeview_e.html

Thanks, Paul
I get

+++++++++++++++++ Device Information ++++++++++++++++++
Device Description : CDC Abstract Control Model (ACM)
Kernel Name (PDO) : \Device\0000009a
Device ID : USB\VID_04E8&PID_6860&MODEM\6&18FC6CAE&3&0001 Hardware IDs : USB\Vid_04e8&Pid_6860&Rev_0400&Modem USB \Vid_04e8&Pid_6860&Modem USB\SAMSUNG_MOBILE&Modem USB\SAMSUNG_MOBILE&MI_01 USB\Vid_04E8&Pid_6860&MI_01 USB
\Vid_04E8&Pid_6860&Class_02&SubClass_02&Prot_01 USB \SAMSUNG_MOBILE&Class_02&SubClass_02&Prot_01 Driver KeyName : - Legacy BusType : PNPBus Class : Modem Class
GUID : {4D36E96D-E325-11CE-BFC1-08002BE10318} (GUID_DEVCLASS_MODEM) Enumerator : USB Location
Info : - Address : 2 Manufacturer
Info : - Capabilities : 0x00 (-)
Status : 0x01802400 (DN_HAS_PROBLEM, DN_DISABLEABLE, DN_NT_ENUMERATOR, DN_NT_DRIVER) Problem Code : 1 (CM_PROB_NOT_CONFIGURED) EnhancedPowerMgmtEnabled : 0
Power State : D3 (supported: D0, D3, wake from D0, wake from
D3)

with a yellow ! ("The required section was not found in the INF)
clicking "reinstall driver" gets me back to the start

also

+++++++++++++++++ Device Information ++++++++++++++++++
Device Description : SAMSUNG Mobile MTP Device
Device Path 1 : \\? \USB#Vid_04e8&Pid_6860&MS_COMP_MTP&SAMSUNG_Android#6&18fc6cae&3&0000# {14480d3f-7a47-4a75-aaef-b14f56397153} Device Path 2 : \\? \USB#Vid_04e8&Pid_6860&MS_COMP_MTP&SAMSUNG_Android#6&18fc6cae&3&0000# {6ac27878-a6fa-4155-ba85-f98f491d4f33} (GUID_DEVINTERFACE_WPD) Device Path
3 : \\? \USB#Vid_04e8&Pid_6860&MS_COMP_MTP&SAMSUNG_Android#6&18fc6cae&3&0000# {f33fdc04-d1ac-4e8e-9a30-19bbd4b108ae} (GUID_DEVINTERFACE_WPD_AUDIO)
Kernel Name : \Device\0000009c Device ID : USB \VID_04E8&PID_6860&MS_COMP_MTP&SAMSUNG_ANDROID\6&18FC6CAE&3&0000 Hardware
IDs : USB
\Vid_04e8&Pid_6860&Rev_0400&MS_COMP_MTP&SAMSUNG_Android USB \Vid_04e8&Pid_6860&MS_COMP_MTP&SAMSUNG_Android USB \SAMSUNG_MOBILE&MS_COMP_MTP&SAMSUNG_Android USB\SAMSUNG_MOBILE&MI_00 USB \Vid_04E8&Pid_6860&MI_00 USB
\Vid_04E8&Pid_6860&Class_06&SubClass_01&Prot_01 USB \SAMSUNG_MOBILE&Class_06&SubClass_01&Prot_01 Driver KeyName : {EEC5AD98-8080-425F-922A-DABF3DE3F69A}\0000 (GUID_DEVCLASS_WPD)
Driver : System32\Drivers\wpdusb.sys (Version:
5.2.3790.3646 Date: 2004-09-22 Company: Microsoft Corporation) Driver
Inf : C:\WINDOWS\inf\oem72.inf Legacy BusType :
PNPBus Class : WPD Class GUID : {EEC5AD98-8080-425F-922A-DABF3DE3F69A} (GUID_DEVCLASS_WPD)
Service : WpdUsb Enumerator : USB Location
Info : - Address : 2 Manufacturer
Info : SAMSUNG Electronics Co., Ltd. Capabilities :
0x84 (Removable, SurpriseRemovalOK) Status : 0x0180600A (DN_DRIVER_LOADED, DN_STARTED, DN_DISABLEABLE, DN_REMOVABLE,
DN_NT_ENUMERATOR, DN_NT_DRIVER) EnhancedPowerMgmtEnabled : 0 Power
State : D0 (supported: D0, D3, wake from D0, wake from D3)


Which sort of implies it's doing something, but I don't get to view the
files on the mobile from the Windows (XP) Explorer.

NB FU to XP group only.


--
Bah, and indeed Humbug.

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: PSA: How to mirror Android onto your PC using scrcpy & adb over Wi-Fi

On Wed, 13 May 2026 05:08:35 -0400, Paul wrote:

On Wed, 5/13/2026 12:37 AM, Lawrence D?Oliveiro wrote:

On Tue, 12 May 2026 13:00:47 +0100, Kerr-Mudd, John wrote:

a.1. find the USB driver. discover it needs a newer os than you have.
cry.

Doesn?t your OS have a proper USB stack built-in?

Does every USB device follow standards ? The answer is NO. There is
at least one device family that "just did what it felt like".

Still, we are talking about Android phones. When I was first learning
about Android development over a decade ago, I discovered that
Microsoft Windows needs a special USB driver to connect the developer
tools to an Android phone, while Linux does not.

It appears that is still true today.

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: PSA: How to mirror Android onto your PC using scrcpy & adb over Wi-Fi

Lawrence D?Oliveiro wrote on 5/13/2026 4:23 PM:

On Wed, 13 May 2026 05:08:35 -0400, Paul wrote:

On Wed, 5/13/2026 12:37 AM, Lawrence D?Oliveiro wrote:

On Tue, 12 May 2026 13:00:47 +0100, Kerr-Mudd, John wrote:

a.1. find the USB driver. discover it needs a newer os than you have.
cry.

Doesn?t your OS have a proper USB stack built-in?

Does every USB device follow standards ? The answer is NO. There is
at least one device family that "just did what it felt like".

Still, we are talking about Android phones. When I was first learning
about Android development over a decade ago, I discovered that
Microsoft Windows needs a special USB driver to connect the developer
tools to an Android phone, while Linux does not.

It appears that is still true today.

Yes. Linux is absolutely perfect for 99.999% of all people.

It should be the default operating system on all devices capable or
running it.


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: PSA: How to mirror Android onto your PC using scrcpy & adb over Wi-Fi

On Wed, 5/13/2026 5:23 PM, Lawrence D?Oliveiro wrote:

On Wed, 13 May 2026 05:08:35 -0400, Paul wrote:

On Wed, 5/13/2026 12:37 AM, Lawrence D?Oliveiro wrote:

On Tue, 12 May 2026 13:00:47 +0100, Kerr-Mudd, John wrote:

a.1. find the USB driver. discover it needs a newer os than you have.
cry.

Doesn?t your OS have a proper USB stack built-in?

Does every USB device follow standards ? The answer is NO. There is
at least one device family that "just did what it felt like".

Still, we are talking about Android phones. When I was first learning
about Android development over a decade ago, I discovered that
Microsoft Windows needs a special USB driver to connect the developer
tools to an Android phone, while Linux does not.

It appears that is still true today.

In the WinXP era, the MTP driver "arrived" with a certain version
of Windows Media Player. You could only get the WMP 12 or whatever
it was, by running a "Genuine Check" before the download would start.
Since, even today, I still don't have any MTP hardware here,
I am not able to check any of these details. My digital camera
is USB Mass Storage, and switches to dumb mode during a file dump.

Today, they don't do that. WMP is called WMP Legacy now, and if I
have a Midi file to play, WMP Legacy plays it. And as far as I know,
no modern downloads are gated by a "Genuine Check" any more.

We would need to find an article about how the stack is constructed
for such things. Notice that the enthusiast sites, the staff writers
just aren't the same as they used to be.

You'd be better off using an AI to hunt for the details, if you
were actually interested in the answer. The feedback I get most
of the time, is people don't like me pasting in AI material
(as if it would bite them or something).

*******

Here is the answer, generated on the Big Machine (CPU, no GPU for inference). This is the first real query, not done on CoPilot. Machine is air-gapped
during run, answer comes over on a USB stick.

The "Too Long" "Didn't Read" is this. The phone declares itself
as Class 0xFF, and only the (custom) Android SDK and adb bus driver
can solve the 0xFF layer. Microsoft is under no requirement to be including
a "convenience function" for ANYONES custom USB hardware. Once you go custom, you ship a driver for each and every OS you hope to support. The rest of it seems for the most part to be Class drivers. And/Or, that WinUSB framework thing. Which might well be in-box by now, but in a WinXP era would
have to be shipped by the phone maker (the license would allow them
to ship the framework driver, on their dime in terms of downloads).
And in the WinXP era, that's different than the MTP driver.
The MTP driver (which is not an MTPfs and does not offer a drive
letter in File Explorer) would now be a Class driver.

******* OpenAI answer (some 58GB or so model) *******

Below is a "from-the-ground-up" description of the whole Windows side of an Android?-->?PC ADB connection, together with the matching pieces that live on the phone.
I break it into three layers:

| Layer | What you see on the PC (Windows) | What lives on the Android device |
|-------|--------------------------------------------------------------------------|------------------------------------------------------------------|
| 1 | USB **host controller** driver (EHCI/UHCI/XHCI) + generic USB hub driver | USB **gadget controller** (dwc2, DWC3, etc.) in the kernel |
| 2 | Windows **USB bus driver stack** -? usbport.sys , usbhub.sys ,
and the **function-specific client driver** ( winusb.sys ) | Android **USB composite framework** ( configfs / android_usb.c ) |
that builds a *composite* USB device made of several functions
(MTP, RNDIS, ADB, ...) |
| 3 | User?mode **ADB transport**
( adb.exe , adb.exe --> adb.dll --> WinUSB API) | Android **ADB function** ( function_adb.c ) that implements |
the vendor?specific USB interface and forwards packets
to the adbd daemon |

Below is a step-by-step walk-through of each layer, the exact descriptors that are exchanged, and the driver files that Windows loads.

## (1) USB Host Controller & Hub (Windows kernel)

| Component | File / Driver | Role |
|-----------------------------------------------|----------------------------------------------------------------|---------------------------------------------------|
| **Host controller** (EHCI/UHCI/XHCI) | usbport.sys (generic), plus vendor?specific mini-port driver
( ehci.sys , uhci.sys , xusb.sys ) | Implements the PCI/PCIe host-controller interface |
and talks to the physical USB port. |
| **Root hub** | Part of the same mini-port driver | Exposes a virtual hub (port?0) that
Windows enumerates as "USB Root Hub". |
| **External hubs** (if you plug through a hub) | usbhub.sys | Manages downstream ports,
forwards enumeration requests. |

When you connect the phone, the host controller detects a new device on one of its ports and notifies
the USB bus driver ( usbport.sys ). The bus driver creates a **device object** for the phone
(e.g., USB\VID_18D1&PID_4EE7 ) and starts the enumeration process.

---
## (2) Windows USB Bus Driver Stack + Function-Specific Client

### 2.1 Enumeration - Descriptors that Android presents

Android phones expose a **composite** device. The first configuration descriptor contains several interfaces;
each interface has its own class/subclass/protocol fields.

Typical descriptors for a phone that supports *MTP* and *ADB* (the exact numbers vary by OEM, but
the pattern is the same):

| Interface | bInterfaceClass | bInterfaceSubClass | bInterfaceProtocol | Typical Usage |
|------------------|----------------------------|----------------------------|--------------------|------------------------------------|
| MTP / PTP | 0x06 (Imaging) | 0x01 (Still Image Capture) | 0x01 (PTP) | File transfer via Windows Explorer |
| RNDIS (optional) | 0xEF (Miscellaneous) | 0x02 (Common Class) | 0x01 (RNDIS) | Ethernet-over-USB |
| **ADB** | **0xFF (Vendor-Specific)** | **0x42** | **0x1** | Debug bridge |

The ADB interface is the only one that matters for adb.exe . It uses:

* **Two bulk endpoints** - EP?IN (device --> host) and EP?OUT (host --> device).
*Typical endpoint numbers*: 0x01 (OUT), 0x81 (IN).
* **MaxPacketSize**: 512?bytes for full?speed, 1024?bytes for high?speed.

Because the class is 0xFF , Windows does **not** have a built?in driver that will bind automatically.
Instead the Android SDK ships an INF file ( android_winusb.inf ) that tells Windows to associate
this interface with the generic **WinUSB** client driver.

### 2.2 Driver binding on Windows

1. **INF file** - android_winusb.inf (installed by the "Google USB Driver" package).

%SingleAdbInterface% = WINUSB, USB\VID_18D1&PID_4EE7&MI_01

The INF matches on the vendor ID ( 0x18D1 for Google?owned devices; OEMs use their own VID) and the interface number (MI_XX).

2. **Client driver** - winusb.sys .
WinUSB is a generic "function-client" driver that exposes the bulk endpoints to user mode
through the **WinUSB API** ( WinUsb_* functions).

3. **Device stack after binding**

+---------------------------+
| User-mode ADB client |
| (adb.exe --> adb.dll) |
+------------+--------------+
|
v
+---------------------------+
| WinUSB client driver |
| winusb.sys |
+------------+--------------+
|
v
+---------------------------+
| USB bus driver stack |
| usbhub.sys, usbport.sys |
+------------+--------------+
|
v
+---------------------------+
| Host-controller mini-port|
| (ehci/uhci/xhci) |
+---------------------------+

When the INF is installed, Windows creates a **device interface** of
class GUID {88BAE032-5A81-49F0-BC3D-A4FF138216D6} (the WinUSB "Device Interface").
adb.exe opens this interface with CreateFile("\\\\.\\usb#vid_18d1&pid_4ee7#...")
and then calls WinUsb_Initialize , WinUsb_ReadPipe , WinUsb_WritePipe .

### 2.3 Optional "Composite?driver" (for MTP/PTP)

If you also want Windows Explorer to see the phone as a media device, the same composite device contains an **MTP** interface whose class/subclass/protocol are recognized
by the built-in **Windows Portable Devices (WPD)** driver ( wpdusb.sys ). That driver binds
in parallel with WinUSB; both drivers share the same physical USB device but own different interfaces.

---
## (3) User?mode ADB Transport on Windows

| Component | File / Library | What it does |
|-----------------------------|------------------------------------|---------------------------------------------------------------|
| adb.exe (client) | Part of Android SDK platform-tools | Parses command line, opens a **transport** to the device. |
| adb.dll (or built-in code) | Linked into adb.exe | Implements the *ADB protocol* on top of the WinUSB I/O calls. |
| WinUsb_* API | winusb.sys + setupapi.dll | Sends/receives raw USB bulk packets. |

**Protocol flow**

1. **Connect** - adb.exe opens the WinUSB handle, then sends an *ADB "host-connect"* packet (0x4e 0x58 ...) on the OUT bulk pipe.
2. **Handshake** - The device replies with a *"device-online"* banner ( "OKAY" + version).
3. **Command packets** - Each ADB command is framed as: <len(4)> <command> .
The payload (e.g., shell:logcat ) travels over the bulk pipes in both directions.
4. **Multiplexing** - When multiple devices are attached, each gets its own WinUSB handle;
adb.exe enumerates them via the device interface GUID.

If you run adb devices , the client asks the WinUSB driver for the list of opened interfaces and prints their serial numbers (which the phone provides through the *ADB function*).

---
## Android?side Stack - How the Phone Presents that Interface

| Layer | Kernel component | What it does |
|--------------------------------|------------------------------------------|-----------------------------------------------------|
| **a. USB Gadget controller** | dwc2 or dwc3 driver (e.g., dwc3.0 ) | Exposes a *USB device* on the physical connector;
registers as usb_gadget . |
| **b. Composite framework** | configfs
( /sys/kernel/config/usb_gadget/... )
+ android_usb.c | Builds a **composite gadget** with several functions
(MTP, RNDIS, ADB). Each function is represented by a
directory under /config/ and gets its own
interface number. |
| **c. ADB function** | function_adb.c ( adb.c ) | Registers a **vendor?specific USB function**:
class?0xFF, subclass?0x42, protocol?0x01;
creates two bulk endpoints (maxpacket 512/1024).
It implements the *USB endpoint callbacks* that copy
data between the host?s bulk pipe and an
internal kernel FIFO. |
| **d. Userspace daemon** | adbd (in /system/bin/adbd ) | Listens on a kernel socket ( /dev/android_adb )
created by the ADB function; when WinUSB writes data,
the function driver pushes it into this socket, where
adbd reads it, parses the ADB protocol, and spawns
services (shell, logcat, sync, etc.) |
| **e. Optional mode switching** | "PTP", "MTP", "RNDIS", "Charging only" | The Android UI ( Settings --> Developer options
--> USB configuration ) writes to
/sys/class/android_usb/android0/functions to change
the list of active functions. When you select
*"ADB only"* the composite contains just the
ADB function; when you select *"MTP + ADB"* both
interfaces are present, etc. |

### How the modes appear on Windows

| Android UI selection | Interfaces exported |
|----------------------|---------------------------------------------------------------------------------------|
| **Charging only** | No USB functions --> Windows sees a simple USB Device (unknown); no driver installed. |
| **MTP** | Imaging interface (class?0x06). Windows loads wpdusb.sys . |
| **PTP** | Same as MTP, different subclass/protocol. |
| **RNDIS** | Miscellaneous class; Windows loads the RNDIS driver ( rndismp.sys ). |
| **ADB only** | Single vendor-specific interface --> WinUSB via android_winusb.inf . |
| **MTP + ADB**,
**RNDIS + ADB**,
etc. | Composite: multiple interfaces, each bound to
its appropriate client driver (WPD, RNDIS, WinUSB). |

When the function list changes, the kernel's USB gadget core sends a *"configuration change"* event down
to the host; Windows re-enumerates the device and may load/unload drivers accordingly. This is why you
sometimes see "Device disconnecting..." in Device Manager when you switch the phone's USB mode.

---
## TL;DR ? The complete driver stack (Windows side)

+----------------------------------------------------------------+
| User-mode ADB client (adb.exe) |
| ÀÄ WinUSB API (WinUsb_*) --> winusb.sys | +-------------------+--------------------------------------------+
|
v +----------------------------------------------------------------+
| USB Bus Driver Stack |
| usbhub.sys <-- usbport.sys (EHCI/UHCI/XHCI mini-port driver) | +-------------------+--------------------------------------------+
|
v +----------------------------------------------------------------+
| Host Controller hardware (PCIe EHCI / XHCI) | +----------------------------------------------------------------+

Device object created by the bus driver:
USB\VID_18D1&PID_4EE7&MI_01 <-- matches android_winusb.inf --> binds to winusb.sys


And on the phone:

dwc3 (USB gadget controller)
ÀÄ configfs composite framework
ÃÄ function_adb (class 0xFF, subclass 0x42, protocol 0x01)
³ ÀÄ bulk EP IN/OUT --> kernel FIFO --> /dev/android_adb socket
ÃÄ function_mtp ...
ÀÄ function_rndis ...
adbd daemon <-- reads/writes from /dev/android_adb and implements the ADB protocol

That is the precise technical picture of how an Android phone presents
an **ADB** interface to a Windows PC, what drivers are loaded on each
side, and how the different USB "modes" are realised by adding or
removing functions in the composite gadget.

******* END: OpenAI answer (some 58GB or so model) *******

Runtime, about four minutes or so. Indicator at the bottom
of the window said "Low reasoning", which might be why the
answer came back quickly. The machine might not be big enough
for any other flavor or reasoning :-)

Paul

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: PSA: How to mirror Android onto your PC using scrcpy & adb over Wi-Fi

On Wed, 13 May 2026 22:53:58 -0400, Paul wrote:

On Wed, 5/13/2026 5:23 PM, Lawrence D?Oliveiro wrote:

On Wed, 13 May 2026 05:08:35 -0400, Paul wrote:

On Wed, 5/13/2026 12:37 AM, Lawrence D?Oliveiro wrote:

On Tue, 12 May 2026 13:00:47 +0100, Kerr-Mudd, John wrote:

a.1. find the USB driver. discover it needs a newer os than you
have. cry.

Doesn?t your OS have a proper USB stack built-in?

Does every USB device follow standards ? The answer is NO. There
is at least one device family that "just did what it felt like".

Still, we are talking about Android phones. When I was first
learning about Android development over a decade ago, I discovered
that Microsoft Windows needs a special USB driver to connect the
developer tools to an Android phone, while Linux does not.

It appears that is still true today.

In the WinXP era, the MTP driver "arrived" with a certain version of
Windows Media Player.

This is not about ?the WinXP era?, nor about MTP.

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: PSA: How to mirror Android onto your PC using scrcpy & adb over Wi-Fi

On Thu, 5/14/2026 6:39 PM, Lawrence D?Oliveiro wrote:

On Wed, 13 May 2026 22:53:58 -0400, Paul wrote:

On Wed, 5/13/2026 5:23 PM, Lawrence D?Oliveiro wrote:

On Wed, 13 May 2026 05:08:35 -0400, Paul wrote:

On Wed, 5/13/2026 12:37 AM, Lawrence D?Oliveiro wrote:

On Tue, 12 May 2026 13:00:47 +0100, Kerr-Mudd, John wrote:

a.1. find the USB driver. discover it needs a newer os than you
have. cry.

Doesn?t your OS have a proper USB stack built-in?

Does every USB device follow standards ? The answer is NO. There
is at least one device family that "just did what it felt like".

Still, we are talking about Android phones. When I was first
learning about Android development over a decade ago, I discovered
that Microsoft Windows needs a special USB driver to connect the
developer tools to an Android phone, while Linux does not.

It appears that is still true today.

In the WinXP era, the MTP driver "arrived" with a certain version of
Windows Media Player.

This is not about ?the WinXP era?, nor about MTP.

That's an example of the perversion of driver availability.

It doesn't work like that today. MTP is not handled that way today.
You can plug an MTP device (like a camera), into a USB port and
copy pictures from it, over MTP.

And the config space reporting 0xFF class is CUSTOM,
which is why Microsoft does not provide a Class driver,
because the device has no Class.

If the manufacturers submit their driver to WHQL and
the driver passes inspection, then it can be served
from catalog.update.microsoft.com .

But as near as I can determine, the "adb" level of the
protocol stack, is enabled by the SDK that is available.
And that's how the 0XFF stage is satisfied. The other
levels, the modem or rndis levels of the composite device,
those can be satisfied by either an in-box driver or
via a catalog.update.microsoft.com driver.

Paul

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: PSA: How to mirror Android onto your PC using scrcpy & adb over Wi-Fi

Lawrence D?Oliveiro <ldo@nz.invalid> wrote:

On Wed, 13 May 2026 05:08:35 -0400, Paul wrote:

On Wed, 5/13/2026 12:37 AM, Lawrence D?Oliveiro wrote:

On Tue, 12 May 2026 13:00:47 +0100, Kerr-Mudd, John wrote:

a.1. find the USB driver. discover it needs a newer os than you have.
cry.

Doesn?t your OS have a proper USB stack built-in?

John was (implicitly) talking about Windows *XP*! See the
'Followup-To: alt.comp.os.windows-xp' in his May 13 response.

Does every USB device follow standards ? The answer is NO. There is
at least one device family that "just did what it felt like".

Still, we are talking about Android phones. When I was first learning
about Android development over a decade ago, I discovered that
Microsoft Windows needs a special USB driver to connect the developer
tools to an Android phone, while Linux does not.

It appears that is still true today.

Nope, it isn't! While it isn't "over a decade ago", I did some adb
work in June 2019 on Windows 8.1 and I didn't need "a special USB
driver".

(My notes specifically say that I did not install the device drivers
which were part of the "15 seconds ADB Installer" package (<https://xdaforums.com/t/official-tool-windows-adb-fastboot-and-drivers-15-seconds-adb-installer-v1-4-3.2588979/>)).

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: PSA: How to mirror Android onto your PC using scrcpy & adb over Wi-Fi

On Fri, 5/15/2026 11:48 AM, Frank Slootweg wrote:

Lawrence D?Oliveiro <ldo@nz.invalid> wrote:

On Wed, 13 May 2026 05:08:35 -0400, Paul wrote:

On Wed, 5/13/2026 12:37 AM, Lawrence D?Oliveiro wrote:

On Tue, 12 May 2026 13:00:47 +0100, Kerr-Mudd, John wrote:

a.1. find the USB driver. discover it needs a newer os than you have. >>>>> cry.

Doesn?t your OS have a proper USB stack built-in?

John was (implicitly) talking about Windows *XP*! See the
'Followup-To: alt.comp.os.windows-xp' in his May 13 response.

Does every USB device follow standards ? The answer is NO. There is
at least one device family that "just did what it felt like".

Still, we are talking about Android phones. When I was first learning
about Android development over a decade ago, I discovered that
Microsoft Windows needs a special USB driver to connect the developer
tools to an Android phone, while Linux does not.

It appears that is still true today.

Nope, it isn't! While it isn't "over a decade ago", I did some adb
work in June 2019 on Windows 8.1 and I didn't need "a special USB
driver".

(My notes specifically say that I did not install the device drivers
which were part of the "15 seconds ADB Installer" package (<https://xdaforums.com/t/official-tool-windows-adb-fastboot-and-drivers-15-seconds-adb-installer-v1-4-3.2588979/>)).

A person doing this work, should be able to examine their Device Manager entries, and at least make a start at determining what "drivers" are present.
I don't have the kit here, to work up a demo.

Paul

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: PSA: How to mirror Android onto your PC using scrcpy & adb over Wi-Fi

On Sun, 17 May 2026 11:13:16 -0600, Maria Sophia wrote:

Yet, to bring it back, all I had to do was put it back, since system
packages usually can't be fully removed in an unrootable USA
Samsung.

It?s easy enough to back up the .apk files before messing around.

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)