From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41595) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Svslk-00036I-1m for qemu-devel@nongnu.org; Mon, 30 Jul 2012 12:24:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Svslf-0000G4-KQ for qemu-devel@nongnu.org; Mon, 30 Jul 2012 12:24:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:23444) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Svslf-0000Fz-B3 for qemu-devel@nongnu.org; Mon, 30 Jul 2012 12:24:27 -0400 Date: Mon, 30 Jul 2012 18:24:19 +0200 From: Alon Levy Message-ID: <20120730162419.GN29361@garlic.redhat.com> References: <1343629462.21647.32.camel@pasglop> <50165D0A.6060608@redhat.com> <1343647217.21647.40.camel@pasglop> <50166F2A.1040507@redhat.com> <1343649267.21647.44.camel@pasglop> <501676D7.3010504@redhat.com> <1343650087.2498.4.camel@pasglop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1343650087.2498.4.camel@pasglop> Subject: Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Benjamin Herrenschmidt Cc: Avi Kivity , qemu-devel@nongnu.org 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. > > > >