# How Devices Connect (USB, PCIe, GPUs & Peripherals)
> How the outside world and expansion cards plug into a computer: the USB host/device model, the PCIe highway inside the case, and how GPUs and everyday peripherals present themselves to the system.
---
# How Devices Connect (USB, PCIe, GPUs & Peripherals)
You've plugged in a thousand USB sticks, slotted a graphics card into a motherboard, or stared at a
device that *should* work and quietly didn't. Most of us treat the ports on a machine as magic holes:
push the connector in, hope a light comes on. When it works, great. When it doesn't - "device not
recognized," a GPU the system swears isn't there, a webcam that's invisible - you've got nothing to
reason with.
This guide gives you something to reason with. There are really only two ways the outside world reaches
the brain of a computer: a slow, friendly, universal door (USB) for the things you plug and unplug all
day, and a fast, internal highway (PCIe) for the heavy hardware that lives inside the case. Once you can
see those two paths - and the little translator (the *driver*) that sits at the end of each - every port,
slot, and "why won't this work" stops being mysterious.
## How to read this
- **Here to fix one thing?** If a device isn't being detected, start with [Phase 1: USB & the Host/Device Model](01-usb-and-the-host-device-model.md) - detection and drivers live there. If you're choosing a slot for a card, jump to [Phase 2: PCIe](02-pcie-the-internal-highway.md).
- **Want it to finally make sense?** Read in order. Phase 1 builds the mental model (host, device, enumeration, driver) that the later phases reuse.
## The phases
1. **[USB & the Host/Device Model](01-usb-and-the-host-device-model.md)** - the universal port: one *host* (the computer) in charge of many *devices*, how plugging something in leads to it being detected and a driver loaded, hubs and daisy-chaining, and the genuinely confusing USB naming and USB-C situation.
2. **[PCIe - the High-Speed Internal Highway](02-pcie-the-internal-highway.md)** - the expansion bus inside the case: *lanes* as parallel data paths, the slots on the motherboard, and what plugs in (GPUs, NVMe SSDs, network cards). Why lane count and generation matter.
3. **[GPUs & Peripherals](03-gpus-and-peripherals.md)** - why a GPU exists (massively parallel work: graphics, and now ML), how it connects and gets fed data, and a short tour of how everyday peripherals - keyboard, mouse, display, webcam - present themselves to the system.
> This is the *physical/electrical* side of how parts talk to each other. The story of how data actually
> travels between the CPU, RAM, and these buses lives in [How Data Moves Inside a Machine](/guides/how-data-moves-inside-a-machine);
> the software layer that turns "a device exists" into "an app can use it" is covered in
> [What an Operating System Is](/guides/what-an-operating-system-is).
---
# USB & the Host/Device Model
USB is the port you've used most and understood least - by design, it asks nothing of you. Until
something *doesn't* appear ("USB device not recognized," a drive that mounts on one machine and not
another) and the friendliness turns into a black box. The whole standard rests on one lopsided
relationship and one little ceremony; see both, and USB stops surprising you.
## The one big idea: a host in charge of devices
USB is not a connection between equals - it's one boss and its workers. The boss is the **host**, almost
always the computer (more precisely, a chip in it called the *host controller*). Everything you plug in
is a **device**: keyboard, flash drive, webcam. The host starts every conversation; devices only ever
answer.
π **Terminology.** A *device* is sometimes called a *peripheral*. The "B" in USB literally stands for
"Bus" - a shared road the host directs traffic on; the *host controller* is the chip that runs it.
This is why you can't normally plug two laptops together with a plain USB-A cable and have them talk -
both think they're the host, and a USB conversation needs exactly one. It's also why a device does
nothing until a host gives it power and starts asking questions: devices are patient and dumb on
purpose; the intelligence lives on the host side.
```mermaid
flowchart TD
Host["THE HOST
(computer + host controller)"]
Host -->|"the bus (a shared road)"| Kbd["keyboard"]
Host -->|"the bus (a shared road)"| Drive["USB drive"]
Host -->|"the bus (a shared road)"| Cam["webcam"]
```
## What happens when you plug something in (enumeration)
The ceremony between "you pushed the connector in" and "the thing works" is **enumeration** - the host
noticing a new device, then interviewing it. The sequence:
1. **Detection.** Electrically, the host notices a device on the port (a voltage on the data lines
changes). This is the "bong" sound or the tray-icon flash.
2. **Reset and address.** The host resets the device to a known state and assigns it a number (an
*address*) so it can be told apart from everything else on the bus.
3. **The interview (descriptors).** The host asks the device to describe itself. The device sends back
**descriptors** - small data structures that say "I am vendor `0x05ac`, product `0x024f`, and I behave
like a *keyboard*." (Those vendor/product IDs are how the system knows *exactly* what you plugged in.)
4. **Driver match.** Using that description, the operating system finds and loads the matching **driver** -
the translator that knows how to talk to this kind of device. Now an app can use it.
π **Terminology.** *Device class* = a standard category (keyboard, mass storage, audio) that lets the OS
use a generic driver instead of one specific to that exact model.
On Linux you can watch enumeration live. Plug in a flash drive and check the kernel log:
```console
$ sudo dmesg --follow
[ 8842.1] usb 1-2: new high-speed USB device number 7 using xhci_hcd
[ 8842.3] usb 1-2: New USB device found, idVendor=0781, idProduct=5567
[ 8842.3] usb 1-2: Product: SanDisk Cruzer Blade
[ 8842.4] usb-storage 1-2:1.0: USB Mass Storage device detected
[ 8842.7] sd 6:0:0:0: [sdb] 30031872 512-byte logical blocks
```
*What just happened:* the whole ceremony in five lines. The host (`xhci_hcd`, the host controller driver)
gave the device a number (`7`), read its descriptors (`idVendor`, `idProduct`, the product name),
recognized the *mass storage* class, loaded the `usb-storage` driver, and the drive showed up as a disk
(`sdb`). "USB device not recognized" is this exact sequence failing partway - usually at the interview or
the driver-match step.
β οΈ **Gotcha - "not recognized" is rarely the cable's fault, but sometimes it is.** Enumeration needs the
*data* lines, not only power. A charge-only cable (very common among cheap cables and phone chargers)
skips or under-builds the data wires: the device charges but never enumerates - it looks dead. If a
device powers on but is never detected, swapping to a known-good data cable is a real first move, not
superstition.
When a device "doesn't work," you now have a sequence to point at. Does it get power (light on)? Then
detection's fine - suspect the interview or driver. Detected on one computer but not another? The
hardware's fine - it's a missing or broken driver on the second machine.
## Hubs and daisy-chaining: one port becomes many
A **hub** splits one upstream port into several downstream ports: plug four things into a hub and the
host sees all four. Hubs nest - a port on your laptop feeds a hub, a port on
*that* hub feeds another - which is what "daisy-chaining" means. The host still addresses and interviews
every device individually, however deep in the tree it sits. Many things you don't think of as hubs *are*
hubs internally - a monitor with USB ports on the back, a keyboard with a passthrough port.
```mermaid
flowchart TD
Host["HOST"]
Hub1["hub"]
Hub2["hub"]
Host --> Hub1
Hub1 --> Mouse["mouse"]
Hub1 --> Kbd["keyboard"]
Hub1 --> Printer["printer"]
Hub1 --> Hub2
Hub2 --> Drive["drive"]
Hub2 --> Cam["webcam"]
```
β οΈ **Gotcha - power is shared, and it's the usual reason a chain "gets flaky."** A port supplies limited
power, and an *unpowered* (bus-powered) hub splits that one budget among everything hanging off it. Plug
a power-hungry device - a portable hard drive, some webcams - into an unpowered hub already running a few
things, and it may enumerate intermittently, disconnect under load, or never spin up. The fix is a
*powered* hub (one with its own wall adapter). Nesting depth also has limits, but you'll hit a power
problem long before that.
"It worked when it was the only thing plugged in" and "it disconnects when I copy big files" are classic
shared-power symptoms, not broken devices.
## The genuinely confusing part: USB naming and USB-C
This confuses *everybody*, because the names mix up two unrelated questions:
- **What shape is the connector?** The physical plug: **USB-A** (the classic flat rectangle that only
goes in one way after three tries), **USB-B** and **Micro-USB** (older, on printers and small devices),
and **USB-C** (the small reversible oval).
- **How fast can it move data, and what can it carry?** The *protocol / version* - USB 2.0, USB 3.x, and
so on.
The trap is assuming the shape tells you the speed. **It does not.** *USB-C is a connector - a plug
shape, not a speed.* It might run slow USB 2.0 underneath, or a fast protocol, or an entirely different
one. "It's USB-C" tells you what the plug looks like, nothing more.
The version names are a committee-made mess. The same generation of speed has been labeled with
different "USB 3.x" names at different points; later branding shifted toward marketing names like
**SuperSpeed USB** with a stated number ("SuperSpeed USB 5Gbps" or "10Gbps"). Upshot: **the version
number on the box is unreliable** - the meaningful number is the advertised data rate, the "Gbps"
figure, not the "3.x" label.
β οΈ **Gotcha - and this is the one that bites.** A USB-C port can hide any of several protocols, so two
ports that *look identical* can behave completely differently. A USB-C port might carry:
- plain USB data (slow or fast),
- **DisplayPort** video (the same port drives a monitor - "DP Alt Mode"),
- **Thunderbolt** (a faster protocol that uses the USB-C connector),
- **power delivery** (USB-PD) to charge a laptop.
β¦and a given port may support some and not others - why one USB-C port on a laptop drives an external
display and its identical-looking neighbor doesn't, or one charges the laptop and another won't. The plug
shape promised nothing; the *port's* capabilities are what matter.
How to actually tell: look for the icon next to the port (a display symbol means video out; a
lightning/Thunderbolt bolt means Thunderbolt; an "SS" or a number means the faster data rate) or check
the spec sheet - when in doubt, the only source you can trust.
## Recap
1. **One host, many devices.** The host (your computer) starts every conversation, supplies power, and
addresses each device. Devices only answer.
2. **Enumeration is the plug-in ceremony.** Detect β reset and address β interview (descriptors) β match a
driver. "Not recognized" is this sequence failing partway, and a charge-only cable is a real cause.
3. **Hubs split one port into many** and nest freely, but they share *one* power budget - flakiness under
load usually means you want a powered hub.
4. **Connector β speed.** USB-C is a plug shape; the version/protocol is separate, and identical-looking
USB-C ports can carry different things (data, video, Thunderbolt, power). Check the icon or spec, not
the shape.
Next we go *inside* the case, where the heavy hardware lives - and where the connection model flips from
"slow and universal" to "fast and direct."
---
# PCIe - the High-Speed Internal Highway
USB isn't trying to be the fastest road in the building. Inside the case, a graphics card or an NVMe SSD
moves enormous amounts of data to and from the CPU and memory, *constantly*, with as little delay as
possible. That road is **PCIe** - the highway the serious hardware
bolts onto. Two ideas explain every slot, spec line, and "will this card run at full speed" question:
**lanes** and **generations**.
> βοΈ This phase is about the *physical bus*. For the bigger picture of how the CPU, RAM, and these buses
> shuttle data between each other, see [How Data Moves Inside a Machine](/guides/how-data-moves-inside-a-machine).
## The mental model: PCIe is a highway measured in lanes
PCIe (PCI Express) is a bus - wires connecting expansion hardware to the rest of the system. Its defining
idea is the **lane**: one independent path for data, a tiny pair of wires for sending and another for
receiving, running at the same time (full-duplex). Many lanes can run *side by side* to the same device,
all carrying data in parallel.
π **Terminology.** The notation **x1, x4, x8, x16** ("by one," "by sixteen") = **how many lanes** a slot
or device uses. More lanes = more parallel paths = more total bandwidth.
It's a freeway: sixteen lanes (x16) move sixteen times what one lane (x1) does.
```text
x1 β 1 lane - a small device (Wi-Fi, sound card)
x4 ββββ 4 lanes - typical NVMe SSD
x8 ββββββββ 8 lanes - a second GPU, fast network card
x16 ββββββββββββββββ 16 lanes - the main graphics card slot
each "β" is one lane = one independent parallel path to the device.
more lanes side by side = more total bandwidth at once.
```
Why this design exists: older expansion buses were *shared* - every card took turns on one common set of
wires, fighting for bandwidth. PCIe gives each device its own dedicated lanes straight toward the
system - a *point-to-point* connection, not a shared party line - so each device gets predictable,
private bandwidth.
## The slots on the motherboard
PCIe slots are the long connectors expansion cards push into, sized to match lane counts: a short slot
for x1, a long one for x16. A card's gold edge-connector ("the fingers") slides into a slot of matching
or larger size.
```text
ββββββββββββββββββββββββββββ MOTHERBOARD ββββββββββββββββββββββββββββ
β β
β [CPU] βββββββββββββββ x16 slot βββββββββββββββ β GPU β
β β
β ββββββββ x4 slot ββββββββ β NVMe/card β
β β
β ββ x1 ββ β Wi-Fi/sound β
β β
β (M.2 slots elsewhere on the board also run on PCIe lanes βNVMe) β
ββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
```
A detail that trips people up: *physical* slot size and *electrical* lane count can differ -
"**x16 physical, x4 electrical**" means the slot is long enough for a big card but only four lanes are
actually wired. The card fits and works; it just gets four lanes, not sixteen. Manufacturers do this to
fit more long slots on a board than they have lanes to fully wire.
β οΈ **Gotcha - your card may be running at fewer lanes than you think.** A CPU and chipset only have so many
lanes to hand out. Populate several slots and M.2 drives at once and the board may quietly *reduce* lanes
to some of them - for example, dropping the main x16 GPU slot to x8 when a second card or certain M.2
slots are in use. The card still works, just on a narrower road than the slot's size implies. The
motherboard manual's lane-allocation table is the only reliable place this is spelled out.
## What plugs in here
PCIe is where the bandwidth-hungry hardware lives. The three you'll meet most:
- **Graphics cards (GPUs)** - the headline tenant of the x16 slot. They move massive amounts of data to
and from the CPU and memory, which is exactly why they get the widest slot. (Their whole story is the
[next phase](03-gpus-and-peripherals.md).)
- **NVMe SSDs** - fast storage on PCIe lanes (usually x4), typically through a small **M.2** slot.
Talking directly to the PCIe highway instead of the older, slower disk interface is the entire reason
NVMe is so much faster than older SSDs - full story in
[Storage: HDD, SSD & NVMe](/guides/storage-hdd-ssd-nvme).
- **Network and other cards** - fast wired network adapters, Wi-Fi, sound, capture cards, add-in
controllers. They need only a lane or two, so they live in the narrow x1/x4 slots.
## Why lane count *and* generation both matter
Bandwidth on PCIe is the product of **two** numbers. **Lane count** is the width of the road.
**Generation** is the speed of each lane: PCIe comes in numbered generations - Gen 3, Gen 4, Gen 5, and
so on - and each new generation roughly doubles the data rate *of a single lane*. A Gen 4 lane carries
about twice a Gen 3 lane, Gen 5 about twice Gen 4. (Doubling per generation is the consistent rule; the
exact rates are published by the spec.)
π **Terminology.** **Total bandwidth β per-lane speed (generation) Γ number of lanes.**
The practical consequence: fewer fast lanes can equal more slow lanes. An x4 link on one generation
carries roughly what an x8 link carried on the generation before - same total, half the lanes. That's why
an NVMe drive on Gen 4 x4 can be genuinely fast despite "only" four lanes: each lane is moving a lot.
β οΈ **Gotcha - the connection runs at the *slower* end's terms.** PCIe negotiates down to whatever both
sides can do. Put a Gen 5 card in a Gen 3 slot and it works - at Gen 3 speeds. A card built for x16
dropped into an x8 link runs at x8. Nothing breaks and you usually get no error; you just silently get
less than the card is capable of. When a new GPU or SSD "feels slower than the reviews," a generation or
lane mismatch is a prime suspect - and most operating systems can report the link's actual negotiated
generation and width, so check rather than guess.
"Is this slot fast enough for this card?" is now two questions: enough *lanes*, and a recent enough
*generation*? And "why is my fast new drive not fast?" starts at the negotiated link.
## Recap
1. **PCIe is a point-to-point highway measured in lanes.** A lane is one independent parallel path; each
device gets its own dedicated lanes instead of fighting for a shared bus.
2. **Slots are sized by lane count** - x1, x4, x8, x16 - but *physical* size and *electrical* lane count
can differ ("x16 physical, x4 electrical"), and boards may reduce lanes when many slots are populated.
3. **GPUs, NVMe SSDs, and network/add-in cards** all plug in here; the bandwidth-hungry ones get the
widest slots.
4. **Bandwidth = lane count Γ generation.** A newer generation can match more lanes of an older one, and
the link always negotiates down to the slower end - silently capping cards that expected more.
Now to the headline tenant of that x16 slot: the GPU - what it's for, how it's fed, and how the everyday
peripherals from Phase 1 present themselves to the system.
---
# GPUs & Peripherals
You have the two roads - USB and PCIe. What's at the ends of them? First the biggest, most misunderstood
tenant of the PCIe highway, the **GPU**, then the humble peripherals from Phase 1 and the trick that lets
one driver handle a thousand different keyboards.
## Why a GPU exists at all
A GPU (Graphics Processing Unit) is built for a completely different shape of work: the CPU is a few
very clever cores doing complicated tasks one after another, *fast*; a GPU is thousands of much simpler
cores doing the *same* simple operation on different pieces of data at once. The CPU is a brilliant chef;
the GPU is a stadium of line cooks who can each crack one egg - useless for a complex recipe, unbeatable
for ten thousand eggs at once.
```text
CPU GPU
ββββββ ββββββ βββ¬ββ¬ββ¬ββ¬ββ¬ββ¬ββ¬ββ¬ββ
βcoreβ βcoreβ a few β β β β β β β β β β thousands of
ββββββ ββββββ powerful βββΌββΌββΌββΌββΌββΌββΌββΌββ€ simple cores,
ββββββ ββββββ cores, β β β β β β β β β β all doing the
βcoreβ βcoreβ complex βββΌββΌββΌββΌββΌββΌββΌββΌββ€ SAME thing to
ββββββ ββββββ work in β β β β β β β β β β DIFFERENT data
sequence βββ΄ββ΄ββ΄ββ΄ββ΄ββ΄ββ΄ββ΄ββ at once
```
Drawing a screen is the original case of "do the same thing to millions of items": every pixel needs
roughly the same color math, independently. A CPU doing one pixel at a time would crawl; a GPU does huge
swaths simultaneously. That's **massively parallel** work - many identical, independent operations - the
GPU's entire reason for being.
Why GPUs now run machine learning too: a neural network is, underneath, mostly multiplying big grids of
numbers (matrices) at enormous scale - *exactly* the "same simple math, millions of times, in parallel"
shape graphics has. The hardware built to shade pixels turned out to be ideal for ML: the same parallel
pattern wearing a different hat.
## How a GPU connects - and how it gets fed
The GPU is a PCIe device - usually a card in the x16 slot from Phase 2, or a chip soldered to the same
kind of high-bandwidth connection. The wide slot isn't vanity - the GPU constantly moves gigantic amounts
of data to and from the rest of the system.
The real bottleneck is feeding it: the work itself is fast, but getting data *to* the GPU over PCIe, and
results back, is often the slow part. That's why GPUs carry large, very fast on-board memory (VRAM) -
once data sits there, the cores chew through it without waiting on the PCIe trip back to system RAM.
```mermaid
flowchart LR
RAM["SYSTEM RAM
(where data starts)"]
GPU["GPU + its own VRAM
(data lives here so the cores
don't wait on the PCIe trip)"]
Cores["thousands of cores
(do the parallel work, fast)"]
RAM -->|"PCIe (the bottleneck often is here)"| GPU
GPU --> Cores
```
β οΈ **Gotcha - "my GPU is barely being used" is usually a feeding problem.** Low utilization while work is
clearly happening typically means *starved* cores - waiting on data (from disk, from the CPU preparing
it, or across PCIe), not lacking power. This ties back to Phase 2: a GPU on a slower-than-expected PCIe
link (fewer lanes or an older generation) is throttled by the road, not the engine. The fix is rarely "a
bigger GPU"; it's removing whatever stops data from arriving fast enough.
"Should I buy a faster GPU?" becomes: is the GPU actually the limit, or idling, waiting to be fed? It's
also why VRAM capacity matters for large models - data that doesn't fit in VRAM pays the slow PCIe trip
constantly.
## How everyday peripherals present themselves
A keyboard, a mouse, a webcam, a display - wildly different devices. The clever bit is how few drivers it
takes to support them all.
During enumeration (Phase 1) a device describes itself, including its **class** - a standard category
like "keyboard," "mouse," "mass storage," or "video." The OS ships one generic driver per class, so *any*
device claiming "standard keyboard" gets the same built-in driver - no per-model download, and a keyboard
or flash drive from a brand you've never heard of works the instant you plug it in.
π **Terminology.** *HID* (Human Interface Device) = the device class covering keyboards, mice, game
controllers, and similar input devices - the reason almost any keyboard or mouse "just works."
A quick tour:
- **Keyboard and mouse** - both HID-class: they announce "standard input device," the OS loads the
generic HID driver, and they work immediately. Macro keys or RGB lighting need the manufacturer's
software - but the *typing* always works: the standard class covers it.
- **Display** - connects over a video link (HDMI, DisplayPort, or DisplayPort over USB-C, as Phase 1
warned). Screen and system negotiate a resolution and refresh rate during connection, much like USB's
interview - why a fresh monitor usually lands on a sensible resolution by itself.
- **Webcam** - typically the standard USB video class, so the OS captures a basic image with a generic
driver. Vendor software adds extras (autofocus tuning, effects), but the core "show a video stream" is
standard - most webcams produce *a* picture before any maker's app is installed.
Without classes, every keyboard would need its own driver shipped to every OS, and a fresh keyboard
wouldn't work until you installed software. Standard behaviors let one driver serve thousands of models;
the cost is that *non-standard* features fall outside the class and need extra software - exactly the
split you see in practice.
## It all comes back to drivers
Every device in this guide - USB stick, GPU, webcam, keyboard - reaches your programs the same way:
through a **driver**, the OS's translator for one kind of hardware. Once the host detects, interviews,
and driver-matches a device, apps talk to the OS in generic terms ("read this drive," "draw this," "give
me the camera frame") and the driver handles the device-specific reality.
That layer - what a driver is, and why "it broke after an update" so often means "the driver broke" - is
told properly in [What an Operating System Is](/guides/what-an-operating-system-is). The point for *this*
guide: the physical connection is only half the story - a device must be plugged in *and* enumerated
*and* matched to a working driver before an app can use it. When something "isn't working," ask which of
the three is missing.
## Recap
1. **A GPU exists for massively parallel work** - thousands of simple cores doing the same operation on
different data at once. Graphics and ML are the same "same math, millions of times" pattern.
2. **It connects over PCIe** (the x16 slot); feeding it data - over PCIe, into its VRAM - is often the
real bottleneck. Low GPU utilization usually means starved cores, not a weak GPU.
3. **Peripherals present via device classes** (keyboard, mouse, HID, video) during enumeration, so one
generic driver serves thousands of models; only non-standard extras need vendor software.
4. **Everything routes through a driver** - plugged in, enumerated, *and* driver-matched before an app
can use it.
That's the whole picture: the universal door (USB), the internal highway (PCIe), the parallel powerhouse
(GPU), and the standard-class trick that makes peripherals plug-and-play.
Watch it animated: [CPU vs. GPU](/explainers/CPUvsGPU.dc.html)