On 21/07/2019 11:00, BALATON Zoltan wrote:
On Sun, 21 Jul 2019, Mark Cave-Ayland wrote:
On 20/07/2019 17:36, BALATON Zoltan wrote:
driver,AAPL,MacOS,PowerPC -- 4941 : 4a 6f 79 21 70 65 66 66 70 77 70 63 00
^^^ This driver should not be here.
Ah I see. This is because vga_config_cb() gets called not just for a specific device/vendor id but for any PCI display device. It might be worth renaming it to bochs_config_cb() and tying it down to the QEMU device/vendor id so that it doesn't interfere with external FCode ROMs.
But I had vga-ndrv? set to false so this then should not add driver even for QEMU VGA and it didn't add it with this serting before your patches, only does now so there's some problem with handling that option now.
Hmmm okay, I thought you meant for your ATI card. I'll do a quick test in a bit and see if I can recreate this.
Not running vga.fs and adding driver for ATY but let an FCode ROM do it is next step but we'll need to make FCode ROMs work for that first. (Actually once that works I'd like to also switch QEMU VGA to use proper FCode ROM added in QEMU then the hacks regading vga.fs and NDRV patching could be completely cleaned up from OpenBIOS.)
I think there is something to be said for splitting out the VGA driver as already is done for the CG3/TCX drivers, but there's not much point doing that until we're happy that the implementation is fairly compliant with the specification. As for the NDRV my current preference is to keep it separate since it makes development/debugging the driver itself considerably easier.
Then again this only affects the QEMU VGA device: if you have a real option ROM then you should be able to pass that in as a parameter to your ATI device and everything should "just work" once OpenBIOS has been tweaked to detect its FCode payload.
ATB,
Mark.