displaylink

alternate

2011-01-27T07:15:51+02:00

a modified raw / run-length encoding.. Fill with Bytes 0xAF 0×63 3_byte_offset 1_byte_total_count [1_byte_count count_bytes_of_value 1_byte_no_of_repeats_of_last_pixel ... ] x N Fill with Words 0xAF 0×6B 3_byte_offset 1_byte_total_count [1_byte_count count_words_of_value 1_byte_no_of_repeats_of_last_pixel ... ] x N

commands

2011-01-26T23:27:32+02:00

Commands - all known ones start with 0xAF One or more commands can be put into a single bulk transfer, always ends with 0xAF 0xA0 (flush pipe or similar) * 0xAF 0x20 .... - write register -> registers * 0xAF 0x40 0x0B - unknown The following commands modify graphics memory. Base is 0x60, bit 0-2 select subcommand, bit 3 selects word mode, bit 4 selects compressed mode.

copymem

2011-01-26T15:14:43+02:00

Internal MemCopy copy byte sequence 0xAF 0x62 3_byte_target_offset 1_byte_count 3_byte_source_offset copy word sequence 0xAF 0x6A 3_byte_target_offset 1_byte_count 3_byte_source_offset

encryption

2011-01-27T06:55:27+02:00

NOTE: all information on this page was gained through reverse-engineering the driver in order to enable interoperability with other systems. All bulk communications between the driver and the device are encrypted. At first, I absolutely couldn't understand why, but when you consider that they use the same ASIC also in Ethernet-based terminal adapters, it makes marginally more sense. Still, the encryption is total crap and doesn't really protect anything (except maybe try to keep the pesky o…

fillmem

2011-01-27T09:28:29+02:00

Fill Memory This is actually a run-length encoding.. Fill with Bytes 0xAF 0×61 3_byte_offset 1_byte_total_count [1_byte_count 1_byte_value ... ] Fill with Words 0xAF 0×69 3_byte_offset 1_byte_total_count [1_byte_count 2_byte_value ... ] total count: byte/word count, 0×00 = 256

gfxdata

2011-01-27T11:39:57+02:00

Compression Algorithm The compression algorithm is the one big thing which is still missing from the picture. As a quick summary, it seems pretty certain that: * the compression is done separately for 16-bit data and for 8-bit data, as always * it doesn't encode absolute pixel values, but the difference to the previous pixel * the start color for each pixel run is black (0x0000) * it uses some kind of Huffman coding * compression doesn't work without the big 512*9-byte table sent at …

lowlevel

2011-01-26T23:40:01+02:00

Low-level control messages All messages listed as: requesttype request value index [buffer] * Memory Peek: 0xC0 0x04 0x00 address [1 byte result] * Memory Poke: 0x40 0x03 0x00 address [1 byte value] * Poll Status(?): 0xC0 0x06 0x00 0x00 [4 bytes result] * Set Encryption Key: 0x40 0x12 0x00 0x00 [16 bytes key] * Unknown: 0x40 0x14 0x00 0x00 [] - empty buffer, sent by the windows driver with every bulk transfer * Read EDID: 0xC0 0x02 offset<<8 0xA1 [up to 64 bytes result]

registers

2009-01-07T13:52:27+02:00

Write Register command: 0xAF 0x20 register value register & value are 1 byte Registers: * 0x00 color depth - 0x00 -> 16 bit, 0x01 -> 24 bit * 0x01 - 0x0E unknown * 0x0F/0x10 probably X resolution MSB/LSB * 0x11 - 0x16 unknown * 0x17/0x18 probably Y resolution MSB/LSB * 0x19 - 0x1C unknown * 0x1F blank output: 0x00 -> show framebuffer content, 0x01 -> show black screen (not DPMS off!) * 0x20,0x21,0x22 big endian bas…

start

2011-01-27T06:53:50+02:00

Startpage for Displaylink Stuff * lowlevel * encryption * commands * registers * compression libtubecable Hello again! Well, the compression is now working properly. And all of this is now encapsulated in a small library, libtubecable, which I've made available here: If you're interested in participating, the public git repository is here:

writemem

2011-01-26T23:36:37+02:00

Write Memory byte-wise: 0xAF 0x60 3_byte_offset 1_byte_length [length_bytes_data] word-wise: 0xAF 0x68 3_byte_offset 1_byte_length [length_words_data]