Proposed GraphicsV enhancements

This page details what I currently have in mind for improving GraphicsV. As the page states, the main goals are to provide an API for exposing the features of the OMAP3 video controller, and to provide proper API-level support for multiple displays (including hotpluggable ones like USB DisplayLink devices).

Feedback in this thread is welcome – but please don’t edit the wiki page itself, as there’s a good chance I won’t spot the edit when I write up the next version of the doc (which is likely to provide a full specification for the new APIs)

Hi Jeffrey. We’re not ignoring you right now, but we have a (non-RISC OS) project going on that is keeping us super busy for a few days so we’ll have to get back to you at some point in the near future about things like this.

No problem – there’s plenty of stuff for me to do with the video driver before I’m even ready to start playing with the fancy stuff :)

I’m slowly moving forward with the next version of the doc. I’ve worked out some of the details with how programs can claim ownership over overlays, and have come to the conclusion that a tag/value list/tree is pretty much the only way to represent the capabilities & configuration values of displays/overlays. But although the API for setting configuration values was easy to come by, I’m still struggling trying to work out a sensible API for querying what the current configuration is and what all the different options are.

In a few days time I’ll hopefully have a better doc uploaded with less waffle and more actual designs/specs. It’ll still be missing a few important pieces, but it should be a bit easier to read!

Looking forward to reading it!

Version 2 of the doc is now up. As you can see I decided not to go with the tag/value list/tree system and go with a table instead. The table approach should make it easier for programs and drivers to deal with the data, even if it introduces some memory wasteage (e.g. even though they aren’t used, each overlay will still have a cell for storing timing parameters) I’m still not even sure if this approach is a good idea; trying to come up with an API that works for all display hardware, while exposing maximal functionality to programs, and preferably indicating why certain settings are invalid, isn’t very easy!

This new doc still isn’t perfect; I have a feeling that most/all of the stuff to do with passing head/overlay numbers in bits 16-23 of R4 can be removed, in preference of using the table-based interface instead. I suspect the most sensible thing to do is to retain the old GraphicsV reason codes for use by the system – i.e. if a driver receives a SetDAG or SetMode call then it knows that it should modify the head/overlay that’s being used by the system to display the desktop. Specifying the head/overlay number on a per-call basis is therefore not required (as long as one of the new reason codes is used to tell the driver which head/overlay the calls should map to)

Also I haven’t gone into much detail as to what the table actually looks like in memory!

Another big issue that needs resolving is memory management. I’ve only really just started to look into that now, but in order to sensibly support display rotation on OMAP3 it looks like drivers will need to be able to exert much more control over memory allocation/usage than they do at the moment. Luckily similar memory management modifications have been made to Select, so we should hopefully be able to base our API modifications around theirs.

If anyone has any ideas on how to make the API or the doc better, please share them! Since the doc does propose some big changes I’ll probably hold on any further rewrites until people (e.g. ROOL) have had a chance to read and comment on it. And as always, there are still 101 other things for me to work on apart from this ;)

Just for info: there’s an article up on TIB (http://www.iconbar.com/articles/Easier_video_playback_on_RISC_OS/index1255.html) with some info on the ARM port of the Ogg Theora libraries. May be of interest to anyone working on an API for the new OMAP facilities.

I read most of Jeffrey’s “Proposed GraphicsV enhancements” page last night. I don’t know if I missed anything, but I looked for any method of showing spatial relationships between linked displays and couldn’t see any.

A human being has to be the original source of the information (e.g. display 1 is to the left of display 0), but subsequently the OS and applications should be able to look it up and use it.

Good point. Adding spatial location info is certainly something worth considering, but it’s not something I’m particularly eager to add to this version. If you can spec out a good way for it to work then I can probably add the relevant support when I write the rest of the code, but I don’t think I’ll be losing any sleep over the design myself ;)

How about this:

Each display has four numbers associated with it, being the numbers of the display to the left of it, to the right of it, above it, and below it, or -1 if there is no such linked display.

There’s an implicit assumption that linked displays have the same resolution. If they don’t, it might be excessively difficult to link them anyway.

If they don’t, it might be excessively difficult to link them anyway.

Which is one of the reasons I’m not keen on coming up with the API myself ;)

I haven’t played around with multi-monitor setups in Windows much, but I do know that it supports displays of differing resolutions, and allows you to specify the alignment of the displays. The displays span to each others edges, but I’m not sure of how/when the layout changes if one of the displays changes resolution, rotates, disconnects, etc.

I chose the words “excessively difficult” to imply that it was too difficult and therefore you wouldn’t attempt it. At least, not at this revision.

It’s OK if the adjacent edges of adjacent linked displays have the same length, regardless of the other dimension.

The test has to be performed when the operator tries to tell the system about adjacencies. If they don’t fit, then the linkage information won’t be accepted.