On 04.06.2011, at 12:42, Ingo Molnar wrote: > > * Alexander Graf <[email protected]> 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. 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. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
