USB VIDEO ON THE DENEB?

[alexh]

platon42 wrote:
maybe the registers of the DVI encoder chip are directly accessible over control transfers. If that's the case, luckily the docs of the chip are available on the net.

The docs of the DVI chip?

platon42 wrote:
It uses the LibUSB, which is LGPL & GPL, so at least here we could demand the source code for. I doubt, it will be any use though.

That is not a bad idea. In our office some managers are dreading a phone call asking about this subject. GPL software has been used in some products and legally no-engineer knows where we stand when it comes to releasing part/all of our source code.

[Zac67]

The DeLock really uses the same chip, but it's a DL-160 - so the high resolutions should work as advertised/mentioned in the 'manual'. But I bet it's the very same board design (=reference design from chip manufacturer).

[Darrin]

wawrzon wrote:

@all: im repeating this for th last time: thanks folks, but i do not need a refund on this. im happy to support.

So where do you want me to send the money?   :-?



That's very kind of you.

In that case, I have another 25 Euros here which I'm willing to pledge to any other useful USB device that Chris would like to examine in the future for developing possible Posseidon drivers.

[wawrzon]

@darrin: thats an attitude i appreciate

[platon42]

Zac67 wrote:
The DeLock really uses the same chip, but it's a DL-160 - so the high resolutions should work as advertised/mentioned in the 'manual'. But I bet it's the very same board design (=reference design from chip manufacturer).

Except for the DL-160, my adapter has the same components, even the same amount of memory (16 MB).

[wawrzon]

@platon42:
hi chris. i quote here the answer iv received from pearl on my complaint. seems to me bllsht since 1600x1200 is a 4:3 resolution but wanted to hear what u say.
@all: sorry for a german quote but this is just support issue i wanted to notify chris about.

Ihre Anfrage an den PEARL-Kundenservice


Sehr geehrte Damen und Herren,

vielen Dank für Ihre Anfrage und das uns entgegengebrachte Vertrauen.

Auflösungen von 1680x1050 oder 1600x1200 können nur auf 22 Zoll
Bildschirmen mit 16:10 bzw. 16:9 Breitbildformat ausgewählt werden.

Dass Sie nur bis maximal 1280x1024 Pixel einstellen können liegt
vermutlich daran, dass Sie einen 17 oder 19 Zoll Monitor besitzen.

Bitte korrigieren Sie uns falls dies nicht zutreffen sollte.

[platon42]

wawrzon wrote:
@platon42:
hi chris. i quote here the answer iv received from pearl on my complaint. seems to me bllsht since 1600x1200 is a 4:3 resolution but wanted to hear what u say.

Yeah, that is bull indeed (I had a monitor connected with a natural resolution of 1600x1050). They should open the box and see for theirselves that it only has the DL-120 inside and not the DL-160 that is needed for the higher resolutions. Also, when searching for the product number "Y-2240" you will find that this device has also been rebranded as "Unitek USB 2.0 External graphic card" with the description "Enjoy resolutions of up to 1200x 1040 at 32 bit color".

[wawrzon]

i actually have some annoying experience with them, so i think they have kinda regular policy to play dumb as long its possible. didnt find the other "Unitek USB 2.0 External graphic card" on teir hp though. we can send the piece back in if you wish, however it is probably unnecessary in this case.

[platon42]

platon42 wrote:

Except for the decompression, I expect the device to be rather simple hardwarewise -- maybe the registers of the DVI encoder chip are directly accessible over control transfers. If that's the case, luckily the docs of the chip are available on the net.

I'll keep you informed how it turns out. But I really need some more sleep...

The thing seems to use some XOR encryption/scrambling with a period of 4095 (LFSR?). Luckily, I found out that it can also operate in an unencrypted "debug" mode, which makes it much easier to analyse the protocol :-) A university friend of mine is helping me as he has a similar aim by writing a driver for linux for it :-)

BTW: x86 assembler sucks big time.

[Zac67]

Nice to see progress here, even if everything is open still.

I started with x86 assembler many years ago, but detested it so much I couldn't stay on - it's like riding an open oxcart after knowing the 'Rolls Royce' 68k version...

[wawrzon]

great news, thanks for keeping up with this, chris!

[alexh]

platon42 wrote:
BTW: x86 assembler sucks big time.

You looking at the Intel MacOS drivers?

DisplayLinkGA
DisplayLinkDriver

I thought with them being beta they might have accidentally left in source level debugging but no such luck!

[platon42]

alexh wrote:

platon42 wrote:
BTW: x86 assembler sucks big time.

You looking at the Intel MacOS drivers?

DisplayLinkGA
DisplayLinkDriver

I thought with them being beta they might have accidentally left in source level debugging but no such luck!

I only got a PPC Mac, and they unfortunately don't provide drivers for PPC Macs. Hence, I've been looking in the wintel drivers. The actual "driver" logic is in the DisplayLinkManager.exe, which in my version does contain a lot of kprintf() debug statements, that led in the right direction already. There are a few debug symbols too, but not in the important parts.

[alexh]

The MacOSX intel beta drivers would probably be a better place to start? They have no hardware acceleration etc.

Use TransMac to open the .dmg stuffit file and 7Zip to open the .pak file

[platon42]

alexh wrote:
The MacOSX intel beta drivers would probably be a better place to start? They have no hardware acceleration etc.

Use TransMac to open the .dmg stuffit file and 7Zip to open the .pak file

The cruel & crucial point is still that I have to read that brainf*cking x86 code. Anyway. I'm at a stage now that I have identified and understood the display memory (16MB) accessing functions and can display a nice gradient. I also have found the registers that are used for the frame buffer start addresses, so I can actually switch between two memory locations now.

I have yet to find out the calculation for the video registers (I'm using a pre-recorded setup right now) and the delta-compression scheme, among other things of course.

But things are progressing well...

[Darrin]

platon42 wrote:
The cruel & crucial point is still that I have to read that brainf*cking x86 code. Anyway. I'm at a stage now that I have identified and understood the display memory (16MB) accessing functions and can display a nice gradient. I also have found the registers that are used for the frame buffer start addresses, so I can actually switch between two memory locations now.

I have yet to find out the calculation for the video registers (I'm using a pre-recorded setup right now) and the delta-compression scheme, among other things of course.

But things are progressing well...

Well done Chris.  I'm glad to see you're still working on this as I thought it was a dead end.  I guess you like a good challenge.  :-D