Proposed GraphicsV enhancements

• The ‘A’ flag only indicates alpha mask support
  

What’s the rationale behind that? It seems an odd restriction to me. Would the OS actually enforce it? If the ROL branch’s *IconSprites ever gets updated to support the new ‘AX’ suffix, then they can add support for the alpha channel format too. Only supporting the alpha mask type seems like a bizarre technical restriction that will result in the situation where this alpha sprite works, but that one doesn’t.

Could we not stick with the existing sort-of-a-precedent (it isn’t very common, but only because alpha sprites aren’t very common) of replacing the ! character with an A to indicate alpha-ness, and keeping the existing two character suffixes?

There are a few reasons I’m opposed to this:

• The OS has a prior precedent of doing everything using suffixes
• Changing the code to use both prefixes and suffixes would be harder than just tweaking the suffixes (not a proper excuse, but programmers naturally look for the quickest/easiest solution to any problem!)
• You can *IconSprites anything, the filename doesn’t have to contain a !
• Wimp_ReadSysInfo 2 allows you to read the preferred suffix that’s used for sprites. If we stuck with suffixes this would automatically cope with alpha sprites, but if we start using prefixes then anything which tries to apply the suffix manually could fail (I’m guessing there must be some software out there somewhere, otherwise the value wouldn’t be exposed). Although it’s arguable that adding ‘A’ to a suffix which used to just be numbers could cause the software to fail anyway!
• If we start using prefixes for things then people won’t have a clue what to call their files in order to avoid them potentially being picked up by *IconSprites (e.g. to avoid *IconSprites accidentally loading a set of sprites that were intended for a different purpose). If we stick with suffixes then all they need to do is make sure the base name of the different files are unique.

The ‘A’ flag only indicates alpha mask support

What’s the rationale behind that? It seems an odd restriction to me.

Mainly to keep things open for if the ‘A’ flag support gets added to the ROL branch. Theoretically all someone would need to do is softload our version of the Wimp.

For enforcing the flag I was only thinking of implementing one check – if during the desktop startup the Wimp determines that alpha masks are supported it will make the ‘A’ flag available, else it will make it unavailable. Apart from potentially looking for ‘A’ files the actual code which loads the sprites will be left pretty much as-is. I.e. if the OS loads the sprite file and merges it into the sprite pool OK then the Wimp will use it.

You do raise a good point about people getting confused when they find that (e.g.) an alpha channel sprite won’t work when loaded on an ‘A’ aware version of ROL’s OS. But technically we’ve been in that situation for ages, where people developing primarily for ROL’s OS might have released apps containing alpha masks or 64K colours which until now wouldn’t have worked on RISC OS 5. But if people are worried about alpha channel sprites slipping out under the ‘A’ name then I don’t have any strong feelings against extending ‘A’ to cover all the RISC OS 5 formats.

So far the consensus seems to be: The ‘A’ flag only indicates alpha mask support. We’ll stick to two character suffixes (!SpritesXY, !SpritesAX, etc.) to avoid issues on old filesystems

This is now implemented.

I’ve also fixed the icon shading/inverting to cope with true colour sprites (previously they’d just be rendered normally). Let me know if you think the quality could do with improving – for speed reasons shading/inverting of true colour sprites is using a set of lookup tables rather than doing the full calculations for each pixel, and the lookup tables are currently quite small (3 tables of 4K colours each). Bumping them up to 32K colour is possible, but it would increase the memory usage to 384K, so I’d probably want to tweak things a bit to get it back down to a more sensible level.

I just tried the latest rom with this change (OMAP3 and OMAP4) on a Pandaboard ES and BeagleBoard Xm. Both hang as soon as ‘ModuleInit’ appears on the serial console.

Oops. I should really stop making last-minute minor edits and then not testing them. I’ve submitted a fix.

I’ve just finished submitting the following batch of changes:

• Updating the kernel to add basic support for multiple GraphicsV drivers
  • OS_ScreenMode 11 to select the active driver (as per RISC OS Select)
  • OS_ScreenMode 64, 65, 66 and 67 for registering and deregistering drivers. See also the bottom of the GraphicsV page for an overview of the registration/deregistration process.
  • OS_ScreenMode 68 for enumerating drivers
  • VDU variable 192 is used to store the active driver (as per RISC OS Select)
• Tidying up handling of the HAL video calls so that
  • If they’re implemented, the OS will turn them into a bona-fide GraphicsV driver instead of just passing on calls for driver 0
  • They no longer need to be implemented if a GraphicsV driver exists in a module
  • Added GraphicsV 16 as a counterpart to HAL_VideoStartupMode (which was previously HAL-only)
• Support for new pixel formats at the GraphicsV/desktop level:
  • Added GraphicsV 17 so that drivers can list list all the pixel formats they support instead of just the RISC OS 3.5-era set of modes that are supported by GraphicsV 8
  • Added support for a new mode provider block format to allow Service_EnumerateScreenModes to list the new modes
  • Added support for VIDC list control list items 15 and 16 to allow the NColour and ModeFlags values to be specified (to complement the Log2BPP value that’s specified in the VIDC list structure body)
• Revised GraphicsV 10 and 11 so that in 16bpp modes the gamma table entries are supplied in a generic form instead of in the funny VIDC20 form
• Updated existing video drivers to add support for the new modes where possible:
  • Iyonix: FX-series cards will now advertise 32K colour modes as being red/blue swapped. Also added support for 64K colour modes. I’ve only tested this with an FX 5500 card, so if people could test 32K colour modes and 64K colour modes on other card types then that would be appreciated, as there are a few bits which need to be done differently depending on the card architecture.
  • IOMD: Added support for 4K and 64K colour modes
  • OMAP: When using TV-out, 16bpp and 32bpp modes will now advertise themselves as being red/blue swapped. There are also some further changes in the works to add support for 4K & 64K modes, but since that’s part of a driver rewrite which I haven’t fully tested yet I’m holding off on submitting it for now.
  • Pi: Added support for 64K colour modes

Note that once a new hard disc image is available, people will most likely want to update their copy of the screen setup plugin – the old plugin is buggy and might crash if it’s used on a system where the new screen modes are available.

Next on my todo list is to sort out multiple head support, including things such as display detection, head/driver selection from within the display manager, how to deal with different displays needing different MDFs, etc.

Jeffrey: Do you have any proposals for an API for hotplug of displays? Having needed to deal with EDID to get my Panda working I now think I understand what would be needed to complete the first 1/3 of the EDID bounty, and if time allows I’ll have a go at implementing it. Multiple displays will make that…err…interesting but shouldn’t cause major headaches one hopes.

I don’t have anything concrete, but my current thinking is that things will work along the following lines:

• For multiple head support, most GraphicsV calls will be extended to take the head number in bits 16-23 of R4, as per the proposed changes doc.
• A head will be classified as something which has video circuitry connected to it which is distinct from the circuitry used by the other heads managed by the driver. I.e. it’s possible to activate all the heads at once and use them to display different images to each other.
• But there’s a spanner in the works in the form of the Pandora (the TV-out cable has both S-Video and Composite, but there’s only one TV-out module in the OMAP) and some OMAP dev boards (on the beagleboard you can fit an LCD to the board – but it uses the same video signal as the DVI connector), and I suspect some PCI video cards (e.g. a cheap card with two VGA connectors and TV-out might only allow two of the outputs to be used at once). So we need to take into account devices where one head can have multiple outputs, and each output might have different mode lists available. For the sake of simplicity we’ll limit the API to only allow each head to have a maximum of one output active at a time. The existing select head call might be a good candidate for replacing with a “select output” call, perhaps with a proviso that the switch will only occur on the next mode change (as the current mode may not be valid for use on the new output). However if each output has different capabilites, then I’m not sure yet how to handle the detection of those capabilities without selecting that output as the active one. Maybe some calls will allow the output to be specified in bits 8-15 of R4, with a value of zero indicating the current output? Or maybe abuse the fact that the “select output” call will only have an effect on the next mode change? (Feels a bit nasty and subject to breaking as soon as threading/concurrency is introduced)

Taking the above into account, I’m thinking the display detection system should operate as follows:

• There’ll be a new GraphicsV call to request that a driver performs display detection
• As input, the caller will provide a list of heads which he wants to check, and a buffer to store the results.
• As output, the driver will return a sorted list of entries. The driver will sort the list by preference, so that the OS can easily decide which display to use on startup.
• Each list item will be as follows:
  • The head number
  • The output number
  • The connection state
• Different states are likely to include:
  • Connected
  • Disconnected
  • Detection not supported
  • Detection not supported due to driver being in power saving mode
• To simplify the act of allocating the buffer (since the size is dependent on how many outputs each head has) it might also make sense to have a call (or an alternate form of the same call) to allow the required buffer size to be read.

I’m thinking that somewhere (either as part of the results list or as part of a separate GraphicsV call) the driver should be able to indicate whether connection and/or disconnection can be detected automatically (i.e. by an IRQ, which will then trigger a service call). I’m thinking this automatic detection would have to be at the driver’s discretion (potentially also tied to an “I’m enabling automatic detection”/“I’m disabling automatic detection” service call), as the driver will be the one which knows best when detection is and isn’t possible/sensible. Case in point – TV-out detection on OMAP can only be performed if the hardware is powered on and generating a video signal. So if you’re using the TV then detecting disconnects comes virtually for free (and can easily be assigned to an IRQ), but if you’re not using the TV then you could waste a lot of battery power by leaving the TV detection running all the time.

Related to this, there also needs to be a service call to notify software of drivers starting/stopping (i.e. when OS_ScreenMode 65 & 66 are called). E.g. for a USB displaylink driver I’d expect the module to register and deregister GraphicsV drivers on the fly as the USB devices are connected and disconnected. And that may or may not correspond with display connection/disconnection, depending on whether it’s a device with a builtin LCD or a generic displaylink to VGA/DVI adapter. I was initially thinking ROL’s Service_DisplayStatus would be a good fit for this, but I’ve since decided against that as it’s geared towards their VideoV vector and not our GraphicsV vector.

I’ve just finished submitting the following batch of changes:

Not tried any of this yet, but sterling work, Jeffrey! Well done.

Jeffrey: could I suggest also adding to the GraphicsV supported features flags: EDID support?

Looks like EDID from the Pi isn’t returning anything useful, and VIDC will presumably be the same. It would be useful to read the flag to know when a driver supports EDID or not.

Jeffrey: could I suggest also adding to the GraphicsV supported features flags: EDID support?

Could I suggest instead a new GraphicsV op to return the EDID block? Rather then being IIC ops, the driver itself will obtain the EDID; with a null block meaning there is no data.
In this way, the information can be obtained and additionally by devices that present a different method of reading this information. It doesn’t look too hard to read the info on the Pi, but it is something best done at driver level and all the necessary code already exists as far as I can see…

RFC?

Jeffrey: could I suggest also adding to the GraphicsV supported features flags: EDID support?

An “EDID support” flag doesn’t make much sense – after all, it’s the IICOp call that’s returning the EDID, and without probing the bus itself the driver won’t know if there’s a monitor there capable of returning the data.

One of the things that yesterday’s changes will have fixed was a bug which meant that on the Pi the IICOp call was reporting success, even though nothing was happening. So if you try again with today’s ROM you should get a sensible result (the GraphicsV call will be left unclaimed, i.e. R4 unmodified).

For VIDC, the driver currently generates a fake EDID block and returns that when it receives a suitable IICOp call. The block is basically empty apart from the sync type, which the driver detects by probing the ID pins. But despite lacking any mode timing information it should be a valid block.

Could I suggest instead a new GraphicsV op to return the EDID block? Rather then being IIC ops, the driver itself will obtain the EDID; with a null block meaning there is no data.
In this way, the information can be obtained and additionally by devices that present a different method of reading this information. It doesn’t look too hard to read the info on the Pi, but it is something best done at driver level and all the necessary code already exists as far as I can see…

We could do, but why make a call that’s limited to just reading the EDID block, when we’ve already got a more general interface available? Sure, the Pi might not allow us direct access to the IIC bus to read the data ourselves, but it’s trivial to create a fake GraphicsV IICOp implementation which returns the EDID block the GPU gives us.

Back to the topic of multiple heads/outputs for a moment – I’m now thinking that having to specify both the head and output when making GraphicsV calls is a step too far and introduces too much complexity to the API. So instead I’m thinking that each output will be treated as its own head, and for the cases where one head/output can’t be active at the same time as another, a DriverFeatures or HeadFeatures call will return a list or mask of which other heads can’t be active at the same time as that head. As far as I can tell this will simplify the most common cases (reading the details of heads, switching output between heads, drivers which have no limitations on how many heads/outputs are active, etc.) while only complicating software which will want to drive multiple heads at once (as it will have to do a bit of work itself to deduce the dependencies between heads). Thoughts?

Jeffrey: Ah – I had presumed the Pi’s output was the ‘intended behaviour’. The problem is not so much monitors that don’t support it, but video output devices that don’t (both because they are legacy – or of course because they are ‘virtual’ devices – dual monitor display RPCEmu by having two windows with different ‘screens’ on each?!?). To offer EDID, we have to use a ‘Use EDID if available’ flag (as oppose to use MDF).

I had expected several possible outcomes in configuration:

1) We don’t respond (or flag set saying it’s unsupported) – the device can’t offer EDID, so grey the option.
2) The EDID block is nonsense/empty: this particular monitor doesn’t support it (or when you were configuring no monitor was attached – possibly because you used VNC etc) but others might. Warn the user this is unwise to set EDID as the current monitor doesn’t support it, but if they insist keep it enabled and use fallback modes as needed.
3) EDID returned fine.

Obviously it’s important to distinguish between case 1 and case 2 – case 1 means don’t offer it, and case 2 should mean we still offer it with warnings.

Agree – I can’t really see a case for another API interface for EDID because those cases should be edge cases and can be faked if need be.

Another question: I assume that returning R4 unchanged if unsupported and not doing anything silly (ie. like crashing) is mandatory? So if the Screen plugin were to call GraphicsV just to see whether R4 had changed or not at plugin startup would be safe – there is no reason why this would

Another question: I assume that returning R4 unchanged if unsupported and not doing anything silly (ie. like crashing) is mandatory?

Correct.

So if the Screen plugin were to call GraphicsV just to see whether R4 had changed or not at plugin startup would be safe

Yep, that should be fine. And if we some day find out that it isn’t fine (e.g. there’s a driver which has to implement the IICOp call but we know will never support EDID) we can at that point decide that a “supports EDID” flag or “return EDID block” call is a better way of doing things :)

I’m not sure if you’ve spotted it or not, but if the IICOp call is implemented then it will provide a return code in R0. IICStatus_Completed will be returned if the data was read OK (although there’s still the chance of the EEPROM in the monitor containing corrupt EDID data), and IICStatus_NoACK will be returned if there was no response (i.e. no monitor connected or monitor doesn’t contain an EDID chip). Other return codes are likely to be caused by temporary transmission errors.

Jeffrey – the Screen Plugin and the latest ROM.
Tested, as usual on RPCEmu, this has a bit of a fit trying to display the resolution information in the drop down.

Is this a problem with the plug-in or RPCEmu feeding the new graphics handler with incorrect information?

NB. Not a problem for me, just poking and testing.

It’s a bug with the plugin. If all goes well there should be a new hard disc image available tomorrow morning with a fixed version (it would have been available today, but the automated disc image builds have been disabled for a while now due to a problem with Perl – but we think that’s been fixed now, so ROOL are going to try re-enabling the automated build)

It’s a bug with the plugin.

OK, time for a beer¹ and then check tomorrow.

¹ I keep a stock at a cool room temperature (cold means you can’t taste it properly, although with stuff from big brewers that’s probably a bonus)

The ZIP file version of the disc update seems to have failed to update.

The ZIP file version of the disc update seems to have failed to update.

The self extractor version did update but the file date appears to be showing as 16 Dec rather than 17 Dec.

For the record the available self extractor version has the fixed version of the screen plugin.

Initial:
Intrigued by the 4096 colour option in the AKF60 I selected it and got a “buffer too short” error. Selecting a more normal 32000 colour option worked fine.

Intrigued by the 4096 colour option in the AKF60 I selected it and got a “buffer too short” error. Selecting a more normal 32000 colour option worked fine.

Well spotted – I guess I didn’t think to check whether the buffer used by the Colours box would be long enough! I’ve now submitted a fix.

Well spotted – I guess I didn’t think to check whether the buffer used by the Colours box would be long enough! I’ve now submitted a fix.

Thanks for that but really it was idle prodding rather than a systematic check.

A few questions from a practical perspective:

MBBack works by reading the mode variables of the current mode, reading the mode variables of an input sprite’s mode word, then creating a new sprite which has a mode word equivalent to that of the current mode. So, for example, if you display a 32bpp sprite in an 8bpp mode, it’ll get reduced to 8bpp before being passed to the Pinboard.

The tricky bit is forming the new sprite mode word and allocating the correct amount of memory to hold the new sprite, and there I suspect the new formats are going to throw a spanner in the works.

First off, does RO5 behave like RO6, in that for a 64K colour mode, Log2BPP is returned as 4 but additionally bit 8 of ModeFlags (“fully definable 256 colour palette”) is set to 1?

Secondly, do 4096 colour modes and sprites support palettes?

How much do I need to know about the new formats in order to enhance MBBack to produce them? I presume at the very least I will need to teach it about the new mode words. And how can I determine, from a mode word and set of dimensions, how much memory a sprite of any format will take? Now Log2BPP can be 6 or 7, it won’t be as simple as shifting right by 3 and word-aligning any more, will it?

Could I put in a request for an enhancement to the OS APIs, assuming it doesn’t exist already and I haven’t stupidly missed it? Given a sprite mode, x and y dimensions, and masking/palette flags, calculate how much memory a sprite will occupy. This task has never been simple, and seems likely to get a whole lot more complicated.

I’ve just realised that you can in fact use the value returned from OS_ScreenMode 1 as input to OS_SpriteOp 15, so I suspect I’ll be taking advantage of that in the near future.

The tricky bit is forming the new sprite mode word and allocating the correct amount of memory to hold the new sprite, and there I suspect the new formats are going to throw a spanner in the works.

Correct. I’m somewhat surprised that there isn’t a SWI to generate a sprite mode word for a given screen mode. The way I’ve seen the OS do it when it wants to cache a sprite in the current screen mode is to use OS_SpriteOp 16 to create a sprite from an arbitrary portion of the screen, and then redirect output to it and use OS_SpriteOp 52 to plot in the desired sprite. You’ll still have to calculate the memory requirements manually, but the sprite mode word generation and initialisation of the sprite palette will be fully handled by the OS.

First off, does RO5 behave like RO6, in that for a 64K colour mode, Log2BPP is returned as 4 but additionally bit 8 of ModeFlags (“fully definable 256 colour palette”) is set to 1?

Yes. See Valid Mode Variable Combinations for a list of all modes supported by all OS versions.

Secondly, do 4096 colour modes and sprites support palettes?

No.

How much do I need to know about the new formats in order to enhance MBBack to produce them? I presume at the very least I will need to teach it about the new mode words.

If you use OS_ReadModeVariable to examine the sprite mode words, and use OS_SpriteOp 16 to create a sprite in the same mode as the screen, then you shouldn’t need to know anything about the structure of the sprite mode words.

And how can I determine, from a mode word and set of dimensions, how much memory a sprite of any format will take? Now Log2BPP can be 6 or 7, it won’t be as simple as shifting right by 3 and word-aligning any more, will it?

Although Log2BPP of 6 and 7 have been defined in the spec, at the moment there’s only rudimentary support for them in the OS. In particular I suspect it will be a long time until you see the desktop start using Log2BPP of 6 or 7 (too much stuff assumes Log2BPP really is the log2 of the BPP). However at some point in the future you might start seeing sprites which use Log2BPP of 6 and 7.

Could I put in a request for an enhancement to the OS APIs, assuming it doesn’t exist already and I haven’t stupidly missed it? Given a sprite mode, x and y dimensions, and masking/palette flags, calculate how much memory a sprite will occupy. This task has never been simple, and seems likely to get a whole lot more complicated.

Sounds like a sensible idea. I’ll probably make it so that you can pass in any old mode specifier, and it will return both the size of sprite needed and the corresponding sprite mode word – so it can serve double-duty as both a way of converting mode specifiers to mode words and calculating the size of a sprite.

I’ve just realised that you can in fact use the value returned from OS_ScreenMode 1 as input to OS_SpriteOp 15, so I suspect I’ll be taking advantage of that in the near future.

Yes, that’s also a good way of dealing with things. Probably better than OS_SpriteOp 16 in most cases as it will avoid the pointless read from screen memory.

@William: if you’re thinking of having a pop at the EDID support, another thing you should be aware of is the CEA-861 extension blocks which can be present after the legacy EDID block. These are increasingly common on modern sinks (e.g. TVs) and should probably be used in preference to the legacy EDID info – with parsing that being the fall-back position.

You have to read the wording of the specifications for EDID very carefully (and they aren’t free, so you’ll probably just have to read other pages, like Wikipedia, instead); its possible for lists to be empty, for multiple entries to be flagged as “preferred”/“native”, for the first entry not to be the one flagged as “preferred”/“native”, for none of the items to be flagged at all (in which case you should usually prefer the first one listed) and for the info in the EDID block to simply be incorrect (especially in cheaper/older sinks).

Parsing EDID is the sort of thing that you eventually fine-tune after throwing lots of different hardware (and connection types, e.g. HDMI, DVI, etc) at it… so, exactly the sort of thing all our intrepid users (those who try the odd-numbered builds) can help with. I’d advise that you implement a command to dump the EDID data to a file for debug purposes – if anyone finds odd behaviour with their setup, they can send that which would help enormously with figuring out what’s going on.

@Jeffrey – at some point, it might be good to have a plain English summary of what the work you’ve been doing will mean to users, both in real terms and in terms of what potential features it’s opening up. Apologies if that’s already on the wiki and I’ve missed it. It’s basically the sort of stuff we will want to put in the 5.22 release note when that release comes around (probably not until April ’14 at the earliest).