Add a real, QEMU-targeted virtio-input driver as a new Red Bear recipe at
local/recipes/drivers/virtio-inputd/. The driver handles virtio-input-host-pci,
virtio-input-keyboard, virtio-input-mouse, and virtio-input-tablet devices and
closes Gap #19 of the v5.0 desktop plan.
The driver:
* Walks the PCI capability list to find the modern virtio 1.0 capability
block (common_cfg, notify_cfg, isr_cfg, device_cfg) using MmioRegion
mappings via redox-driver-sys. Rejects legacy virtio-input (device 0x1052)
which lacks the modern transport.
* Negotiates VIRTIO_F_VERSION_1 only (the only required feature).
* Allocates one event virtqueue (size up to 64) backed by four DMA buffers
(desc, avail, used, event_buffers) and pre-fills the avail ring.
* Polls the used ring at 60 Hz, drains completed events, decodes each
virtio_input_event (8-byte type/code/value), and recycles drained buffers
back to the avail ring.
* Translates events to orbclient format and pushes them to inputd via
ProducerHandle (Orbital path):
- EV_KEY -> KeyEvent (with US-QWERTY character mapping)
- EV_REL -> MouseRelativeEvent (REL_X/REL_Y) or ScrollEvent (REL_WHEEL)
- EV_SYN -> dropped (inputd multiplexes)
- Other -> dropped (Phase 5.2 will add evdevd path)
Probe-time checks:
* Vendor 0x1AF4, device_id >= 0x1042, revision >= 1
* Caps include a device_cfg block with virtio type == 18 (virtio_input)
Configuration: a pcid-spawner fragment is added to config/redbear-full.toml
under /etc/pcid.d/virtio-inputd.toml matching class=0x09 vendor=0x1AF4 with
device_id_range 0x1042..=0x107F (and a separate 0x1052 entry that the driver
intentionally rejects).
Verification: cargo check produces 0 errors and 65 warnings, all of which are
unused input-event-codes.h constants reserved for the Phase 5.2 expansion.
Linking the binary requires the Redox cross-toolchain (relibc provides
redox_sys_call_v0); this is provided by the build system, not the host
toolchain.
Plan: this is Phase 5.1 of CONSOLE-TO-KDE-DESKTOP-PLAN.md v5.0. The plan is
updated to v5.1 with: (a) a 'What Changed Since v5.0' section, (b) Gap #19
marked DONE, (c) Phase 5 row marked DONE with sub-task status, (d) Gate E
updated, (e) Input pipeline section updated to reflect the (c) path is now
implemented. Phase 5.2 (evdevd producer path + virtio-snd) is documented as
the next planned work but not yet implemented.
vasilito
19a9eecb54