Hi Alex, Sven, and Denis,
On Friday 02 August 2002 03:14, Alex Song wrote:
> > > > the accelerated functions simple don't seem to have any effect which
> > > > means that the screen is not cleared and not scrolled. Fortunately
> > > > this is harmless and acceleration can be turned off using the command
> > > > 'fbset -accel false' which makes the 0.4.0 version of the driver
> > > > behave like the 0.3.2 version.
>
> yes, i have noticed this. i am currently trying to debug the accelerated
> clear function which is really a fill rectangle. the function is being
> called but the screen is not being cleared for some reason. don't know what
> is wrong yet, have to debug some more.
So perhaps I can help you. Yesterday I have invested some hours of
testing with the directfb kernel driver. As I stated some mails before,
I already hacked an Savage driver for our local project which supports
accelerated clear, copy and yuv2rgb conversion. The driver was hacked
from the XFree86 sources and directfb sources.
In the meantime I have received the Savage documentation from dok (thanks!).
But nevertheless, my knowledge of the Savage chipset is very poor. So my
strategy for finding bugs in this context is to compare the several sources,
to analyze the source comments and to find differences.
So I don't want to post a patch here because I hope that Alex or Sven
are more competent. I only want to point out some things I've found.
The kernel driver has at least two bugs, both in the SavageSetup2DEngine:
=== begin cut ===
static void
SavageSetup2DEngine (struct savagefb_info *info,
const struct savagefb_par *par)
{
unsigned long GlobalBitmapDescriptor;
GlobalBitmapDescriptor = 1 | 8 | BCI_BD_BW_DISABLE;
BCI_BD_SET_BPP (GlobalBitmapDescriptor, par->depth);
^^^^^^^^^^
BCI_BD_SET_STRIDE (GlobalBitmapDescriptor, par->vwidth);
^^^^^^^^^^^^
/* Disable BCI */
savage_out32 (0x48C18, savage_in32 (0x48C18) & 0x3FF0);
=== end cut ===
Some debug printk's showed me, that par->depth and par->vwidth
are ZERO when calling SavageSetup2DEngine. So the first quick
hack I did was to replace the variables with fixed values
(here 8 and 1024). Sure, the driver should include the proper
variables here.
The second bug is comes some lines later:
=== begin cut ===
/* Enable 2D engine. */
vga_out8 (0x3d4, 0x40 );
vga_out8 (0x3d4, 0x01 );
^^^^^
=== end cut ===
So the 2D engine was never activated because the data register was never
written.
But after fixing these two issues, the driver still did'nt work. Tim Roberts
inserted a small comment in the XFree86 driver in the context of the Savage
accel functions (savage_accel.c, line 308):
=== begin cut ===
/* Use and set global bitmap descriptor. */
/* For reasons I do not fully understand yet, on the Savage4, the */
/* write to the GBD register, MM816C, does not "take" at this time. */
/* Only the low-order byte is acknowledged, resulting in an incorrect */
/* stride. Writing the register later, after the mode switch, works */
/* correctly. This needs to get resolved. */
SavageSetGBD(pScrn);
=== end cut ===
This comment pointed me out that the Savage chips are fragile beasts.
I tried to initialize the GBD register several times, not only one time.
At the same time I changed the order of some lines and changed the code
to write the GBD register to that of the XFree86 driver. The result was:
=== begin cut ===
savage_out32 (MONO_PAT_0, ~0);
savage_out32 (MONO_PAT_1, ~0);
/* Setup plane masks */
savage_out32 (0x8128, ~0 ); /* enable all write planes */
savage_out32 (0x812C, ~0 ); /* enable all read planes */
savage_out16 (0x8134, 0x27 );
savage_out16 (0x8136, 0x07 );
for (i=0; i<2; i++)
{
/* Turn on 16-bit register access. */
vga_out8(0x3d4, 0x31);
vga_out8(0x3d5, 0x0c);
/* Set stride to use GBD. */
vga_out8 (0x3d4, 0x50);
vga_out8 (0x3d5, vga_in8 (0x3d5 ) | 0xC1);
/* Enable 2D engine. */
vga_out8 (0x3d4, 0x40 );
vga_out8 (0x3d5, 0x01 );
/* Now set the GBD */
info->SavageWaitIdle (info);
savage_out32 (0x8168, 0);
savage_out32 (0x816c, GlobalBitmapDescriptor);
savage_out32 (0x8170, 0);
savage_out32 (0x8174, GlobalBitmapDescriptor);
savage_out32 (0x8178, 0);
savage_out32 (0x817C, GlobalBitmapDescriptor);
savage_out32 (0x81c8, 1024);
savage_out32 (0x81d8, 1024);
}
}
=== end cut ===
All three fixes together made the driver work for me: Accelerated
scroll and accelerated clear.
But there is another issue which perhaps could be fixed by people with
more knowledge about that: After doing some scrolling, the same problem
rises as before with the buggy driver: Clear and scroll doesn't work
anymore. But: After switching to another virtual console and back,
everything is fine again.
This problem seems to have to do with the pan function of the Linux console:
Sometimes it is faster to pan the visible area inside the graphics buffer
than to move data inside the graphics buffer. The Savage accelerated functions
seems to conflict with that pan function. It should be easy to disable pan
with the savage driver, but in the moment I don't know why. Maybe we get
help from other accelerated fb drivers.
These days I'm a little bit short in time, so I couldn't debug more.
But I hope this helps.
Frank
--
Frank Mehnert
## Dept. of Computer Science, Dresden University of Technology, Germany ##
## E-Mail: [EMAIL PROTECTED] http://os.inf.tu-dresden.de/~fm3 ##
--
Info: To unsubscribe send a mail to [EMAIL PROTECTED] with
"unsubscribe directfb-dev" as subject.
