Messages

1

6000 - Tosa / Video Acceleration Fund

« on: December 09, 2005, 08:57:40 pm »

I would glady give 100 Eur to see such features. mahadri or anyone else could be interested if more people could donate.[div align=\"right\"][a href=\"index.php?act=findpost&pid=105836\"][{POST_SNAPBACK}][/a][/div]

Video acceleration is suddenly looking very interesting. =)

- kernel support for the various accels available, with sample code for each acceleration (to ease integration into applications)
 - libsdl tweaks to give a good speed to emulators (with 640x480 and 480x320 mode)

All of the TC6393's accelerations are supported by the kernel's framebuffer core, so adding framebuffer acceleration operations should accelerate the X server and all X applications without modifying them.  The same applies to OPIE and libsdl if they use the framebuffer operations (I would assume they do).

- faster scroll speed in text more (try dmesg and cry)

xenophobe recently posted the parameters for the screen copy command.  A short ~30 line kernel patch would make this a reality.  I'll look into it. =)

- a plugin for mplayer to have hi-res video support (538x400 is ok)

Are you sure acceleration is possible to any great extent? I mean a faster dmesg would be nice..but not worth much. vga video at 24 fps would be worth something....

Do we know, or have a clue, what is possible with this hardware?

I've benchmarked copying from CPU to video memory at ~9.5 MB/s, so it could theoretically do 528x400 @ 22.6 fps.  If mplayer renders to the off-screen video memory in less than 32K chunks at a time (probably in 8x8 pixel blocks, using 8 cache lines = 256 bytes), then it's possible that the CPU can cache the writes and perform them in the background while the CPU is decoding another 8x8 block.  If this is the case, then writing to video memory will not stall the CPU, and 528x400 @ 22 fps or 512x384 @ 24 fps is theoretically possible.

2

6000 - Tosa / Aaa Battery Pack Adapter Fab

« on: November 29, 2005, 05:06:40 am »

reading about the lifespan of Lithium Ion batteries has brought me to the conclusion that a new battery pack for the 6k should be designed.[div align=\"right\"][a href=\"index.php?act=findpost&pid=103380\"][{POST_SNAPBACK}][/a][/div]

Why not buy a new 3.7V Li-poly cell in about the same dimensions and replace the dead cell?  If someone has opened the pack, you could search for the cell's part number and, if it's still manufactured, buy an exact replacement.  If not, there are other cells we could use instead, but they might be less than 1500mAh.

3

6000 - Tosa / Sl-6000 Pocket Pc

« on: November 29, 2005, 02:04:30 am »

I was under the impression that the prices reflected an adjustment of the value of the yen, which had been high (at least vs. the USD) for the past few years.[div align=\"right\"][{POST_SNAPBACK}][/a][/div]

If you look at the cost history in yen, that will eliminate any price changes due to the fluctuation of the USD to yen conversion rate.  The C1000 and C3100 have dropped about 33% from MSRP.

SL-C1000 [a href=\"http://www.kakaku.com/prdsearch/detaillowprice.asp?PrdKey=00303010243]price history[/url] MSRP: 49,800 street: 33,490
SL-C3100 price history MSRP: 79,800, street: 54,000
SL-6000W price history MSRP: 79,800, street: same  

4

6000 - Tosa / Sl6000 Hardware Accelerated Display?

« on: November 28, 2005, 06:10:51 am »

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.

5

6000 - Tosa / Sl6000 Hardware Accelerated Display?

« on: November 28, 2005, 05:28:19 am »

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?