[Qemu-devel] Re: sun framebuffer selection (was option-rom)

[Artyom Tarasenko <atar4qemu@googlemail.com>]

2010/6/6 Blue Swirl <blauwirbel@gmail.com>:
> On Sat, Jun 5, 2010 at 11:10 PM, Bob Breuer <breuerr@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?

>>> Maybe the recently proposed machine subtype patches could help here.

How is the graphic card different from cpu or a disk drive?

>> 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?

>> 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/