From: BALATON Zoltan <balaton@eik.bme.hu>
To: Chad Jablonski <chad@jablonski.xyz>
Cc: qemu-devel@nongnu.org, "Gerd Hoffmann" <kraxel@redhat.com>,
marcandre.lureau@redhat.com,
"Philippe Mathieu-Daudé" <philmd@linaro.org>
Subject: Re: [PATCH v6 7/8] ati-vga: Simplify pointer image handling
Date: Tue, 24 Mar 2026 15:49:53 +0100 (CET) [thread overview]
Message-ID: <fa102b60-4b0d-7d70-81b1-dc145ee8b5f0@eik.bme.hu> (raw)
In-Reply-To: <DHB2SIE9XM4F.38ZR2LJ2F670B@jablonski.xyz>
On Tue, 24 Mar 2026, Chad Jablonski wrote:
>> /* FIXME handle cur_hv_offs correctly */
>> + srcoff = s->regs.cur_offset - (s->regs.cur_hv_offs >> 16) -
>> + (s->regs.cur_hv_offs & 0xffff) * 16;
>
> This is pre-existing (and a FIXME!) but do we want to be subtracting the
> horizontal cursor offset (s->regs.cur_hv_offs >> 16) here? I think when
> it's non-zero it would mean that the first row of the cursor would be offset
> and rows would contain bytes from the next row at the end. The way I read the
> register reference is that the horizontal offset is the number of columns the
> cursor is shifted. So I don't think this would affect the source, just how it's drawn.
As you say it's preexisting and I did not try to fix that and left the
FIXME comment there. I haven't seen anything using hv_offset so far except
the Linux test image at the very left and top of the screen but that also
has other problems with the mouse pointer so unless it's first confirmed
on real hardware that it's supposed to work I won't try to fix that
because I tested MacOS that also uses big endian frame buffer and that
works now so it might be the Linux driver is buggy or there's some other
swap bit somewhere we should take into account. As nothing else seems to
use non-0 hv_offset this should not matter for most drivers so until we
see something that needs it and we can test with I leave it a FIXME.
>> + for (int i = 0; i < 64; i++, srcoff += 16) {
>> + data[i] = ldq_le_p(&s->vga.vram_ptr[srcoff]);
>> + data[i + 64] = ldq_le_p(&s->vga.vram_ptr[srcoff + 8]);
>
> Is this ldq_le_p correct here? Wouldn't this cause issues on BE hosts?
I'm not sure as I noted in commit message. According to the docs I've seen
hw cursor data should always be little endian and if we pass these on as
host endian data here then le should be correct but I could not test on
big endian host so can't say for sure.
Regards,
BALATON Zoltan
next prev parent reply other threads:[~2026-03-24 14:50 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-21 16:30 [PATCH v6 0/8] ati-vga fixes BALATON Zoltan
2026-03-21 16:30 ` [PATCH v6 1/8] ati-vga: Fix colors when frame buffer endianness does not match host BALATON Zoltan
2026-03-21 16:30 ` [PATCH v6 2/8] ati-vga: Also switch mode on HW cursor enable bit change BALATON Zoltan
2026-03-21 16:30 ` [PATCH v6 3/8] ati-vga: Do not add crtc offset to src and dst data address BALATON Zoltan
2026-03-21 16:30 ` [PATCH v6 4/8] ati-vga: Avoid warnings about sign extension BALATON Zoltan
2026-03-21 16:30 ` [PATCH v6 5/8] ati-vga: Fix display updates in non-32 bit modes BALATON Zoltan
2026-03-21 16:30 ` [PATCH v6 6/8] ati-vga: Add work around for fuloong2e BALATON Zoltan
2026-03-21 16:30 ` [PATCH v6 7/8] ati-vga: Simplify pointer image handling BALATON Zoltan
2026-03-23 12:21 ` Philippe Mathieu-Daudé
2026-03-23 12:25 ` Philippe Mathieu-Daudé
2026-03-23 13:39 ` BALATON Zoltan
2026-03-23 13:38 ` BALATON Zoltan
2026-03-24 14:17 ` Chad Jablonski
2026-03-24 14:49 ` BALATON Zoltan [this message]
2026-03-25 13:10 ` Chad Jablonski
2026-03-21 16:30 ` [PATCH v6 8/8] ati-vga: Make sure hardware cursor data is within vram BALATON Zoltan
2026-03-24 13:29 ` Chad Jablonski
2026-03-23 12:01 ` [PATCH v6 0/8] ati-vga fixes BALATON Zoltan
2026-03-24 13:38 ` Michael Tokarev
2026-03-24 14:31 ` Michael Tokarev
2026-03-24 14:39 ` BALATON Zoltan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fa102b60-4b0d-7d70-81b1-dc145ee8b5f0@eik.bme.hu \
--to=balaton@eik.bme.hu \
--cc=chad@jablonski.xyz \
--cc=kraxel@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox