Sl6000 Hardware Accelerated Display?, Anyone figured out how to use it? Options

[cwaig]

I've been looking at the kernel source for the SL6000's framebuffer driver, and I can see an API provided to access the hardware acceleration - but it's documentation is pretty much zero

The only example of it being actually used in the driver itself is the tc6393_clear_screen() function, that uses the hardware rectangle fill to clear the screen. There's a very interesting looking command set provided in the tc6393fb.h file, and an ioctl provided to pass lists of commands to the graphics hardware for processing - but the actual commands (although defined) aren't actually documented

The clear screen example in the driver is
static u32 cmd[6];
cmd[0] = PXAIO_COMDI_DSADR|PXAIO_COMDD_DSADR(((int)remapped_fbuf));
cmd[1] = PXAIO_COMDI_DHPIX|PXAIO_COMDD_DHPIX(xres - 1);
cmd[2] = PXAIO_COMDI_DVPIX|PXAIO_COMDD_DVPIX(yres - 1);
cmd[3] = PXAIO_COMDI_FILL|PXAIO_COMDD_FILL(0xffff);
cmd[4] = PXAIO_COMDI_FLGO;

Using the ioctl interface to the framebuffer, this would be:
static u32 cmd[6];
cmd[0] = 5;
cmd[1] = PXAIO_COMDI_DSADR|PXAIO_COMDD_DSADR(((int)remapped_fbuf));
cmd[2] = PXAIO_COMDI_DHPIX|PXAIO_COMDD_DHPIX(xres - 1);
cmd[3] = PXAIO_COMDI_DVPIX|PXAIO_COMDD_DVPIX(yres - 1);
cmd[4] = PXAIO_COMDI_FILL|PXAIO_COMDD_FILL(0xffff);
cmd[5] = PXAIO_COMDI_FLGO;
ioctl(fbHandle,TC6393FB_ACC_CMD_WRITE,cmd);

and then I'm guessing that if you want to make sure it's completed before carrying on, you can use:
ioctl(fbHandle,TC6393FB_ACC_SYNC,0);

But the tc6393 looks like it can do blitting as well....I've no idea what the rest of the command API def's actually do though?

And glory be - Toshiba haven't released a datasheet for the chip
When I eventually get my hands on my SL6000 (my wife's hidden it 'til Christmas) I'll start trying some of the commands, see if I can work it out through trial & error.....unless someone else beats me to it of course

SDL would go much quicker with a bit of the ol' hardware accel...

[guylhem]

without the chip technical manual, no hope.

[mahadri]

Sharp's tc6393fb.h has enough information to experiment. First, I'd try modifying the fill command to draw colored boxes on the screen. This is very useful for accelerating window managers, as they tend to draw the backing color, then the objects on top. The source copy would be great for moving windows, scrolling windows, scrolling the console, and drawing console characters.

The TC6393 has 1MB of video memory. The default 640x480x16bit mode only uses 600kB, leaving 424kB for console fonts, bitmaps, etc, for source copy. Also, 424kB is enough for one large 528x400 buffer. With a custom mplayer plugin, mplayer can render to that off-screen buffer, then StretchBLT the buffer to the 640x480 screen. It looks like StretchBLT has vertical reverse and horizontal reverse options, too, so you can flip horizontal, or flip vertical, or rotate the video 180 degrees in hardware.

I'm working on the 2.6 kernel at the moment, and I'll work on video acceleration at some point (it's a low priority, so it could be a while). If someone wants to experiment and help out, that'd be even better. =)

The TC6393's LCD controller has five accelration commands:
PXAIO_COMDI_CMGO - Cursor Move?
PXAIO_COMDI_FLGO - Fill
PXAIO_COMDI_SCGO - Source Copy
PXAIO_COMDI_SBGO - StretchBLT
PXAIO_COMDI_LDGO - Line Draw

Out of the set commands, we can group by ones that take a pixel color as a paremeter:
PXAIO_COMDI_FILL - fill color
PXAIO_COMDI_TCLOR - transparent color for Source Copy

ones that take a memory address as a parameter:
PXAIO_COMDI_CSADR - cursor screen address?
PXAIO_COMDI_PSADR - physical screen address?
PXAIO_COMDI_POADR - physical offset address?
PXAIO_COMDI_DSADR - destination screen address?
PXAIO_COMDI_SSADR - source screen address?

and ones that take a x or y offset or pixel count as a parameter:
PXAIO_COMDI_CHPIX - cursor horizontal pixels?
PXAIO_COMDI_CVPIX - cursor vertical pixels?
PXAIO_COMDI_PHPIX - physical horizontal pixels?
PXAIO_COMDI_PVPIX - physical vertical pixels?
PXAIO_COMDI_PHOFS - physical horizontal offset?
PXAIO_COMDI_PVOFS - physical vertical offset?
PXAIO_COMDI_DHPIX - destination horizontal pixels
PXAIO_COMDI_DVPIX - destination vertical pixels
PXAIO_COMDI_SHPIX - source horizontal pixels?
PXAIO_COMDI_SVPIX - source vertical pixels?

[speculatrix]

Sharp's tc6393.h has enough information to experiment.  First, I'd try modifying the fill command

this sounds very promising. Perhaps with the re-release of the 6000 as a windows mobile device more information will come out too.

Whilst I'd love to help, I'm only running kernel 2.4 on the Guylhem ROM, sorry :-(

I've also no experience at actually writing kernel modules. But, I'd be willing to give back-porting the driver to 2.4.x a shot, or even being a guinea pig if I can.

If nothing else, be encouraged that there are lots of eager people waiting for faster video drivers for their 6000!

Paul

[mahadri]

this sounds very promising. Perhaps with the re-release of the 6000 as a windows mobile device more information will come out too.

I could reverse-engineer those drivers if they implement a feature we like.

Whilst I'd love to help, I'm only running kernel 2.4 on the Guylhem ROM, sorry :-(

The Sharp kernel exports an ioctl for video acceleration. I doubt any Sharp-based ROM removed this ioctl, so you can test from userspace. You just need a cross-compiler to compile tosaacc.c. It's a simple program that uses the Fill command to clear the screen to a color specified on the command line.

Usage: tosaacc <color in hex>
Example: tosaacc 48c0

If there's enough demand from people without cross-compilers, I can modify this program to read accelerator commands from stdin so I can distribute a binary version. It's not as nice, though, as you can't use Sharp's #defines and would have to write all commands in hex.