DisplayLink

Todo:

• The huffman compression is a bit dodgy – it mostly works but sometimes draws garbage. Uncompressed (as above) seems fine.
• Needs wrapping up as a GraphicsV driver. Preferably with support for more flexible screen memory handling at the OS level, as without cacheable screen memory or some kind of abort handler to detect writes it’ll be a bit slow.
• Could do with EDID support in the OS, as there doesn’t appear to be any other way of reading the device capabilities (even for fixed displays like the one in my device). Furthermore, there’s only a fixed set of modes which are supported (comprised of a list of magic numbers), so we’ll probably want some software scaling support in order to allow arbitrary modes to be used. Which would definitely require EDID, to allow the driver to work out which native mode to use in each situation.

Very cool. Assuming you’ve done sufficient packaging for the GraphicsV driver, have you managed to test with the EDID code as-is? Clearly multiple display support in ScreenModes becomes more of an issue when that’s the case.

No GraphicsV bits yet – at the moment it’s just an app that initialises the driver (with the EDID decoding hardcoded for my device) and then copies over the top-left portion of the screen. But a quick test does show that ScreenModes will decode the EDID dump correctly.

Very interesting.

Nice one! When combined with multi-head support, this will be a hugely useful feature. Out of interest, is that using 16- or 24-bpp?

16bpp.

Although I’ve been using the OpenBSD sources so far, I’ve just had a peek at the NetBSD sources and it looks like they’ve cracked the structure of the magic numbers used to program the display modes – so they’re able to program everything directly using the mode timings. It also looks like they have support for a few more devices. So I think the next thing on my todo list will be to switch over to the NetBSD sources. I’ll also pick up a DVI/HDMI/VGA adapter at some point as they seem to be reasonably cheap.

Unfortunately neither of the two drivers appear to support 24bpp, but I think I know roughly what needs to be done to get it working.

Jeffrey: I’ve had a DisplayLink adaptor for a while now. (I’m sure you’ll not be surprised that a driver was on my to-do list, but never made it to the top.) So if you would like me to try your code, please send me a copy with some instructions about what I have to change to match my setup.

Jeffrey: I’ve had a DisplayLink adaptor for a while now. (I’m sure you’ll not be surprised that a driver was on my to-do list, but never made it to the top.)

I think I had mine for about 4 years before I finally started to work on the driver this weekend :/

I’ll probably upload something once I’ve got a basic GraphicsV driver up and running – maybe in a week or two depending on how much higher priority stuff gets in the way.

Jeffrey, is your code based on tubecable or the official displaylink stuff?

I had a DisplayLink device for many years now, never got round to experiment with it in a RISC OS context…but it was great for adding multi-head to my notebooks!

Jeffrey, is your code based on tubecable or the official displaylink stuff?

Currently I’m using the OpenBSD driver (which is based around floe’s reverse-engineered spec; not sure if they used any of his code directly). Soon I’ll be migrating to the NetBSD driver (which is an improved version of the OpenBSD one).

Have you seen libdlo – wot I wrote? This was the original OSS reference implementation for DisplayLink driver writers to understand how to drive the chips (in a fairly basic way). All of the screen mode setup is implemented in mode.c, which will hopefully help you.

Yes. Shame you released it under the GPL instead of BSD ;-)

Also there’s no support for the huffman compression or using arbitrary mode timings.

Ah, hang on, yes it does support arbitrary mode timings. But also has a big list of magic numbers it uses for standard modes, hence my confusion.

Yes. Shame you released it under the GPL instead of BSD ;-)

Easily fixed, at the copyright owners discretion.

Progress update:

• 16bpp and 24bpp support, with and without huffman compression, is now working.
  • It doesn’t look like anyone’s implemented 24bpp huffman support before, so that required a bit of reverse-engineering on my part in order to deduce the extra huffman table that’s used for the 8 bit plane.
  • For the original problems I was seeing with the 16bpp huffman I think it must have just been a bug in the original OpenBSD code – the routine I wrote myself seems to work fine (I’ve basically ditched all of the original framebuffer update code and created my own implementations to cover the use cases that the RO driver will need).
• Mode setting code from the NetBSD driver has been merged in and seems to be working OK with the new adapter I bought. Taking any of the other NetBSD changes didn’t seem to be sensible considering how much of the BSD code I’ve now ditched in favour of my own tailor-made stuff. Plus the huffman code is completely disabled in the NetBSD driver, which isn’t a very good sign!

I’m currently in the middle of converting the code over to run as a module/GraphicsV driver, so it shouldn’t be too long before I have something ready for other people to try out.

Also I’m wondering how much effort I should put into trying to crunch down the 16bit huffman table. In an ideal world I’d want the displaylink driver to go into ROM, but the uncompressed huffman table is 256K+64K = 320K, which is a bit bulky for something which only a handful of people will use (the displaylink driver itself is likely to come in at around 20KB). Squashing the data does give some gains, but it’s still around 240K in size. The best solution would be to work out the algorithm that was used to generate the tree, but the only obvious pattern I’ve seen so far is that in 99% of cases the second to last bit gives the sign of the encoded value. That could allow the table size to be cut in half, but finding a few more patterns would be ideal to get it down to a much more acceptable 30KB or so. In any case I should probably wait until the GraphicsV driver is working so that I can get some useful stats on whether the huffman compression is actually worth it or not – it wouldn’t surprise me if the CPU overhead in compressing the data outweighs the performance gains from reducing the USB bandwidth.

If anyone wants to try analysing the huffman table themselves, a nice human-readable form of the data is here

Great progress! Could you split the driver into driver+huffman table, and include the driver in ROM, but put the huffman tables elsewhere? I know nothing about it, but from your description, it sounds like you can get useful functionality without the huffman compression.

Could you split the driver into driver+huffman table, and include the driver in ROM, but put the huffman tables elsewhere? I know nothing about it, but from your description, it sounds like you can get useful functionality without the huffman compression.

Yes, that would be pretty straightforward to do.

I’ve been messing around a bit more today and realised that simply doing a couple of passes over the table, EORing each entry with a preceding entry, will result in a file that’s much easier to compress – it comes out as 86K when squashed, or 52K using zlib, which sounds acceptable to me.

The module version of the driver is also working now. There are a couple of bugs to fix and some debug features to add, after which I should be able to release a copy for testing. But it’ll probably be a few months until you see it in any ROM images, as some kernel/GraphicsV improvements are needed in order for it to not feel like you’re using a somewhat laggy VNC connection (and to get rid of a nasty memory allocation hack!)

Test version of the driver over here: http://www.phlamethrower.co.uk/misc2/UDLVideo.zip

This is a debug build of the module, so it’s recommended to load DADebug (which is also in the archive) before loading UDLVideo so that you’ll hopefully get some debug output (*DADPrint) if things aren’t working correctly.

When you connect a recognised device it won’t do anything much with it apart from initialise the device and set up a GraphicsV driver instance. In order to get stuff to appear on screen you’ll either have to use some of the debug commands (below) or take the plunge and use OS_ScreenMode 11 to switch output to the device – e.g. SYS "OS_ScreenMode",11,1 to activate, SYS "OS_ScreenMode",11,0 to deactivate. However for that to work properly you’ll most likely need to be using a ROM from today, as there was a kernel bug which would have prevented the startup mode from being correctly selected.

*commands are as follows:

• UDLDevices – Lists all the active devices and various bits of state information. Devices which failed to initialise won’t be shown, so you’ll have to check the DADebug output for clues as to why.
• UDLProducts – Lists all the vendor/product IDs the driver knows about and which chip they correspond to. If your device isn’t in the list you can create a system variable for it, e.g. set UDLVideo$Product_VVVV_PPPP DL123 where VVVV and PPPP are the vendor/product IDs and the variable value should be the (suspected) chip type (DL120, DL125, DL160, DL165, DL195, or DLUNK for unknown). After doing this you’ll have to reconnect the device or reload the module to get it to have another go at initialising the device.
• UDLWriteReg – For the brave, this allows you to send register write commands to the device. Writes to the sync register must be performed manually.
• UDLStartupMode – Allows you to select the initial resolution to use when using OS_ScreenMode 11 to switch to the device. Some devices with fixed displays may need this (although my Nanovision MiMo didn’t cope too badly when I messed around and gave it some unsupported modes). Note that you’ll also need a corresponding entry in your MDF.
• UDLHuffman – Remember when I said huffman was fixed? It isn’t. It works fine on my new device (DL165) but has the same artifacts on the MiMo (DL120). I suspect the older chips are fussier and don’t like the way the DeviceFS layer ends up splitting the huffman data packets across multiple USB bulk packets. But whatever the case may be, huffman is disabled by default, so you should use this command to try turning it on and see what happens.
• UDLTest – This can be used to do some basic functional tests without having to switch GraphicsV drivers. It will switch a device to the specified mode and then plot a sprite file to the screen.

Testing I’m interested in:

• Which devices work and which ones don’t. Specifically if anyone has any devices which need adding to the builtin list (and what model of chip they use – the chips are labelled quite clearly so taking your device apart is perhaps the best way of finding out what you’ve got)
• Which chips huffman does and doesn’t work on
• The value shown in the ‘Status:’ line of the *UDLDevices output. This is a status register which I’m hoping can be used to determine the chip type – there’s already some code from the original OpenBSD driver which uses it to determine the chip type for certain devices, so I’m hoping that with a bit more digging we’ll be able to work out a generic way of identifying the chip instead of relying on a hardcoded list.

Apart from the huffman issues, the chip type doesn’t appear to have any bearing on the communication protocol. However the different chips supposedly have different resolution limits, so knowing the correct type will be important once I implement a proper mode vetting call.

A couple of extra notes:

• The driver only supports 16bpp and 32bpp screen modes – no palettised modes yet. So don’t be surprised if things fail spectacularly if you try entering a numbered mode. (Software emulated) palettised mode support will probably come in the final version of the driver.
• The driver only supports the DL1xx series of chips – as I understand it the newer chips (DL3xxx, DL4xxx, DL5xxx) use a completely different protocol, for which there aren’t any open-source drivers yet.

I managed to get a ‘Plugable UGA-165’ DisplayLink adapter working with RISC OS on a Pandaboard ES.

I had to set ‘UDLVideo$Product_17e9_037a DL165’ to get it to be picked up.

It’s this model here.

Device 1:
USB device: USB5
GraphicsV driver: 1
Chip: DL165
Memory: 8MB @ 7fc00000
Mode: 1680×1050 32bpp
Display: on
Startup mode: 1680×1050 16bpp
Huffman compression: enabled
Status: f1005001

Amazing job
It says on the website ‘no drivers for linux’. But there is now one for RISC OS. Is this a first?

I managed to get a ‘Plugable UGA-165’ DisplayLink adapter working with RISC OS on a Pandaboard ES.

I had to set ‘UDLVideo$Product_17e9_037a DL165’ to get it to be picked up.

It’s this model here.

Yep, that’s basically the same as the one I recently bought. Except I took the riskier approach of buying a cheaper model from a different seller which I was hoping to be a DL195 but ended up being a completely unbranded DL165 device (same form factor, manual, installation CD and basic box design as the Plugable one, but without any branding, serial number, model number or barcode on the box, device, or manual).

Amazing job
It says on the website ‘no drivers for linux’. But there is now one for RISC OS. Is this a first?

Linux has had support for DL1xx chips for years. That notice is probably referring to the newer DL3xxx/DL4xxx/DL5xxx chips, which I think are only supported by Windows so far.

I’ve got a device with VID 17E9 and PID 0198, which I think is a DL120. I’ve hooked it up to my Xerox XA7-17i monitor. The only connector on the DisplayLink box and the monitor is DVI-I. DADPrint shows this:

UDLVideo: ***** Debug Session Started **************************************
UDLVideo: DebugLib is (c) Pace Micro Technology plc. 1997-2001
UDLVideo: System: DebugLib 0.67
UDLVideo:         remotedb 0.11
UDLVideo:         PDebug 0.08
UDLVideo: Task:   UDLVideo
UDLVideo: Time:   Sat Jun  7 22:35:57 2014
UDLVideo: Levels: Not specified.
UDLVideo: ******************************************************************
UDLVideo: enumerate_cb: Matched device USB17
UDLVideo: huffman tables initialised
UDLVideo: USB17: udl_init_chip: poll=0xf0005001
UDLVideo: USB17: udl_init_chip: chip 1
UDLVideo: USB17: udl_init_chip: read 0x8d from 0xc484
UDLVideo: USB17: udl_init_chip: write 0x01 to 0xc41f
UDLVideo: USB17: udl_init_chip: set encryption key
UDLVideo: USB17: udl_init_chip: write 0x00 to 0xc40b
UDLVideo: USB17: udl_cmd_send: sent 4620 of 4620 bytes
UDLVideo: PCI RAM at 5fd00000 log c24fd000 phys, size 00600000
UDLVideo: Created DA 290 @ 8bc8d000
UDLVideo: free space: 65537/65538
UDLVideo: free space: 3329/65538
UDLVideo: finish_packet: 3583/6912 remain
UDLVideo: free space: 3329/65538
UDLVideo: finish_packet: 3583/6912 remain
UDLVideo: process_rate set to 33120 bytes per tick
UDLVideo: RegisterDriver failed, error 000001f2 Unknown OS_ScreenMode reason code

set UDLVideo$Product_17E9_0198 DLUNK or DL120 don’t seem to make any difference.

I can’t see the chip markings as it has a heatsink glued on.

UDLVideo: RegisterDriver failed, error 000001f2 Unknown OS_ScreenMode reason code

It’s failing to register the device as a GraphicsV driver – so you need to use a newer ROM image.

Once you’ve done that I think the device should work fine, it looks like it’s one of the ones the original BSD sources supported.

you need to use a newer ROM image.

Rats, yes, you did say that. My apologies for the noise.

Better news now. There is an image on the other monitor, though not yet enough to be useful. I can see the scroll bars of a window, though pretty much everything else is black.

The status value you wanted to know in this case is f0005001, for a 17E9:0198 device. The monitor is a Xerox XA7-17i which is 1280 × 1024.

I concocted a sprite file, 1280 × 1024, 16 bits, no mask; UDLTest causes it to be displayed on the Xerox monitor.

Congratulations, Jeffrey! Another conspicuous success!

We’ve now got a “ClimaxDigital CUH195 USB 2.0 Graphic Adapter”
Vid:17e8
Pid:0360
Is that on the list of tested units?
If not we can give it a go.

Better news now. There is an image on the other monitor, though not yet enough to be useful. I can see the scroll bars of a window, though pretty much everything else is black.

Are you using Geminus, by any chance? I’ve just done a bit of testing and it looks like Geminus (unsurprisingly) assumes that every GraphicsV driver will correspond to an instance of the NVidia module. So if you start Geminus before UDLVideo registers a device then it looks like Geminus will end up intercepting most of the GraphicsV calls and sending them to the wrong places. And if you try starting Geminus after UDLVideo then it will fail because it will be unable to find the PCI device that it thinks the DisplayLink device represents.

I concocted a sprite file, 1280 × 1024, 16 bits, no mask; UDLTest causes it to be displayed on the Xerox monitor.

Good good. The sprite can be any size or colour depth, by the way – the code just uses regular OS_SpriteOp calls to plot it. But it doesn’t do any scaling, so to give the code a proper test small sprites should probably be avoided.

We’ve now got a “ClimaxDigital CUH195 USB 2.0 Graphic Adapter”
Vid:17e8
Pid:0360
Is that on the list of tested units?
If not we can give it a go.

That one isn’t on the list of known devices, so if you can give it a quick test then that would be great. You’ll need to set up a system variable for it to be detected:

*set UDLVideo$Product_17E9_0360 DL195

(I’m guessing that 17E8 vendor ID is a typo – AFAIK 17E9 is the only one used for DisplayLink devices)