qemu-stable
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 5/5] hw/display/artist: Fix framebuffer access for Linux


From: Sven Schnelle
Subject: Re: [PATCH 5/5] hw/display/artist: Fix framebuffer access for Linux
Date: Sat, 15 Jan 2022 19:36:41 +0100

Sven Schnelle <svens@stackframe.org> writes:

> Philippe Mathieu-Daudé <f4bug@amsat.org> writes:
>
>> +Sven
>>
>> On 12/1/22 22:07, Helge Deller wrote:
>>> This patch fixes two problems which prevented Linux to access the
>>> artist graphics framebuffer:
>>> The check if the framebuffer or the color map should be accessed was
>>> incomplete. By using the vram_read/write_bufidx() functions we now check
>>> correctly if ARTIST_BUFFER_CMAP should be accessed.
>>> The second fix is to correctly calculate the X- and Y-coordinates
>>> and
>>> check against the graphics resolution.
>>> With this fix in place, the Linux stifb driver now works correctly,
>>> shows the penguins at bootup and uses the stifb as graphics console.
>>
>> Cool, could you add a test similar to these?
>>
>> $ git grep Tux tests/avocado/
>> tests/avocado/machine_arm_integratorcp.py:69:        Boot Linux and
>> verify the Tux logo is displayed on the framebuffer.
>> tests/avocado/machine_mips_malta.py:44:        Boot Linux kernel and
>> check Tux logo is displayed on the framebuffer.
>>
>>> I haven't seen any negative side effects when running HP-UX.
>

> Hmm, the patch below  breaks hp-ux 10.20 for me, please see the
> attached screenshot.

I think my initial thought that the register 118000 is the buffer access
mode for the color map is just wrong. I think it's setting the SRC & DST
buffer access mode at the same time because on the Visualize FX cards
we have similar registers:

#define B2_FBC_BABoth                     0x00920804 /* DBA & SBA (reads return 
DBA) (RW) */
#define B2_FBC_DBA                        0x00920808 /* Destination Bitmap 
Access Register (RW) */
#define B2_FBC_SBA                        0x0092080C /* Source Bitmap Access 
Register (RW) */

Looking at Artist, we have:

CMAP_BM_ACCESS = 0x118000
DST_BM_ACCESS = 0x118004
SRC_BM_ACCESS = 0x118008

Given that artist and visualize fx are very similar when it comes to 2D
acceleration, i think CMAP_BM_ACCESS is just changing both registers,
completely unrelated to the color map. I tried changing the code, but
of course that breaks a lot of things. Let me see whether i can make
that work.

/Sven



reply via email to

[Prev in Thread] Current Thread [Next in Thread]