Groups | Search | Server Info | Login | Register

Groups > comp.mobile.android > #153897

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

Cross-posted to 3 groups.

Show all headers | View raw

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

Back to comp.mobile.android | Previous — Previous in thread | Next in thread | Find similar

Thread

PSA: How to mirror Android onto your PC using scrcpy & adb over Wi-Fi Maria Sophia <mariasophia@comprehension.com> - 2026-05-09 21:02 -0600
  Re: PSA: How to mirror Android onto your PC using scrcpy & adb over Wi-Fi Maria Sophia <mariasophia@comprehension.com> - 2026-05-10 20:01 -0600
    Re: PSA: How to mirror Android onto your PC using scrcpy & adb over Wi-Fi Maria Sophia <mariasophia@comprehension.com> - 2026-05-11 20:34 -0600
    Re: PSA: How to mirror Android onto your PC using scrcpy & adb over Wi-Fi "Kerr-Mudd, John" <admin@127.0.0.1> - 2026-05-12 13:00 +0100
      Re: PSA: How to mirror Android onto your PC using scrcpy & adb over Wi-Fi Maria Sophia <mariasophia@comprehension.com> - 2026-05-12 09:15 -0600
      Re: PSA: How to mirror Android onto your PC using scrcpy & adb over Wi-Fi Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-13 04:37 +0000
        Re: PSA: How to mirror Android onto your PC using scrcpy & adb over Wi-Fi Paul <nospam@needed.invalid> - 2026-05-13 05:08 -0400
  Re: PSA: How to mirror Android onto your PC using scrcpy & adb over Wi-Fi Roger Mills <mills37.fslife@gmail.com> - 2026-05-12 12:09 +0100
    Re: PSA: How to mirror Android onto your PC using scrcpy & adb over Wi-Fi Maria Sophia <mariasophia@comprehension.com> - 2026-05-12 09:03 -0600

csiph-web