On Mon, Jul 30, 2012 at 10:08:07PM +1000, Benjamin Herrenschmidt wrote: > On Mon, 2012-07-30 at 14:58 +0300, Avi Kivity wrote: > > Let's balkanize some more then? > > > > No, qxl is our paravirt vga, we should improve it instead of spawning > > new ones (which will be horrible in the eyes of the next person to look > > at them). You should also be getting the drm driver for free. > > > > http://spice-space.org/page/DRM > > "Free" is a big word here, I wouldn't be surprised if it was totally > endian busted :-) > > Why so much effort into a bad design on top of a crack transport btw ? Could you elaborate about the design and transport issues that you see?
> Is it just RH politics of there's a good reason hiding somewhere ? Some No politics AFAIK. Spice code may suck but it's doing a good job while sucking, so we prefer to fix it unless a good design that makes it easier to rebuild from scratch comes along. I'm all ears. > kind of morbid fascination for anything Windows ? We do have bad linux performance but the is work going to improve it, by adding RENDER implementation to our driver and protocol additions, among others. > > People I've talked to around in the community seem to agree that some > minor improvements on qemu-vga are worthwhile, so I'm doing them, > nothing drastic, mostly having a mirror of the legacy IO registers in an > MMIO BAR so it's more usable for non-x86 platforms, and I'm about to add > some simplistic 2D blit facility so we can have a semi-decent fb console > over vnc. I can trivially do an equivalent of cirrusdrmfb for it so we > get X mode setting / RandR. > > That gives us a baseline for mostly unaccelerated 2D. > > Something tells me that getting that spice/qxl gunk will be more than a > trivial effort (but I might be wrong) and I'm reluctant to start > committing effort on it since so far I yet have to see it being actually > picked up by people. I'll be happy to elaborate on any part of qxl/spice that I understand and help you help us improve it. > > Cheers, > Ben. > > > >