vasilito/RedBear-OS
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

drivers: redox-drm wins virtio-gpu bind for the VirGL desktop path

Browse Source 
driver-manager had a priority tie for QEMU virtio-gpu (vendor 0x1AF4, class
0x03): redox-drm (generic class @60) vs virtio-gpud (@60). If virtio-gpud won,
it registered display.virtio-gpu (VT scanout only) and never provided
/scheme/drm/card0, starving KWin/the compositor. redox-drm had priority-61
entries for Intel and AMD but none for VirtIO. Add a priority-61 redox-drm entry
for vendor 0x1AF4 class 0x03 (subclass omitted — QEMU virtio-gpu is subclass
0x80) so the VirGL path deterministically binds redox-drm and gets a real DRM
card0. virtio-gpud remains as fallback.
This commit is contained in:
vasilito
2026-07-24 13:19:23 +09:00
parent 74d5e01bb4
commit a00c13e5c7
1 changed files with 15 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
local/config/drivers.d/30-graphics.toml
+15
View File
@@ -44,3 +44,18 @@ command = ["/usr/bin/redox-drm"]
vendor = 0x1002
class = 0x03
subclass = 0x00
# VirtIO GPU (QEMU virtio-gpu / VirGL, e.g. 1AF4:1050 class 03) — bind redox-drm
# at higher priority than the base virtio-gpud (@60) so the desktop path gets a
# real /scheme/drm/card0 (redox-drm's built-in VirtIO KMS driver) instead of the
# display.virtio-gpu VT-only scanout. Subclass is intentionally omitted:
# QEMU reports virtio-gpu as class 0x03 subclass 0x80, not 0x00.
[[driver]]
name = "redox-drm"
description = "VirtIO GPU display driver (VirGL/KMS)"
priority = 61
command = ["/usr/bin/redox-drm"]
[[driver.match]]
vendor = 0x1AF4
class = 0x03