hw/display/vga.c | 35 +++++++++++++++++++++++++++++++++ include/hw/display/bochs-vbe.h | 7 +++++-- pc-bios/qemu_vga.ndrv | Bin 18752 -> 20944 bytes 3 files changed, 40 insertions(+), 2 deletions(-)
Dear all,
I want to give Mac OS 9 clients access to hardware cursor support, to improve
responsiveness in absolute-cursor mode.
Would it be acceptable to add a hardware cursor interface to the VGA device?
And if so, can anyone advise on an appropriate register layout?
This is an example of such a patch. Because it alters the Bochs VBE interface
it is ONLY an example, NOT fit for acceptance. I have omitted the changes to
the binary driver qemu_vga.ndrv.
Kind regards,
Elliot Nunn
---
hw/display/vga.c | 35 +++++++++++++++++++++++++++++++++
include/hw/display/bochs-vbe.h | 7 +++++--
pc-bios/qemu_vga.ndrv | Bin 18752 -> 20944 bytes
3 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/hw/display/vga.c b/hw/display/vga.c
index 5dca2d1528..9b562e24e2 100644
--- a/hw/display/vga.c
+++ b/hw/display/vga.c
@@ -744,6 +744,10 @@ void vbe_ioport_write_data(void *opaque, uint32_t addr, uint32_t val)
{
VGACommonState *s = opaque;
+ static size_t cursorCounter;
+ static uint8_t cursorData[16 * 16 * 4];
+ QEMUCursor *cursor;
+
if (s->vbe_index <= VBE_DISPI_INDEX_NB) {
trace_vga_vbe_write(s->vbe_index, val);
switch(s->vbe_index) {
@@ -796,6 +800,37 @@ void vbe_ioport_write_data(void *opaque, uint32_t addr, uint32_t val)
s->vbe_regs[s->vbe_index] = val;
vga_update_memory_access(s);
break;
+
+ case VBE_DISPI_INDEX_CURSOR_IMG:
+ cursorData[cursorCounter++] = val >> 8;
+ cursorData[cursorCounter++] = val;
+ cursorCounter &= sizeof(cursorData) - 1;
+ break;
+
+ case VBE_DISPI_INDEX_CURSOR_HOTSPOT:
+ cursor = cursor_alloc(16, 16);
+
+ if (val == 0x8080) { // blank cursor
+ for (int i = 0; i < 16*16; i++) {
+ cursor->data[i] = 0;
+ }
+ } else {
+ for (int i = 0; i < 16*16; i++) {
+ cursor->data[i] =
+ ((uint32_t)cursorData[i*4] << 24) |
+ ((uint32_t)cursorData[i*4+1] << 16) |
+ ((uint32_t)cursorData[i*4+2] << 8) |
+ (uint32_t)cursorData[i*4+3];
+ }
+
+ cursor->hot_x = (int8_t)(val >> 8);
+ cursor->hot_y = (int8_t)val;
+ }
+
+ dpy_cursor_define(s->con, cursor);
+ cursor_put(cursor); // dealloc
+ break;
+
default:
break;
}
diff --git a/include/hw/display/bochs-vbe.h b/include/hw/display/bochs-vbe.h
index bc2f046eee..7de409bae7 100644
--- a/include/hw/display/bochs-vbe.h
+++ b/include/hw/display/bochs-vbe.h
@@ -19,7 +19,10 @@
#define VBE_DISPI_INDEX_VIRT_HEIGHT 0x7
#define VBE_DISPI_INDEX_X_OFFSET 0x8
#define VBE_DISPI_INDEX_Y_OFFSET 0x9
-#define VBE_DISPI_INDEX_NB 0xa /* size of vbe_regs[] */
+#define VBE_DISPI_INDEX_CURSOR_IMG 0xb
+#define VBE_DISPI_INDEX_CURSOR_HOTSPOT 0xc
+#define VBE_DISPI_INDEX_CURSOR_ABS 0xd
+#define VBE_DISPI_INDEX_NB 0xe /* size of vbe_regs[] */
#define VBE_DISPI_INDEX_VIDEO_MEMORY_64K 0xa /* read-only, not in vbe_regs */
/* VBE_DISPI_INDEX_ID */
@@ -54,7 +57,7 @@
/* bochs vbe register region */
#define PCI_VGA_BOCHS_OFFSET 0x500
-#define PCI_VGA_BOCHS_SIZE (0x0b * 2)
+#define PCI_VGA_BOCHS_SIZE (VBE_DISPI_INDEX_NB * 2)
/* qemu extension register region */
#define PCI_VGA_QEXT_OFFSET 0x600
--
2.30.1 (Apple Git-130)On Mon, Aug 01, 2022 at 11:58:51AM +0800, Elliot Nunn wrote: > Dear all, > > I want to give Mac OS 9 clients access to hardware cursor support, to improve > responsiveness in absolute-cursor mode. > > Would it be acceptable to add a hardware cursor interface to the VGA device? > And if so, can anyone advise on an appropriate register layout? Certainly acceptable. Toyed with the idea, but never actually did it because in most cases it is easier to just use virtio-gpu instead ;) > +#define VBE_DISPI_INDEX_CURSOR_IMG 0xb > +#define VBE_DISPI_INDEX_CURSOR_HOTSPOT 0xc > +#define VBE_DISPI_INDEX_CURSOR_ABS 0xd There already is a qemu-specific register extension set (see pci_vga_qext_ops in hw/display/vga-pci.c). Right now it has two registers: One r/o register returning the size of the register area, and one register to get/set the frame buffer byte order. So, when adding hardware cursor support I'd strongly suggest to add the registers there. First because that is already qemu-specific, and second because handling backward compatibility is much easier then. Guests can easily figure whenever hardware cursors are supported by checking the size register and see whenever the hwcursor registers are there or not. I'd also suggest to use more verbose register names and use a separate register for each value, i.e. PCI_VGA_QEXT_REG_HWCURSOR_ENABLE PCI_VGA_QEXT_REG_HWCURSOR_VRAM_OFFSET PCI_VGA_QEXT_REG_HWCURSOR_HOTSPOT_X PCI_VGA_QEXT_REG_HWCURSOR_HOTSPOT_Y PCI_VGA_QEXT_REG_HWCURSOR_POSITION_X PCI_VGA_QEXT_REG_HWCURSOR_POSITION_Y Also define clear semantics for each register and for the cursor format. Do we want just a fixed 64x64 rgba format? If not we need more registers ... Is position the upper left corner of the image or the hotspot? take care, Gerd
On Mon, 15 Aug 2022, Gerd Hoffmann wrote: > On Mon, Aug 01, 2022 at 11:58:51AM +0800, Elliot Nunn wrote: >> Dear all, >> >> I want to give Mac OS 9 clients access to hardware cursor support, to improve >> responsiveness in absolute-cursor mode. >> >> Would it be acceptable to add a hardware cursor interface to the VGA device? >> And if so, can anyone advise on an appropriate register layout? > > Certainly acceptable. Toyed with the idea, but never actually did it > because in most cases it is easier to just use virtio-gpu instead ;) I think that's the way Elliot ended up going for as well also because it could provide more features in the future. Getting just the framebuffer and hardware cursor working with virtio-vga may be relatively easy to do. >> +#define VBE_DISPI_INDEX_CURSOR_IMG 0xb >> +#define VBE_DISPI_INDEX_CURSOR_HOTSPOT 0xc >> +#define VBE_DISPI_INDEX_CURSOR_ABS 0xd > > There already is a qemu-specific register extension set (see > pci_vga_qext_ops in hw/display/vga-pci.c). Right now it has two > registers: One r/o register returning the size of the register > area, and one register to get/set the frame buffer byte order. > > So, when adding hardware cursor support I'd strongly suggest to > add the registers there. First because that is already > qemu-specific, and second because handling backward compatibility > is much easier then. Guests can easily figure whenever hardware > cursors are supported by checking the size register and see > whenever the hwcursor registers are there or not. > > I'd also suggest to use more verbose register names and use a separate > register for each value, i.e. > > PCI_VGA_QEXT_REG_HWCURSOR_ENABLE > PCI_VGA_QEXT_REG_HWCURSOR_VRAM_OFFSET > PCI_VGA_QEXT_REG_HWCURSOR_HOTSPOT_X > PCI_VGA_QEXT_REG_HWCURSOR_HOTSPOT_Y > PCI_VGA_QEXT_REG_HWCURSOR_POSITION_X > PCI_VGA_QEXT_REG_HWCURSOR_POSITION_Y Having at least position in a single register may be better as then updating it is a single register write instead of two. Not likely to have so big VGA screens that don't fit in one register. Regards, BALATON Zoltan > Also define clear semantics for each register and for the cursor format. > > Do we want just a fixed 64x64 rgba format? > If not we need more registers ... > > Is position the upper left corner of the image or the hotspot? > > take care, > Gerd > >
On 01/08/2022 04:58, Elliot Nunn wrote:
> Dear all,
>
> I want to give Mac OS 9 clients access to hardware cursor support, to improve
> responsiveness in absolute-cursor mode.
>
> Would it be acceptable to add a hardware cursor interface to the VGA device?
> And if so, can anyone advise on an appropriate register layout?
>
> This is an example of such a patch. Because it alters the Bochs VBE interface
> it is ONLY an example, NOT fit for acceptance. I have omitted the changes to
> the binary driver qemu_vga.ndrv.
>
> Kind regards,
>
> Elliot Nunn
>
> ---
> hw/display/vga.c | 35 +++++++++++++++++++++++++++++++++
> include/hw/display/bochs-vbe.h | 7 +++++--
> pc-bios/qemu_vga.ndrv | Bin 18752 -> 20944 bytes
> 3 files changed, 40 insertions(+), 2 deletions(-)
>
> diff --git a/hw/display/vga.c b/hw/display/vga.c
> index 5dca2d1528..9b562e24e2 100644
> --- a/hw/display/vga.c
> +++ b/hw/display/vga.c
> @@ -744,6 +744,10 @@ void vbe_ioport_write_data(void *opaque, uint32_t addr, uint32_t val)
> {
> VGACommonState *s = opaque;
>
> + static size_t cursorCounter;
> + static uint8_t cursorData[16 * 16 * 4];
> + QEMUCursor *cursor;
> +
> if (s->vbe_index <= VBE_DISPI_INDEX_NB) {
> trace_vga_vbe_write(s->vbe_index, val);
> switch(s->vbe_index) {
> @@ -796,6 +800,37 @@ void vbe_ioport_write_data(void *opaque, uint32_t addr, uint32_t val)
> s->vbe_regs[s->vbe_index] = val;
> vga_update_memory_access(s);
> break;
> +
> + case VBE_DISPI_INDEX_CURSOR_IMG:
> + cursorData[cursorCounter++] = val >> 8;
> + cursorData[cursorCounter++] = val;
> + cursorCounter &= sizeof(cursorData) - 1;
> + break;
> +
> + case VBE_DISPI_INDEX_CURSOR_HOTSPOT:
> + cursor = cursor_alloc(16, 16);
> +
> + if (val == 0x8080) { // blank cursor
> + for (int i = 0; i < 16*16; i++) {
> + cursor->data[i] = 0;
> + }
> + } else {
> + for (int i = 0; i < 16*16; i++) {
> + cursor->data[i] =
> + ((uint32_t)cursorData[i*4] << 24) |
> + ((uint32_t)cursorData[i*4+1] << 16) |
> + ((uint32_t)cursorData[i*4+2] << 8) |
> + (uint32_t)cursorData[i*4+3];
> + }
> +
> + cursor->hot_x = (int8_t)(val >> 8);
> + cursor->hot_y = (int8_t)val;
> + }
> +
> + dpy_cursor_define(s->con, cursor);
> + cursor_put(cursor); // dealloc
> + break;
> +
> default:
> break;
> }
> diff --git a/include/hw/display/bochs-vbe.h b/include/hw/display/bochs-vbe.h
> index bc2f046eee..7de409bae7 100644
> --- a/include/hw/display/bochs-vbe.h
> +++ b/include/hw/display/bochs-vbe.h
> @@ -19,7 +19,10 @@
> #define VBE_DISPI_INDEX_VIRT_HEIGHT 0x7
> #define VBE_DISPI_INDEX_X_OFFSET 0x8
> #define VBE_DISPI_INDEX_Y_OFFSET 0x9
> -#define VBE_DISPI_INDEX_NB 0xa /* size of vbe_regs[] */
> +#define VBE_DISPI_INDEX_CURSOR_IMG 0xb
> +#define VBE_DISPI_INDEX_CURSOR_HOTSPOT 0xc
> +#define VBE_DISPI_INDEX_CURSOR_ABS 0xd
> +#define VBE_DISPI_INDEX_NB 0xe /* size of vbe_regs[] */
> #define VBE_DISPI_INDEX_VIDEO_MEMORY_64K 0xa /* read-only, not in vbe_regs */
>
> /* VBE_DISPI_INDEX_ID */
> @@ -54,7 +57,7 @@
>
> /* bochs vbe register region */
> #define PCI_VGA_BOCHS_OFFSET 0x500
> -#define PCI_VGA_BOCHS_SIZE (0x0b * 2)
> +#define PCI_VGA_BOCHS_SIZE (VBE_DISPI_INDEX_NB * 2)
>
> /* qemu extension register region */
> #define PCI_VGA_QEXT_OFFSET 0x600
Hi Elliot,
Nice work! Have you been in contact with the Bochs developers to see what their
thoughts are to your proposed changes? Generally QEMU prefers to implement documented
specifications, so this would be the best route to go.
ATB,
Mark.
>> I want to give Mac OS 9 clients access to hardware cursor support, to improve >> responsiveness in absolute-cursor mode. >> Would it be acceptable to add a hardware cursor interface to the VGA device? >> And if so, can anyone advise on an appropriate register layout? >> This is an example of such a patch. Because it alters the Bochs VBE interface >> it is ONLY an example, NOT fit for acceptance. I have omitted the changes to >> the binary driver qemu_vga.ndrv. >> Kind regards, >> Elliot Nunn > Nice work! Have you been in contact with the Bochs developers to see what their thoughts are to your proposed changes? Generally QEMU prefers to implement documented specifications, so this would be the best route to go. Thanks! I don't think it would be appropriate to update the Bochs standard with a feature that they don't use. And on reflection, perhaps the compatibility-oriented VGA device is big enough already. My plan is to write a Mac OS 9/X "ndrv" targeting virtio-gpu. All going this well, this might become the default mac99 GPU until ati-vga is ready. But virtio-gpu is not compiled into qemu-system-ppc by default. What is the difference between CONFIG_VIRTIO_(GPU|PCI|VGA)? And is configs/devices/ppc-softmmu/default.mak the correct place to declare them?
On Sun, 7 Aug 2022, Elliot Nunn wrote: >>> I want to give Mac OS 9 clients access to hardware cursor support, to improve >>> responsiveness in absolute-cursor mode. >>> Would it be acceptable to add a hardware cursor interface to the VGA device? >>> And if so, can anyone advise on an appropriate register layout? >>> This is an example of such a patch. Because it alters the Bochs VBE interface >>> it is ONLY an example, NOT fit for acceptance. I have omitted the changes to >>> the binary driver qemu_vga.ndrv. >>> Kind regards, >>> Elliot Nunn >> Nice work! Have you been in contact with the Bochs developers to see >> what their thoughts are to your proposed changes? Generally QEMU >> prefers to implement documented specifications, so this would be the >> best route to go. > > Thanks! I don't think it would be appropriate to update the Bochs > standard with a feature that they don't use. And on reflection, perhaps > the compatibility-oriented VGA device is big enough already. > > My plan is to write a Mac OS 9/X "ndrv" targeting virtio-gpu. All going > this well, this might become the default mac99 GPU until ati-vga is > ready. Once you have a full virtio driver there's likely not much reason to use ati-vga as virtio-gpu should be better with no legacy stuff that ati-vga has to emulate which may limit its performance and make it more complex than it could be without all those compatibility layers. The ati-vga approach is good if you have a legacy guest which already has an ATI driver but can't or don't want to write a new driver for it. If you can write a new guest driver then you could put the effort there and target virtio instead. Both ways are probably a lot of work, virtio might give better end results but will be specific to the guests you write the driver for while ati-vga would be usable for all guests without needing to change them. Since I have three Amiga like guests of which two are closed source and no published driver API the best option for me was ati-vga but for Mac OS virtio might be a good option if somebody puts in the needed effort. > But virtio-gpu is not compiled into qemu-system-ppc by default. What is > the difference between CONFIG_VIRTIO_(GPU|PCI|VGA)? And is > configs/devices/ppc-softmmu/default.mak the correct place to declare > them? Probably Gerd can provide better advice but in my (very limited) understanding the difference between them is what interfaces do they provide. VIRTIO_GPU is likely the base which selected by the other two. This plain device needs some way to let the guest know about it (could use some firware specific way and then the devices tree for example) but there's a more standard way: the PCI one appears to the guest as a PCI device so it can detect/configure it via standard methods it already knows. The VGA one also has VGA compatibility so you don't need a firmware driver but can boot it as a normal VGA device then your driver can switch it into virtio mode once the guest started. Maybe you can start with this last one then see if it can be simplified later or works well enough. Here are some info I've found that may help to get started: https://www.linux-kvm.org/images/0/09/Qemu-gfx-2016.pdf https://www.studiopixl.com/2017-08-27/3d-acceleration-using-virtio.html The course of action to follow in my opinion might be: 1. Get vitio-vga to compile with mac99 2. Try if guest still boots with it (due to the VGA compatibility it probably should but won't use the virtio part yet) 3. Start writing the driver so that it detects the card but does nothing with it yet 4. Enhance the driver so it can switch the card in virtio mode and can communicate with it 5. Set up framebuffer and hwcutsor via virtio and get some basic graphics going 6. Add 2D accel if applicable 7. Explore adding 3D support (this is far away yet, maybe don't even consider it before all the above steps to cut down complexity; even if this is the final goal the basis should be there first so concentrate on those now). But you know better what and how you want to do, I just shared my thoughts in the hope it might be useful. If not you're free to ignore it. Regards, BALATON Zoltan
On 07/08/2022 12:47, Elliot Nunn wrote: >>> I want to give Mac OS 9 clients access to hardware cursor support, to improve >>> responsiveness in absolute-cursor mode. >>> Would it be acceptable to add a hardware cursor interface to the VGA device? >>> And if so, can anyone advise on an appropriate register layout? >>> This is an example of such a patch. Because it alters the Bochs VBE interface >>> it is ONLY an example, NOT fit for acceptance. I have omitted the changes to >>> the binary driver qemu_vga.ndrv. >>> Kind regards, >>> Elliot Nunn >> Nice work! Have you been in contact with the Bochs developers to see what their thoughts are to your proposed changes? Generally QEMU prefers to implement documented specifications, so this would be the best route to go. > > Thanks! I don't think it would be appropriate to update the Bochs standard with a feature that they don't use. And on reflection, perhaps the compatibility-oriented VGA device is big enough already. Sure, no worries. > My plan is to write a Mac OS 9/X "ndrv" targeting virtio-gpu. All going this well, this might become the default mac99 GPU until ati-vga is ready. That sounds really interesting. Is there a forum/mailing list somewhere where it is possible to follow the Mac side of your work? I can certainly advise on the qemu-system-ppc side. > But virtio-gpu is not compiled into qemu-system-ppc by default. What is the difference between CONFIG_VIRTIO_(GPU|PCI|VGA)? And is configs/devices/ppc-softmmu/default.mak the correct place to declare them? You probably want to add a "select VIRTIO_GPU_PCI" and/or "select VIRTIO_GPU_VGA" in the "config MAC_NEWWORLD" section of hw/ppc/Kconfig to enable the virtio devices for the mac99 machine. ATB, Mark.
On Sun, 7 Aug 2022, Mark Cave-Ayland wrote: > On 07/08/2022 12:47, Elliot Nunn wrote: > >>>> I want to give Mac OS 9 clients access to hardware cursor support, to >>>> improve >>>> responsiveness in absolute-cursor mode. >>>> Would it be acceptable to add a hardware cursor interface to the VGA >>>> device? >>>> And if so, can anyone advise on an appropriate register layout? >>>> This is an example of such a patch. Because it alters the Bochs VBE >>>> interface >>>> it is ONLY an example, NOT fit for acceptance. I have omitted the changes >>>> to >>>> the binary driver qemu_vga.ndrv. >>>> Kind regards, >>>> Elliot Nunn >>> Nice work! Have you been in contact with the Bochs developers to see what >>> their thoughts are to your proposed changes? Generally QEMU prefers to >>> implement documented specifications, so this would be the best route to >>> go. >> >> Thanks! I don't think it would be appropriate to update the Bochs standard >> with a feature that they don't use. And on reflection, perhaps the >> compatibility-oriented VGA device is big enough already. > > Sure, no worries. > >> My plan is to write a Mac OS 9/X "ndrv" targeting virtio-gpu. All going >> this well, this might become the default mac99 GPU until ati-vga is ready. > > That sounds really interesting. Is there a forum/mailing list somewhere where > it is possible to follow the Mac side of your work? I can certainly advise on > the qemu-system-ppc side. > >> But virtio-gpu is not compiled into qemu-system-ppc by default. What is the >> difference between CONFIG_VIRTIO_(GPU|PCI|VGA)? And is >> configs/devices/ppc-softmmu/default.mak the correct place to declare them? > > You probably want to add a "select VIRTIO_GPU_PCI" and/or "select > VIRTIO_GPU_VGA" in the "config MAC_NEWWORLD" section of hw/ppc/Kconfig to > enable the virtio devices for the mac99 machine. Not sure how this works but pc and pseries machines seem to have imply VIRTIO_VGA so probably that's what you need to add to config MAC_NEWWORLD or just try qemu-system-ppc64 -machine mac99,via=pmu -cpu G4 which should already have it due so pseries but may otherwise be equivalent to the one in qemu-system-ppc. Regards, BALATON Zoltan
On Sun, 7 Aug 2022, BALATON Zoltan wrote: > On Sun, 7 Aug 2022, Mark Cave-Ayland wrote: >> On 07/08/2022 12:47, Elliot Nunn wrote: >> >>>>> I want to give Mac OS 9 clients access to hardware cursor support, to >>>>> improve >>>>> responsiveness in absolute-cursor mode. >>>>> Would it be acceptable to add a hardware cursor interface to the VGA >>>>> device? >>>>> And if so, can anyone advise on an appropriate register layout? >>>>> This is an example of such a patch. Because it alters the Bochs VBE >>>>> interface >>>>> it is ONLY an example, NOT fit for acceptance. I have omitted the >>>>> changes to >>>>> the binary driver qemu_vga.ndrv. >>>>> Kind regards, >>>>> Elliot Nunn >>>> Nice work! Have you been in contact with the Bochs developers to see what >>>> their thoughts are to your proposed changes? Generally QEMU prefers to >>>> implement documented specifications, so this would be the best route to >>>> go. >>> >>> Thanks! I don't think it would be appropriate to update the Bochs standard >>> with a feature that they don't use. And on reflection, perhaps the >>> compatibility-oriented VGA device is big enough already. >> >> Sure, no worries. >> >>> My plan is to write a Mac OS 9/X "ndrv" targeting virtio-gpu. All going >>> this well, this might become the default mac99 GPU until ati-vga is ready. >> >> That sounds really interesting. Is there a forum/mailing list somewhere >> where it is possible to follow the Mac side of your work? I can certainly >> advise on the qemu-system-ppc side. >> >>> But virtio-gpu is not compiled into qemu-system-ppc by default. What is >>> the difference between CONFIG_VIRTIO_(GPU|PCI|VGA)? And is >>> configs/devices/ppc-softmmu/default.mak the correct place to declare them? >> >> You probably want to add a "select VIRTIO_GPU_PCI" and/or "select >> VIRTIO_GPU_VGA" in the "config MAC_NEWWORLD" section of hw/ppc/Kconfig to >> enable the virtio devices for the mac99 machine. > > Not sure how this works but pc and pseries machines seem to have imply > VIRTIO_VGA so probably that's what you need to add to config MAC_NEWWORLD or > just try qemu-system-ppc64 -machine mac99,via=pmu -cpu G4 which should > already have it due so pseries but may otherwise be equivalent to the one in > qemu-system-ppc. I've tried this: qemu-system-ppc64 -M mac99,via=pmu -cpu G4 -m 512 \ -vga none -device virtio-vga,romfile=qemu_vga.ndrv \ -cdrom "Mac OS 9.2.2 Universal Install.iso" -boot d \ -serial stdio to see if it recognised the card in vga mode but it does not work. (Without the second line disabling stdvga and adding virtio-vgs this does boot for me.) The problem seems to be that openbios does not recognise the rom, maybe because it expects the rom to be at BAR 6 and only tries to map that but virtio-vga seems to have rombar=1 by default (see info qtree in monitor). I did not try if it's settable though so maybe adding virtio-vga,rombar=6 could get it further? Regards, BALATON Zoltan
On Mon, 8 Aug 2022, BALATON Zoltan wrote: > On Sun, 7 Aug 2022, BALATON Zoltan wrote: >> On Sun, 7 Aug 2022, Mark Cave-Ayland wrote: >>> On 07/08/2022 12:47, Elliot Nunn wrote: >>> >>>>>> I want to give Mac OS 9 clients access to hardware cursor support, to >>>>>> improve >>>>>> responsiveness in absolute-cursor mode. >>>>>> Would it be acceptable to add a hardware cursor interface to the VGA >>>>>> device? >>>>>> And if so, can anyone advise on an appropriate register layout? >>>>>> This is an example of such a patch. Because it alters the Bochs VBE >>>>>> interface >>>>>> it is ONLY an example, NOT fit for acceptance. I have omitted the >>>>>> changes to >>>>>> the binary driver qemu_vga.ndrv. >>>>>> Kind regards, >>>>>> Elliot Nunn >>>>> Nice work! Have you been in contact with the Bochs developers to see >>>>> what their thoughts are to your proposed changes? Generally QEMU prefers >>>>> to implement documented specifications, so this would be the best route >>>>> to go. >>>> >>>> Thanks! I don't think it would be appropriate to update the Bochs >>>> standard with a feature that they don't use. And on reflection, perhaps >>>> the compatibility-oriented VGA device is big enough already. >>> >>> Sure, no worries. >>> >>>> My plan is to write a Mac OS 9/X "ndrv" targeting virtio-gpu. All going >>>> this well, this might become the default mac99 GPU until ati-vga is >>>> ready. >>> >>> That sounds really interesting. Is there a forum/mailing list somewhere >>> where it is possible to follow the Mac side of your work? I can certainly >>> advise on the qemu-system-ppc side. >>> >>>> But virtio-gpu is not compiled into qemu-system-ppc by default. What is >>>> the difference between CONFIG_VIRTIO_(GPU|PCI|VGA)? And is >>>> configs/devices/ppc-softmmu/default.mak the correct place to declare >>>> them? >>> >>> You probably want to add a "select VIRTIO_GPU_PCI" and/or "select >>> VIRTIO_GPU_VGA" in the "config MAC_NEWWORLD" section of hw/ppc/Kconfig to >>> enable the virtio devices for the mac99 machine. >> >> Not sure how this works but pc and pseries machines seem to have imply >> VIRTIO_VGA so probably that's what you need to add to config MAC_NEWWORLD >> or just try qemu-system-ppc64 -machine mac99,via=pmu -cpu G4 which should >> already have it due so pseries but may otherwise be equivalent to the one >> in qemu-system-ppc. > > I've tried this: > > qemu-system-ppc64 -M mac99,via=pmu -cpu G4 -m 512 \ > -vga none -device virtio-vga,romfile=qemu_vga.ndrv \ > -cdrom "Mac OS 9.2.2 Universal Install.iso" -boot d \ > -serial stdio > > to see if it recognised the card in vga mode but it does not work. (Without > the second line disabling stdvga and adding virtio-vgs this does boot for > me.) The problem seems to be that openbios does not recognise the rom, maybe > because it expects the rom to be at BAR 6 and only tries to map that but > virtio-vga seems to have rombar=1 by default (see info qtree in monitor). I > did not try if it's settable though so maybe adding virtio-vga,rombar=6 could > get it further? I've tried with rombar=6 but it made no change. I don't fully get how this should work. Even by default when rombar=1 the virtio-vga device does not seem to have BAR 1 but has a BAR 6. Openbios seems to look for that but maybe only for vga devices it knows about. I thought it would also look for device class but maybe it needs to be added to openbios's pci database for it to recognise and try to detect an NDRV in ROM? Maybe Mark could look at it and advise. I think I gave up here, don't want to debug this further but getting MacOS 9 boot with virtio-vga in vga mode would give Elliot a good start to experiment with ndrv and not fight with QEMU and OpenBIOS instead just to get started. Regards, BALATON Zoltan
© 2016 - 2024 Red Hat, Inc.