DisplayLink

Are you using Geminus, by any chance?

No. I have never had Geminus. It isn’t on the machine.

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:

It was a typo, the PID is 17E9. The device works happily on our 1280×1024 screen here with a test sprite of a screenshot in 16M colours. The result of *UDLDevices was:

Device 1:
USB device: USB6
GraphicsV driver: 1
Chip: DL195
Memory: 9MB @ 5fd00000
Mode: 0×0 1bpp
Display: blanked
Startup mode: 640×480 16bpp
Huffman compression: disabled
Status: f1005001

Turning on Huffman compression didn’t give any noticeable differences to the output test image.

Dave: In that case, I suspect it might have just been a USB error causing the black/partial screen. At the moment there code doesn’t really do any error detection/recovery, so it’s not too unsurprising.

Chris: Thanks!

I suspect it might have just been a USB error causing the black/partial screen.

Do you mean a temporary error that would make it worthwhile to retry, possibly several times?

Even if it’s only displaying a sprite, I’ll be showing it at tonight’s SAUG meeting.

Do you mean a temporary error that would make it worthwhile to retry, possibly several times?

Yeah. The code bypasses DeviceFS/OS_GBPB and just calls the buffer manager directly (writing directly into the buffer where possible), so I’ll have to double-check how you’re meant to detect/handle errors in that case.

Another possibility is that the code was re-entered and it ended up sending a corrupt command to the device – at the moment it doesn’t have any proper protection against that. Writing directly into the DeviceFS buffer is nice from a performance point of view, but a bit of a pain when you have to deal with re-entrancy!

We did our test on an Iyonix. Should it also work on BeagleBoard, Pi, Panda & Pandora?

Yes, it should work on all machines with the USB stack.

Tremendously successful yesterday evening.

OS_ScreenMode 11 comes up with a damaged-looking screen, but in fact all I needed to do was F12 – Return, then up comes a properly filled screen – and it works, it’s live, albeit a rather slow redraw rate, which is to be expected.

It would be handier if UDLStartupMode allowed specifying the bit depth too. My device defaulted to 16 bits, which produced some interesting artifacts (blue background and poorly rendered text from Netsurf). Setting the thing to 32 bits produced a nice crisp display.

Huffman produced a complete mess of the screen, though I think we only tried it when the bit depth was set to 16.

It was curious to see that reverting to the normal video output also needed F12 – Return, and had the same resolution as the DisplayLink-connected monitor. Clearly there is only one set of settings for the display system.

Congratulations again, Jeffrey!

OS_ScreenMode 11 comes up with a damaged-looking screen, but in fact all I needed to do was F12 – Return, then up comes a properly filled screen – and it works

Ah, so you were trying that from within a task window. I can’t remember if I’ve tried that myself – I guess there must be something getting in the way and stopping the mode change from happening.

it’s live, albeit a rather slow redraw rate, which is to be expected.

Yes. At the moment it’s using a ticker event + callback to scan the screen and check for updates. There’s a limiter in there so that it’ll use 20% of CPU time just for scanning for updates – not including the time taken to process a change once it’s found one.

The finished version will switch over to using some kind of abort trapping system to trap screen writes, so should get rid of most of the CPU overhead and make things a lot more responsive. My current thinking is that this will be a generic feature built into the OS, so that any number of clients (video drivers, VNC servers, etc.) can be notified of screen writes on a per-page basis. I’ll also need to take another look at the actual update functions – the compiler seems to be struggling with register allocation, so I may end up having to rewrite them all in assembler to get something that works well. I’ll probably also play around with NEON optimisation, although I’m not sure how well I’ll be able to get it to work with the huffman compression (lookup tables + variable-length output = yuck)

It would be handier if UDLStartupMode allowed specifying the bit depth too. My device defaulted to 16 bits, which produced some interesting artifacts (blue background and poorly rendered text from Netsurf). Setting the thing to 32 bits produced a nice crisp display.

Noted. I think I just stuck to 16bpp by default because it would be fastest.

My current thinking is that this will be a generic feature built into the OS, so that any number of clients (video drivers, VNC servers, etc.) can be notified of screen writes on a per-page basis.

So it will be possible to configure a VNC server as an additional screen?
A revolution :)

Yes. Although in that case I was talking about a more traditional VNC server which would just relay whatever’s displayed on the main screen.

The finished version will switch over to using some kind of abort trapping system to trap screen writes, so should get rid of most of the CPU overhead and make things a lot more responsive. My current thinking is that this will be a generic feature built into the OS

Could OS_ChangedBox do what you want? It should be possible to get a rectangle covering the parts that changed from the VDU system.

OS_ChangedBox has several problems:

1. It’s too coarse-grained. Change one pixel in one corner of the screen and one pixel in the opposite corner and it’ll return a rectangle covering the whole screen.
2. It can’t be used by multiple clients at once.
3. Software which writes directly to screen memory probably won’t bother notifying it of updates.

Trapping writes on a per-page basis isn’t perfect either (a single vertical line could easily mark all pages as being dirty), but I think it’s a better place to start.

Jeffrey: presumably that principle is the same way by which the graphics stack (and acceleration) as a whole can be propelled?

Yes, there are lots of interesting things which could be done once we have a mechanism to trap screen writes (and reads). Cacheable screen memory, asynchronous graphics acceleration, software emulation of low colour modes, display spanning, etc.

Each case does have different requirements in terms of how granular it would like the information to be, but once we’ve got the basic page-level trapping implemented it should be relatively easy to extend the API to support more coarse-grain or fine-grain information as appropriate. E.g. if the callback accepted the start & end address of the access rather than just a page identifier then we’d be free to make the underlying implementation as coarse or as fine grained as we like (and make it switch dynamically based around the granularity levels the clients request).

Yes, it should work on all machines with the USB stack.

I can confirm that it works on a BBxM with the 2014-06-03 ROM. I’m typing this with the DisplayLink adaptor as the display driver now.

Just a thought, which is probably useless, but the abort handler that deals with this mechanism could itself maintain a set of invalidated rectangles (I assume it knows the actual address – pixel(s) – that aborted). Thus, the clients might not need to sit on the abort (or some vector thereof) but be slightly abstracted away such that they can get a ChangedBox-like list of invalidated areas.

The trick here would be to update this list in the abort handler without making the direct screen accesses painfully slow. Maybe also, anything that isn’t direct screen access could be made to avoid the abort route(?) and instead hang off the existing ChangedBox implementation.

I suppose this is what you mean when you say we could later extend this to be either as course or as fine as any clients might require.

Yeah, that’s the kind of thing that I’d consider for a future expansion. However rather than tracking the X,Y coords of the pixels it would probably just track the start and end address of each region. That’ll simplify the processing a bit, and allow it to deal with any situations where the screen parameters could change between the write occurring and the driver/client processing the updates (screen scrolling, multiple screen banks, mode changes, etc.)

The trick here would be to update this list in the abort handler without making the direct screen accesses painfully slow.

Indeed. Some kind of bypass for the abort handler would be nice, but I’m a bit worried about implementing a system which could allow writes to screen memory to be missed. E.g. if an IRQ handler writes to the screen while a foreground task is in the middle of doing a rectangle-based update. If the IRQ handler writes to a pixel which is outside the changed rectangle but inside one of the pages which has had the abort handler disabled then the write will be missed and the video driver might not spot the change at all.

But on the other hand, I can’t think of many legitimate reasons for code to write to the screen from an IRQ handler, so I don’t think it’ll break much existing third-party code. OS code can easily be updated to notify the system of changes (I think only the flashing of the VDU text cursor will write to the screen from an IRQ?), and long-term we’d probably want to deprecate screen access from IRQ completely (it won’t work very well if we use aborts to synchronise with the GPU when performing asynchronous accelerated ops)

Ah-ha!

http://markmail.org/thread/wch4zf4m6nosspns

That answers a few questions.

I try my “i-tec USB Docking Station”. It is combi-device. I use it with my Pandora.
1. USB HUB works
2. LAN Asix AS88772a works if I tell EtherUS the right vendor_product_id
3. USB Audio… works as a C-Media-device in/out
4. DL 165; vendor 17e9; product 02e9… not working. Not sure if I make a mistake or not.
*UDLDevices
… no output
*dadprint… no devicespecific output
*UDLVideo$Product_17e9_02e9 DL165
at first “file not inside…”
second try… nothing. Only a *
*UDLProducts… not in the list

I’m not sure what I should do :-(

In USBInfo I can see all the devices.

*UDLVideo$Product_17e9_02e9 DL165
at first “file not inside…”

You’re missing the ‘set’ command:

*set UDLVideo$Product_17e9_02e9 DL165

After setting the variable you also need to disconnect and reconnect the device to get UDLVideo to detect it.

My mistake. I have use the “set” command yesterday and I have saved the TaskWindow.
I *set UDLVideo$Products_17e9…
Now I became a comparable output like this
The startmode is a other one, the Status is the same.
No picture at this time. A new mistake? Not sure if it works with my cable (DVItoHDMI, should I use DVItoVGA?).
I will try more if I have a little bit more time. Maybe tomorrow morning.
Many thanks!

Ok, now it works .
I have use a old VGA Monitore and think about I read a little bit longer
Jeffrey, is it possibe to switch off the Pandora display if I use the DisplayLink?

Jeffrey, is it possibe to switch off the Pandora display if I use the DisplayLink?

The following should work:

SYS "OS_CallAVector",1,3,,,4,,,,,42

Jeffrey, I remember (hazily) that there was discussion about how to get two displays, possibly of disparate sizes, to show a larger desktop. Have you decided how that is to be done, and do you have any guess as to how long it will be until there will be something we can try?