Use the same color-calculating algorithm as in atyfb_imageblit in this driver
or in generic cfb_fillrect.
This patch fixes bad colors when using an accelerator in 15-bit and 16-bit
modes.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com
---
drivers/video/aty/mach64_accel.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
Index: linux-2.6.30-fast/drivers/video/aty/mach64_accel.c
===================================================================
@@ -250,8 +250,11 @@ void atyfb_fillrect(struct fb_info *inforeturn;}-color|=(rect->color<<8);-color|=(rect->color<<16);+if(info->fix.visual==FB_VISUAL_TRUECOLOR||+info->fix.visual==FB_VISUAL_DIRECTCOLOR)+color=((u32*)(info->pseudo_palette))[rect->color];+else+color=rect->color;if(info->var.bits_per_pixel==24){/* In 24 bpp, the engine is in 8 bpp - this requires that all */------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
On my card, the accelerator corrupts display if its line length is not
multiple of 64 bytes.
Misaligned lines in the drawn recrangle are shifted left, as if the accelerator
thought that every line begins on 64-byte boundary. For example, in 800x600x8
(scanlines are aligned on 32 bytes) every odd scanline is drawn shifted by
32 bytes to the left.
The card is ATI Technologies Inc 3D Rage Pro 215GP (rev 5c) onboard on
Sparc64 Ultra 5.
This patch disables accelerator if scanline is not multiple of 64 bytes.
I don't have any other cards to test. If someone tests that his card doesn't
have this bug, he can whitelist it.
(note: if you find a better place where to disable the accelerator on
non-conforming modes, do it there)
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com
---
drivers/video/aty/mach64_accel.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
Index: linux-2.6.30-fast/drivers/video/aty/mach64_accel.c
===================================================================
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
From: Ville Syrjälä <syrjala@sci.fi> Date: 2009-06-17 17:22:05
On Wed, Jun 17, 2009 at 06:02:30AM -0400, Mikulas Patocka wrote:
On my card, the accelerator corrupts display if its line length is not
multiple of 64 bytes.
Misaligned lines in the drawn recrangle are shifted left, as if the accelerator
thought that every line begins on 64-byte boundary. For example, in 800x600x8
(scanlines are aligned on 32 bytes) every odd scanline is drawn shifted by
32 bytes to the left.
The card is ATI Technologies Inc 3D Rage Pro 215GP (rev 5c) onboard on
Sparc64 Ultra 5.
I think normally the offset should be just aligned to 8 bytes and pitch
to 8 bytes and 8 pixels.
I was under the impression that 64 byte aligned offset and pitch are only
required if block writes are used. But perhaps it is always required
with SGRAM/WRAM, or perhaps you have auto block writes enabled. Can you
check the memory type and the the value of the HW_DEBUG register?
This patch disables accelerator if scanline is not multiple of 64 bytes.
A better option would be to round the pitch up in check_var(). Also it
would be more proper to use fix.line_length as the pitch value instead
of var.xres_virtual. That way check_var() could leave var.xres_virtual
alone and just round fix.line_length to whatever is required.
Actually now that I think about it I would prefer to round to 64 bytes
always when SGRAM/WRAM is found. The reason is that the mach64 DirectFB
driver always enables auto block writes on SGRAM boards and if atyfb
uses less alignment things will not work correctly. Perhaps atyfb should
enable auto block writes too.
--
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
From: Ville Syrjälä <syrjala@sci.fi> Date: 2009-06-17 17:24:28
On Wed, Jun 17, 2009 at 06:00:53AM -0400, Mikulas Patocka wrote:
Use the same color-calculating algorithm as in atyfb_imageblit in this driver
or in generic cfb_fillrect.
This patch fixes bad colors when using an accelerator in 15-bit and 16-bit
modes.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com
Acked-by: Ville Syrjala <syrjala@sci.fi>
--
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
On Wed, Jun 17, 2009 at 06:02:30AM -0400, Mikulas Patocka wrote:
quoted
On my card, the accelerator corrupts display if its line length is not
multiple of 64 bytes.
Misaligned lines in the drawn recrangle are shifted left, as if the accelerator
thought that every line begins on 64-byte boundary. For example, in 800x600x8
(scanlines are aligned on 32 bytes) every odd scanline is drawn shifted by
32 bytes to the left.
The card is ATI Technologies Inc 3D Rage Pro 215GP (rev 5c) onboard on
Sparc64 Ultra 5.
I think normally the offset should be just aligned to 8 bytes and pitch
to 8 bytes and 8 pixels.
I was under the impression that 64 byte aligned offset and pitch are only
required if block writes are used. But perhaps it is always required
with SGRAM/WRAM, or perhaps you have auto block writes enabled. Can you
check the memory type and the the value of the HW_DEBUG register?
Memory is SGRAM M32L1632512A-8Q. See this:
http://www.digchip.com/datasheets/parts/datasheet/581/M32L1632512A.php
The status line is:
atyfb: 3D RAGE PRO (Mach64 GP, PQFP, PCI) [0x4750 rev 0x7c]
atyfb: 4M SGRAM (1:1), 14.31818 MHz XTAL, 230 MHz PLL, 100 Mhz MCLK, 100
MHz XCLK
The debug register is zero (printed with printk("ATI INIT ENGINE, DEBUG
%08X", aty_ld_le32(HW_DEBUG, par)); at the end of aty_init_engine).
quoted
This patch disables accelerator if scanline is not multiple of 64 bytes.
A better option would be to round the pitch up in check_var(). Also it
would be more proper to use fix.line_length as the pitch value instead
of var.xres_virtual. That way check_var() could leave var.xres_virtual
alone and just round fix.line_length to whatever is required.
Actually now that I think about it I would prefer to round to 64 bytes
always when SGRAM/WRAM is found. The reason is that the mach64 DirectFB
driver always enables auto block writes on SGRAM boards and if atyfb
uses less alignment things will not work correctly. Perhaps atyfb should
enable auto block writes too.
So patch it to align line length (I don't know fb well to pick the right
place) and send me the patch and I'll test it.
BTW. why doesn't it use accelerator for screen scrolling? It seems to
redraw all non-empty characters, which is fast if most of the screen is
empty but gets slower if the screen is full of text.
Mikulas
From: Krzysztof Helt <hidden> Date: 2009-06-17 21:32:20
On Wed, 17 Jun 2009 06:00:53 -0400 (EDT)
Mikulas Patocka [off-list ref] wrote:
Use the same color-calculating algorithm as in atyfb_imageblit in this driver
or in generic cfb_fillrect.
This patch fixes bad colors when using an accelerator in 15-bit and 16-bit
modes.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com
Acked-by: Krzysztof Helt <redacted>
----------------------------------------------------------------------
Masz juz dosc wysokich rachunkow? Wygraj nowa mozliwosc komunikacji!
Sprawdz >>> http://link.interia.pl/f21d2
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
From: Ville Syrjälä <syrjala@sci.fi> Date: 2009-06-20 21:25:34
On Wed, Jun 17, 2009 at 05:05:31PM -0400, Mikulas Patocka wrote:
On Wed, 17 Jun 2009, Ville Syrjälä wrote:
quoted
I was under the impression that 64 byte aligned offset and pitch are only
required if block writes are used. But perhaps it is always required
with SGRAM/WRAM, or perhaps you have auto block writes enabled. Can you
check the memory type and the the value of the HW_DEBUG register?
Memory is SGRAM M32L1632512A-8Q. See this:
http://www.digchip.com/datasheets/parts/datasheet/581/M32L1632512A.php
The status line is:
atyfb: 3D RAGE PRO (Mach64 GP, PQFP, PCI) [0x4750 rev 0x7c]
atyfb: 4M SGRAM (1:1), 14.31818 MHz XTAL, 230 MHz PLL, 100 Mhz MCLK, 100
MHz XCLK
The debug register is zero (printed with printk("ATI INIT ENGINE, DEBUG
%08X", aty_ld_le32(HW_DEBUG, par)); at the end of aty_init_engine).
OK then it has auto block writes enabled.
quoted
quoted
This patch disables accelerator if scanline is not multiple of 64 bytes.
A better option would be to round the pitch up in check_var(). Also it
would be more proper to use fix.line_length as the pitch value instead
of var.xres_virtual. That way check_var() could leave var.xres_virtual
alone and just round fix.line_length to whatever is required.
Actually now that I think about it I would prefer to round to 64 bytes
always when SGRAM/WRAM is found. The reason is that the mach64 DirectFB
driver always enables auto block writes on SGRAM boards and if atyfb
uses less alignment things will not work correctly. Perhaps atyfb should
enable auto block writes too.
So patch it to align line length (I don't know fb well to pick the right
place) and send me the patch and I'll test it.
I cooked up a patch and briefly tested it on my Dell Inspiron 7000
which has an LT Pro /w SGRAM. I will send it as part of a series now.
--
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/
------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org