virtio_gpu: add support for xf86-video-scfb
Needs ReviewPublic
Actions

Authored by tiga on Jan 31 2026, 3:10 PM.

Details

Reviewers

andrew
bryanv
kevans
dumbbell
emaste

Summary

virtio_gpu: add support for xf86-video-scfb

Added virtio_gpu support for UTM/MacOS configured with virtio-gpu-pci.
Tunable parameters:

hw.virtio_gpu.width
hw.virtio_gpu.height
dev.vtgpu.X.refresh_rate

Tested with FreeBSD 15 (arm64) running on MacOS 26.2 and UTM (version 4.7.5 / qemu 10.0.2).

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Skipped

Unit

Tests Skipped

Event Timeline

tiga created this revision.Jan 31 2026, 3:10 PM

Herald added a subscriber: imp. · View Herald TranscriptJan 31 2026, 3:10 PM

tiga requested review of this revision.Jan 31 2026, 3:10 PM

ref: https://bugs.freebsd.org/292982

lwhsu added reviewers: andrew, bryanv.Feb 6 2026, 12:37 AM

ziaee added reviewers: kevans, dumbbell.Feb 6 2026, 1:12 AM

imp added a reviewer: emaste.Feb 8 2026, 7:03 PM

So I don't understand the underlying code well enough to have a good take on this... It seems like this is always active, but maybe shouldn't be.
It would be helpful, though, if you could upload the next set of diffs created with -U9999 so that we get enough context in phabricator. It made it hard to check on stuff

sys/dev/virtio/gpu/virtio_gpu.c
374	why is this. unconditional?
405	this seems backwards.
423	Do we always need this periodic flush, or just when this feature is active?
473	when would this get called before initialized is true?

tiga added inline comments.Feb 8 2026, 10:26 PM

sys/dev/virtio/gpu/virtio_gpu.c
374	I am guessing that VirtIO GPU always allocates the framebuffer in system RAM rather than mapping actual GPU VRAM, so I decided to use VM_MEMATTR_DEFAULT. I am not sure 100% about this, though, but it seemed right...
405	yes, i agree looks very strange. when running my tests, it turns out that after registering with fbd_register, the device /dev/fb0 appears, and the result if EEXIST. not really sure why... I propose to change the code to the following (tested and seems working): } else { device_printf(dev, "/dev/fb0 created\n"); sc->vtgpu_fb_registered = true; }
423	You are right - this periodic flush should only be done when `sc->vtgpu_fb_registered` is true I will change the code to reflect this, and test it again
473	i tried to do some defensive programming here, you are right, when this function is called, the vtgpu_initialized should always be true. this check can be reduced to if (!sc->vtgpu_detaching) i will change accordingly and test

Updated code according to review comments:

removed vtgpu_initialized flag
flush task only started when /dev/fd0 is available
improved logic for device_printf when attached
removed unnecessary if conditions

Sorry, new here... still learning
This patch has -U9999, as requested

What is the overhead form all the extra wakeups this adds? I'd prefer we add a way for userspace to tell the kernel to perform an update.

In D55012#1261935, @andrew wrote:

What is the overhead form all the extra wakeups this adds? I'd prefer we add a way for userspace to tell the kernel to perform an update.

Hi. In my computer, the overhead is not really noticeable - and if this is a problem, it can be controlled with the "refresh_rate" setting...
This is for sure not a "good" solution, but it is kind of working...
I see this as temporary until we can have a solution that e.g. properly implements 3D / hardware acceleration - unfortunately I do not know how to do this.
In any case, this is my first patch - I am open to suggestions, in case someone knows a better way to implement this :-)

Hi. Sorry for not being too active on this - just wanted to give a heads-up that I am looking at disabling the functionality by default as asked by @imp; currently I am "under water" with lots of things to do at work and with family, and therefore having difficulties to find time to look at this; however this is not forgotten, and I will come back asap. Thanks!