From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=39013 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OLALd-0000Xy-7G for qemu-devel@nongnu.org; Sun, 06 Jun 2010 03:32:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OLALb-000198-Uc for qemu-devel@nongnu.org; Sun, 06 Jun 2010 03:32:45 -0400 Received: from mail-px0-f173.google.com ([209.85.212.173]:33089) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OLALb-00018z-9R for qemu-devel@nongnu.org; Sun, 06 Jun 2010 03:32:43 -0400 Received: by pxi2 with SMTP id 2so841617pxi.4 for ; Sun, 06 Jun 2010 00:32:42 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4C0AD980.8040206@mc.net> References: <4C0AB2B8.2080906@mc.net> <4C0AD980.8040206@mc.net> From: Blue Swirl Date: Sun, 6 Jun 2010 07:32:22 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] Re: sun framebuffer selection (was option-rom) List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bob Breuer Cc: qemu-devel@nongnu.org, Artyom Tarasenko On Sat, Jun 5, 2010 at 11:10 PM, Bob Breuer wrote: > Blue Swirl wrote: >> =C2=A0but again: should we have a new machine with cg14 or >> some switch to select TCX vs. cg14? >> >> Maybe the recently proposed machine subtype patches could help here. >> > Well, let's try to figure out a method of selecting the framebuffer > type. =C2=A0I'll try to list some of the options, even if they might be > ridiculous. > > 1) Use the -vga option. =C2=A0I know TCX and cg14 are not vga, but I thin= k > it's the closest existing command line option available. > > 2) Switch based on the -g WxH option. =C2=A0At the moment, the TCX emulat= ion > doesn't really handle anything other than 1024x768, so switch to cg14 > for other resolutions if supported. > > 3) Use some other existing command line option, -device, -set or > -global? =C2=A0Might work, but the syntax may not be easy to remember. We don't have an equivalent of -chardev, -netdev and -drive for displays. > 4) Machine subtype. > > 5) New command line option. =C2=A0Anything above might be better. > > 6) New machine type. =C2=A0Is it a big enough feature to demand it's own > machine type? =C2=A0Maybe, but see next option. > > 7) Select as default video for SS-20. =C2=A0The SS-10 and SS-600MP are > already very similar. =C2=A0This would allow for some differentiation bet= ween > the machines, but there could still be an option to switch back to TCX. > Note that TCX was really only available for the SS-4 and SS-5. > > > Is there anything else that I missed? Combined 7 & 6: make cg14 default for SS-20, add a deprecated compatibility machine for SS-20 with TCX. > > I'm going to go ahead with option 2 in the short term. =C2=A0I'm inclined= to > narrow it down to options 1, 4, and 7. =C2=A0I know that 7 would have > backwards compatibility concerns. =C2=A0The cg14 seems to have at least t= he > same capabilities as TCX so there shouldn't be any loss of > functionality. =C2=A0Even though SS-20 is not the default machine, do you > know of any OS that works with the sun4m implementation today but > doesn't have a cg14 driver? =C2=A0Possible downside to cg14 for video is = that > any "acceleration" is handled by the SX pixel processor which has no > available documentation. =C2=A0TCX also has some amount of unimplemented > acceleration. It would be nice to use some basic device with well defined acceleration or just a frame buffer as default.