On Mon, 30 Oct 2023, Mark Cave-Ayland wrote:
On 30/10/2023 10:37, BALATON Zoltan wrote:
On Mon, 23 Oct 2023, BALATON Zoltan wrote:
On Tue, 10 Oct 2023, BALATON Zoltan wrote:
Some misc patches I had laying around that could be upstreamed just to
clean up my tree a bit.
Ping? Is Gerd still the maintainer of gfx or who else should be cc'd on
such patches?
Ping^2
Regards,
BALATON Zoltan
BALATON Zoltan (3):
ati-vga: Fix aperture sizes
ati-vga: Support unaligned access to GPIO DDC registers
ati-vga: Add 30 bit palette access register
hw/display/ati.c | 50 ++++++++++++++++++++++++++++---------------
hw/display/ati_dbg.c | 1 +
hw/display/ati_int.h | 1 +
hw/display/ati_regs.h | 1 +
4 files changed, 36 insertions(+), 17 deletions(-)
Slightly off-topic, but are there any known issues with the ati-vga device
(hardware?) cursor handling? At least here with testing MorphOS with -display
gtk, the guest unconditionally grabs the mouse and it's impossible to release
it. Within the windows itself the mouse "skids" which means I can't get to
the edge of the window to close it, and so I end up having to switch to a
text console and kill QEMU to be able to access the desktop again.
Try -device ati-vga,guest_hwcursor=true that may work better. There are
two ways in QEMU to handle HW cursor and the default is to let the host
move the pointer but the problem with this in my understanding is that the
host and guest may have different mouse pointer acceleration settings so
the host pointer and guest pointer may get out of sync which causes it to
jump ot lag. There's another API which does it differently and let the
guest dictate where the pointer is which does not get out of sync but may
freeze or jump if the guest is busy. Or something like that. I've
implemented both in ati-vga as first it used the host pointer but others
also reported problems so added the guest_hwcursor option as well. Maybe
also using -display sdl can help as I did not get that problem with sdl.
Regards,
BALATON Zoltan