* Alexander Graf <agraf@xxxxxxx> wrote: > > On 04.06.2011, at 12:42, Ingo Molnar wrote: > > > > > * Alexander Graf <agraf@xxxxxxx> wrote: > > > >> I wrote up 2 virtio-fb implementations a while back and I still > >> believe it's a bad idea. Better implement QXL in kvm-tool, so work > >> doesn't get needlessly duplicated. If you really have to use virtio > >> for whatever reason (no PCI available), just write a small QXL over > >> virtio transport that allows you to reuse the protocol. > >> > >> I really don't want to see people waste time on reinventing the > >> wheel over and over again. > > > > Oh, we are just ignorantly blundering around trying to find a good > > solution! :-) > > > > We are not trying to reimplement the wheel (at all), if you check we > > started with VNC GUI support which is as far from NIH as it gets! :-) > > > > I didn't know about QXL but it looks interesting at first sight: a > > virtual GPU seen by the guest OS with Xorg support for it in the > > guest Xorg. But i do not see guest kernel framebuffer support for it > > - how does that aspect work, if one boots without Xorg, etc.? > > IIUC it implements VESA and just goes through the respective fb. > [...] So, if you look at the context of this dicussion our motivation is slow scrolling and our desire to support smooth scrolling on 64-bit too. It was unclear whether VESA would proper panning/scrolling on 64-bit as well - Pekka thinks that it is not supported there. > [...] I would love to see a QXL fb implementation though. I'd also > love to see QXL working on !PCI, so we can potentially use it on > s390x and ppc-hv which can't easily do MMIO. > > So instead of putting effort into writing virtio-fb host and guest > sides, why not implement QXL-fb against a working target (qemu) and > then implement the QXL host side against a working target (working > guest support)? That probably makes the development process a lot > easier. Have a look at the 'kvm' tool: git pull git://github.com/penberg/linux-kvm master We'd like to implement better graphics support there, in a gradual fashion if possible. Right now we have VNC and SDL support - two rather primitive 2D framebuffer concepts with no acceleration at all. If you think qxl-fb can be done gradually in that context then that's probably the right solution. Is there *any* QXL code in the kernel that would allow us to get started? I really know nothing about QXL. The natural steps for us would be: - add primitive 2D acceleration support: scrolling - check what it would require to get good guest Xorg support. QXL has a full driver on the guest side Xorg server - but how does this get channeled over to the virtualizer - is it a magic PCI device that the host has to provide to the guest and which the guest Xorg server uses as a PCI device? Or does the guest side DRM code know about this GPU and uses it in KMS? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
