Re: [Qemu-devel] [PATCH] hw/display: Add basic ATI VGA emulation

[BALATON Zoltan]

Hello,

On Wed, 20 Feb 2019, Gerd Hoffmann wrote:
> > > So it could be tested with linux guests on x86 too I guess?
> > > Can the radeon drm driver handle the devices too?
> >
> > Yes you can try with x86 guests, I haven't tested that yet. The radeon
> > driver only supports RV100 and up I think so may only work with the 0x5159
> > variant not with Rage 128 Pro which had another driver r128 but not sure
> > that still exists. Although these two chips are similar, Rage 128 Pro is a
> > bit simpler that's why I'm targeting it first and also that's what the
> > PowerMac3,1 (the ppc mac99 machine is converging to) has. The R128Pro is the
> > last of the previous generation before Radeon, while RV100 is the stripped
> > down simplest version of the R100 family which has some more 3D capability).
> > But even if the DRM driver loads, probably only the mode setting part is
> > useful at the moment as 3D is not implemented yet by this device model.
>
> Chances are not too bad that it'll be good enough to bring up a linux
> console.

Yes, that may work but I haven't tested it. I've quickly tried booting a 
Linux install CD with 0x5159 but got no picture while the same iso got me 
output with the default r128p. The latter uses aty128fb. I haven't try to 
debug the radeon case not sure if the boot CD I've tried does not support 
that or something is missing for the Linux driver. In general I'm only 
targeting r128p now and added 0x5159 for the mips_fulong2e board and for 
later direction to develop it further but haven't tested that much yet.

> > > I'd also use model=<name> instead of device_id=... to switch between
> > > different devices.
> >
> > The only problem with that is that there are this many versions with
> > confusing names (and maybe different device ids for different versions):
> >
> > https://www.x.org/wiki/RadeonFeature/#index5h2
>
> Do we want emulate them all?
> I'd guess picking a few models would be more useful ...

Sure we don't want them all I was just trying to show that names are less 
clear than device id.

> Ok, I'd suggest to rename it to x-device-id (to indicate that it may go
> away later) if you want stick with device id for now.

That works for me as well, will do that in next version.

> One thing I've noticed is that you use the vbe registers internally.
> I'd suggest to not do that, I suspect it will only get into the way
> latter on.  Better register your own GraphicsHwOps, then go call the vga
> ops in vga mode and your ati modesetting code in extended mode.
> virtio-vga does it that way if you want look at some sample code.  Also
> looking at bochs-display.c is probably more helpful than looking at
> vga.c when figuring how to handle display updates.

Currently it's simpler for me the way I've done it so until this becomes a 
problem I don't want to add more code. Also I'm not sure how it would work 
because the hardware has both VGA engine and GUI engine (extended mode) 
working from the same memory and drivers sometimes poke VGA registers for 
example to set palette even in extended mode. So we can't avoid VGA 
altogether. Also we have no VESA BIOS and the one we have depends on VBE 
so that's also needed at the moment. This could be cleaned up later so I'd 
leave it for now and add more functionality instead.

Regards,
BALATON Zoltan