How To Do Video Out On C3000? Options

[kahm]

It is going to be impossible to do VGA video at any reasonable speed on the Zaurus.

VGA is 640x480 resolution. That's 307200 pixels. If you only want 256 colours that's 300 kb/frame. If you want 16 bit color that's 600 kb/frame. Uncompressed video over USB would therefore give you ~2 frames per second. If you compress the video before hand you could get 5-8 frames per second, at the cost of using your entire processor for compression. CF is faster, theoretcially, but once again you're processor limited.

There are things that can be done to reduce the data requirements, but the worst case scenario - Full-screen video - becomes impossible.

This is assuming that these things have open source drivers that work under Linux, which they don't.

If we didn't care that performance would be no better than IOData's CF card, and if we had the documentation, or wanted to tie up a developer for a few years doing reverse engineering, we could write a driver. But we dont', so we can't.

There is no support for external video built into the processor, and all the external databusses are too slow. VGA video out at usable rates is completely impossible.

[rickh]

If we didn't care that performance would be no better than IOData's CF card, and if we had the documentation, or wanted to tie up a developer for a few years doing reverse engineering, we could write a driver.  But we dont', so we can't.

Would this link help? I don't know what the licensing is - it may be restrictive - but they do offer source and API spec on that page.

Unfortunately, I'm not a programmer, so I wouldn't have the slightesst idea what to do with the code, but I would think that if there were enough interest, it would be a good starting point, provided the licensing allowed it.

R.
==

[kahm]

If we didn't care that performance would be no better than IOData's CF card, and if we had the documentation, or wanted to tie up a developer for a few years doing reverse engineering, we could write a driver.  But we dont', so we can't.

Would this link help? I don't know what the licensing is - it may be restrictive - but they do offer source and API spec on that page.

Unfortunately, I'm not a programmer, so I wouldn't have the slightesst idea what to do with the code, but I would think that if there were enough interest, it would be a good starting point, provided the licensing allowed it.

R.
==

We already have working drivers for the IOData card. I was referring to the usb VGA adaptors that people keep bringing up as potential solutions.

[rickh]

We already have working drivers for the IOData card. I was referring to the usb VGA adaptors that people keep bringing up as potential solutions.

Does it actually work with the C1000/3000? I've been unsuccessful with my C3000, although it works fine with my 5600.

R.
==

[kahm]

We already have working drivers for the IOData card. I was referring to the usb VGA adaptors that people keep bringing up as potential solutions.

Does it actually work with the C1000/3000? I've been unsuccessful with my C3000, although it works fine with my 5600.

R.
==

That I don't know about. I don't have one, and I'm not likely to ever end up with one. Someone was saying that the kernel module on the 3000 was still compiled for the old kernel, so it would work but not very well (lockups).

I don't know offhand whether the full driver source is available to re-compile. It might never have been redone for the new Z's due to the card itself being discontinued.

Sorry, but I can't be of more help than that

[rickh]

That I don't know about. I don't have one, and I'm not likely to ever end up with one. Someone was saying that the kernel module on the 3000 was still compiled for the old kernel, so it would work but not very well (lockups).

That would be me :-)

I don't know offhand whether the full driver source is available to re-compile. It might never have been redone for the new Z's due to the card itself being discontinued.

Sorry, but I can't be of more help than that

No problem. Thought you might have had some first hand knowledge of recompiling it.

R.
==

[kahm]

That I don't know about. I don't have one, and I'm not likely to ever end up with one. Someone was saying that the kernel module on the 3000 was still compiled for the old kernel, so it would work but not very well (lockups).

That would be me :-)

I don't know offhand whether the full driver source is available to re-compile. It might never have been redone for the new Z's due to the card itself being discontinued.

Sorry, but I can't be of more help than that

No problem. Thought you might have had some first hand knowledge of recompiling it.

R.
==

Well, the source is there. Shouldn't be all that painful to recompile it against the newer kernel. I'm not going to have time to try any time soon, though, and I don' t have a card to test with anyway. =(

[sven]

just for comleteness. This is the link to the(one?) usb-vga Solution:

Data Display AG - USB-VGA controller

There is also a preliminary documentation which seems to be enough for programming a linux driver.
Even if (and they do, i think) the usage and bandwidth restrictions above apply, it will be a very nice toy.

Sven

[Meanie]

nice card, but no linux drivers so zaurus support is even more unlikely

[kahm]

just for comleteness. This is the link to the(one?) usb-vga Solution:

Data Display AG - USB-VGA controller

There is also a preliminary documentation which seems to be enough for programming a linux driver.
Even if (and they do, i think) the usage and bandwidth restrictions above apply, it will be a very nice toy.

Sven

Wow. A device that may actually be usable. It is, however, utterly impractical, for the same reason that it is doable - It is for the embedded market.

The reason that this could be implemented is because it isn't a video card. (Ie a box with a USB connection on one end and a VGA connection on the other). This is a frame-buffer for driving raw TFTs and is intended for the embedded market. That means, by definition, people have to know how to program them because they are buying them for inclusion in their own product. Thus, one way or another, the required specs have to be there.

Secondly it is just a dumb framebuffer. (Or very nearly so). That means that we can feed it an arbitrary stream of pixels, and it remembers them and throws them up on the display - quite similar to what I presume the Iodata card does in practice. Performance would be lousy, but it is really only intended for nearly static images anyway. (Note the inclusion of touch screen cababilities - perfect for cash registers or displays for small embedded devices like controllers.)

Now the problems: Because it is an embedded style part it will be 1) Expensive, 2) mostly likely a bare board, and 3) hard to get hold of in small quantities.
The kicker is the display, though. It doesn't drive a monitor. It only drives raw LCD displays. You'll have to find a 640x480 LCD with a TFT TTL connector. ( A standard connector is a step up from the last time I looked into these things - it used to be that every LCD had a manufacturer proprietary connector. They may still do - it's been a while since I checked) This means that the LCD will probably be 1) Small (6-8"), 2) Bare, perhaps even to the extent of you having to track down power supply and inverter, and 3) most likely expensive and hard to track down in small quantities.

Then you have to write the driver.

So...While this would be the most likely course of action to try, and far easier to accomplish than trying to use a USB->VGA adapter (which, AFAIK, are unavailable in USB1.x flavours anyway), it is also highly unlikely that anyone would go to the trouble.

[sven]

After going deeper in to the specs of this usb-vga adpter i see:

- every transfered frame must really be complete frame at 640x480x16 pixel (600k)
(which means about 2 frames per second, see above)

- even moving the cursor need a complete frame

I hoped it is possible only to transfer changed picture blocks.

[kahm]

After going deeper in to the specs of this usb-vga adpter i see:

- every transfered frame must really be complete frame at 640x480x16 pixel (600k)
  (which means about 2 frames per second, see above)

- even moving the cursor need a complete frame

I hoped it is possible only to transfer changed picture blocks.

Nuts. I didn't bother to read the documentation quite that far in. Complete frames only? What a waste. It's a dumber framebuffer than I gave it credit for. There should be no reason that it can't let you arbitrarily twiddle memory locations. If that's the case I'm going to bet that it doesn't support any sort of compression, either.

That limits the usefulness of this thing in most circumstances.

[sven]

There should be no reason that it can't let you arbitrarily twiddle memory locations.

They even let the fields in the commands for that, but the framebuffer only accepts hard coded values for full screen at 16bit.

If that's the case I'm going to bed that it doesn't support any sort of compression, either.

No compression at all.

Sven

[Da_Blitz]

with the io vga out card does that allow you to use the output like a normal vag adaptor or will it only work for applications written for it?

its a shame it the c3000 doesnt have the 2700 video card from intel as that had vga out built in (all it needed was a driver chip) (see the x50 from dell for refrence)

[kahm]

with the io vga out card does that allow you to use the output like a normal vag adaptor or will it only work for applications written for it?

its a shame it the c3000 doesnt have the 2700 video card from intel as that had vga out built in (all it needed was a driver chip) (see the x50 from dell for refrence)

AFAIK, you could either use the "Mirror" applet, which mirrored the output of the Z's screen (slowly), or a specialised application such as Hancom Presenter.