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

[Blue Swirl]

On Sun, Jun 6, 2010 at 4:28 PM, Artyom Tarasenko
<address@hidden> wrote:
> 2010/6/6 Blue Swirl <address@hidden>:
>> On Sat, Jun 5, 2010 at 11:10 PM, Bob Breuer <address@hidden> 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/
>