RFE: Add MS-RDPEUSB support

[elmarco]

Teach client & server about USB device redirection.

I will submit a GSoC proposal through the QEMU community:
https://wiki.qemu.org/Internships/ProjectIdeas/RDPUSB

See linked sub-issues below. The PDU layer (#1136) can be started in parallel with the ironrdp-dvc infrastructure (#1135), since it is pure serialization with no dependency on either. The backend (#1139) can also be started early by defining the trait up front and implementing it against stubs.

[uchouT]

Hi, I'm interested in working on this for GSoC 2026.

I run a Proxmox-based home server with several QEMU instances, so USB redirection is something I'd use myself.

I've been reading the IronRDP codebase — specifically the DvcProcessor trait in ironrdp-dvc and existing implementations (cliprdr, rdpdr, displaycontrol). It's clear that a new crate ironrdp-rdpeusb should implement DvcProcessor and expose a backend trait to keep I/O out of the Core tier.

I'm reading the MS-RDPEUSB these days.

[CBenoit]

Marc-André Lureau (@elmarco) Are you in charge of GSoC projects for QEMU?

[uchouT]

Relates to #61.

MS-RDPEUSB requires creating DVCs dynamically, as described in the spec:

There is one control channel and one channel for each of the USB devices.

On the client side, attach_dynamic_channel already allows registering a processor at runtime:

IronRDP/crates/ironrdp-dvc/src/client.rs

Lines 65 to 70 in 33410e0

	pub fn attach_dynamic_channel<T>(&mut self, channel: T)
	where
	T: DvcProcessor + 'static,
	{
	self.dynamic_channels.insert(channel);
	}

On the server side, there's no equivalent. Additionally, DrdynvcServer currently only sends CreateRequest PDUs during the initial capability handshake — there's no way to initiate a new DVC channel mid-session.

[CBenoit]

Summarizing what was discussed in the Matrix room for visibility in the issue tracker.

RDPEUSB is a client-to-server redirection protocol: physical USB devices are attached to the RDP client, and the RDP server gains access to them as if they were local. Traffic on the channel is bidirectional: the server drives the USB stack (sends IO_CONTROL, TRANSFER_IN_REQUEST, etc.) and the client executes operations against the hardware and ships completions back (URB_COMPLETION, IOCONTROL_COMPLETION, etc.).

The channel uses the name "URBDRC" over MS-RDPEDYC, with one control channel and one independent DVC channel per redirected USB device (MS-RDPEUSB §1.3.1.1, §3.3.5.1.1). Each device channel is a separate DYNVC_CREATE_REQ with a unique ChannelId but the same ChannelName = "URBDRC". MS-RDPEDYC §2.2.2.1 only requires ChannelId uniqueness; channel names are not unique.

The per-device channel lifecycle is:

1. Client detects a USB device → sends ADD_VIRTUAL_CHANNEL on the control channel
2. Server opens a new "URBDRC" DVC channel (new ChannelId)
3. Both sides exchange CHANNEL_CREATED on the new channel
4. Client sends ADD_DEVICE on the new channel (carries UsbDevice InterfaceId, hardware IDs, capabilities)
5. Server sends USB IO requests; client executes them via libusb and returns completions
6. On unplug: client sends RETRACT_DEVICE + RIMCALL_RELEASE, device channel closes

I’ll open sub-issues to split the work into smaller, manageable pieces of work that we can merge incrementally.

I’ll summarize the required changes in IronRDP codebase below.

Required ironrdp-dvc infrastructure change

The current DynamicChannelSet in ironrdp-dvc uses channel name as the primary key, it can only hold one channel instance per name. RDPEUSB requires multiple concurrent instances of "URBDRC". Two changes are needed:

Client side: listener/factory trait

Instead of registering a processor instance per name, register a factory that is called for each new DYNVC_CREATE_REQ for a given name, producing a fresh processor instance (with its own complete_data for fragmentation reassembly):

pub trait DvcChannelListener: Send {
  fn channel_name(&self) -> &str;

  /// Called for each new DYNVC_CREATE_REQ for this name.
  fn on_channel_creation(&mut self, channel_id: u32) -> Box<dyn DvcClientProcessor + Send>;
}

Server side: new-channel drain hook

The server needs a way for a processor to request that a new DVC channel be opened mid-session (triggered by receiving ADD_VIRTUAL_CHANNEL). A post-process() drain hook on DvcServerProcessor avoids changing the return type of process():

pub trait DvcServerProcessor: DvcProcessor {
  fn take_new_channels(&mut self) -> Vec<Box<dyn DvcServerProcessor + Send>> {
      vec![]
  }
}

After each process() call, DrdynvcServer drains take_new_channels(), inserts returned processors into the slab, and sends the corresponding DYNVC_CREATE_REQ PDUs.

Reference implementations in IronRDP

• ironrdp-displaycontrol (MS-RDPEDISP): simplest existing DvcClientProcessor + DvcServerProcessor implementation. Study this for how to wire a DVC channel into DrdynvcClient/DrdynvcServer.
• ironrdp-rdpdr (MS-RDPEFS): closest in protocol semantics; server-driven IO requests, client-side completions, device announce/remove lifecycle, and the RdpdrBackend trait pattern for separating protocol from hardware. Study this for the IO model.

Spec references

• MS-RDPEDYC
• MS-RDPEUSB