Service_EnumerateScreenModes changes

Hi,

I noted Jeffrey’s recent change to the block returned in Service_EnumerateScreenModes. Am I correct in thinking that pre-existing recipients of this service call will not be able to recognise the new variant of this service call if any type 1 blocks are present?

If that’s the case, potentially existing clients for Service_EnumerateScreenModes will break in any case – why not send type 1 data blocks by default and deprecate type 0s?

For multiple display devices, we could also extend that call out by changing R2 on entry:

R2 bits 0-7 – monitor type flags.
bits 8-15 – display number (we may need less bits than this – depends what your defined ‘maximum’ is).

Not that I’m fancying the task of doing the modifications at this stage (ScreenModes will need quite a rework for this) – we would probably want to set up screen modes to check EDID types for each attached display, and then keep multiple linked lists, which are then vetted by the driver – so each display has its own list of modes, which are validated for that display. It then responds to an enumerate modes request by returning the list for a specific device.

Obviously *LodeModeFile / *ReadEDID have to take device number as an additional parameter.

Am I correct in thinking that pre-existing recipients of this service call will not be able to recognise the new variant of this service call if any type 1 blocks are present?

From the Service_EnumerateScreenModes information in PRM 5A:

Future modules may use different mode info formats, therefore callers should check bits 0 – 7 of the mode provider flags before extracting the other information in this block. If the caller doesn’t recognise the mode info format for an entry, then it can skip the entry by using the size field at offset 0. For format checking purposes, bits 8 – 31 should be ignored.

Unfortunately not everyone (including Acorn themselves) have heeded that warning and so some software will break when it sees the new format block. Even I’ve been inconsistent – some of my older software checks OK, but newer stuff (e.g. ArcEm) doesn’t.

If that’s the case, potentially existing clients for Service_EnumerateScreenModes will break in any case – why not send type 1 data blocks by default and deprecate type 0s?

Just because software might break, we shouldn’t aim to break it completely. I tested a few different bits of software before checking in the changes, and found that it was only software which tried to look at the mode names which broke in a particularly bad way. Software which just looks at the X/Y/colour depth information (which seemed to be the majority of the software) seemed to fail a lot more gracefully, by failing to recognise/make use of the Log2BPP (which in the new block is the NColour value) with the net effect that the entry was effectively ignored.