On Sun, Jun 6, 2010 at 4:28 PM, Artyom Tarasenko <atar4q...@googlemail.com> wrote: > 2010/6/6 Blue Swirl <blauwir...@gmail.com>: >> On Sat, Jun 5, 2010 at 11:10 PM, Bob Breuer <breu...@mc.net> wrote: >>> Blue Swirl wrote: >>>> but again: should we have a new machine with cg14 or >>>> some switch to select TCX vs. cg14? >>>> > > Why not just probe for both devices? OpenBIOS has the intention > to run one day on a real hardware, doesn't it?
I don't think it's very interesting for old hardware. Also coreboot may be a better platform (with OpenBIOS as a payload). >>>> Maybe the recently proposed machine subtype patches could help here. > > How is the graphic card different from cpu or a disk drive? It isn't. >>> Well, let's try to figure out a method of selecting the framebuffer >>> type. I'll try to list some of the options, even if they might be >>> ridiculous. >>> >>> 1) Use the -vga option. I know TCX and cg14 are not vga, but I think >>> it's the closest existing command line option available. >>> >>> 2) Switch based on the -g WxH option. At the moment, the TCX emulation >>> 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? Might work, but the syntax may not be easy to remember. >> >> We don't have an equivalent of -chardev, -netdev and -drive for displays. > > I guess only cause the other emulated platforms don't have that much > of choice (yet). > Why not use just the generic -device option? Then there would be two graphics devices. There should be something like -displaydev SDL,id=1 -displaydev SDL,id=2 -device cg14,display=1 -device TCX,display=2. > >>> 4) Machine subtype. >>> >>> 5) New command line option. Anything above might be better. >>> >>> 6) New machine type. Is it a big enough feature to demand it's own >>> machine type? Maybe, but see next option. >>> >>> 7) Select as default video for SS-20. The SS-10 and SS-600MP are >>> already very similar. This would allow for some differentiation between >>> 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. >>> > > They are similar in qemu. But it's rather a bug than a feature. The > real SS-600 is much more complex VME-bus machine. > >>> >>> 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. I'm inclined to >>> narrow it down to options 1, 4, and 7. I know that 7 would have >>> backwards compatibility concerns. The cg14 seems to have at least the >>> same capabilities as TCX so there shouldn't be any loss of >>> functionality. Even 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? Possible downside to cg14 for video is that >>> any "acceleration" is handled by the SX pixel processor which has no >>> available documentation. TCX 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. >> > > AFAIK the open source OSes don't use the cg14 acceleration anyway. So > we'll only have potential problems with Solaris and NeXTStep here. > > > -- > Regards, > Artyom Tarasenko > > solaris/sparc under qemu blog: http://tyom.blogspot.com/ >