Display scaling and other issues

You can export the text from Impression using Document Description Format (DDF), which is easily (…) edited to other formats for import into other programs. It’s a bit of a pain if the text is in multiple unconnected frames, or if there are lots of illustrations, though.

I used to have apps to do conversions from Impression to HTML, but I’m afraid I’ve not maintained them since leaving J Physiol and indeed I don’t think I even have them any longer.

the most likely option – they don’t want to be stuck with a bunch of files that they can’t do anything with, other than continue using Impression…

There’s a converter in Ovation Pro

There’s a converter in Ovation Pro

That’s Impressive – Impression file format is an amazing tangle.

There’s a converter in Ovation Pro

…how well does it work? Is it able to handle everything Impression can throw at it, and recreate complex documents without messing up?

I don’t have any Impression docs to try (always been an Ovation(Pro) user), but I have observed some “differences” loading original-Ovation documents into OvationPro. Nothing major, but not exactly identical.

…how well does it work? Is it able to handle everything Impression can throw at it, and recreate complex documents without messing up?

Not actually had to convert any files in the last ten years+ so I really can’t recall.
I do recall that like the differences in Ov and OvPro there are differences in layout. I suppose if someone wanted to engineer a new version that produced a better match it might be useful.

…how well does it work? Is it able to handle everything Impression can throw at it, and recreate complex documents without messing up?

The Impression loader is very good in my experience, but it cannot bridge the major differences between OvationPro and Impression wrt master page handling for example. But you’d have to ask the die-hard Impression users for more details – all I still remember is that if you are used to structure your documents in a certain way with master pages in Impression, it is nearly impossible to get used to the OvationPro way of things.

all I still remember is that if you are used to structure your documents in a certain way with master pages in Impression, it is nearly impossible to get used to the OvationPro way of things

It’s not just me then!

When I moved from Physiology to ARM (20 years ago now – blimey!), I had to get used to the FrameMaker way of doing things. Quite a wrench from Impression Publisher Plus, but I managed. Needs must and all that. And now I’ve moved to LibreOffice – fortunately not (mostly) doing anything with quite so much structure (although my current project has – aaarrrghhh!) – because I don’t have either Impression or Framemaker available. Generally I like LibreOffice, but it does have some annoyances.

If Impression was available for RISCOS/Pi3 at a reasonable price, and could reliably produce good PDFs acceptable to commercial printers, I’d be interested.

Dragging this discussion kicking and screaming back on topic: I had a bit of a think last night about how best to adapt the GraphicsV API to allow it to deal with the framebuffer row stride requirements of the Pi (and other platforms), within the context of future planned work like improved VetMode feedback in general and fancy memory mapping for multi-monitor setups

While thinking about it I realised that the problem would become a lot simpler if feedback on the mode timings and feedback on the framebuffer were handled separately. So far I think most of the discussion about improved mode vet feedback has focused on how the improved feedback could be used to massage mode timing, e.g. when generating custom modes based around EDID, or as part of an improved MakeModes tool. But that’s always been a very nebulous thing (the rules for what mode timings are/aren’t acceptable can be pretty complex), so by ignoring mode timing feedback and focusing on just framebuffer feedback the problem becomes a lot simpler.

With that in mind, I’m thinking that most of our requirements for framebuffer feedback could be handled by the following new GraphicsV entry:

In:
R0 -> VIDC list type 3 (read-only)
R4 = reason code + driver number

Out:
R0 = flags:
     bits 0-1:
      0 -> driver can't support the mode/framebuffer arrangement; R1-R3, R5 undefined
      1 -> framebuffer can be placed in any VRAM (i.e. use DA 2); R3 & R5 undefined
      2 -> framebuffer must be placed in external framestore (as defined by R3 & R5)
      3 -> framebuffer must be placed in a specific location (but driver doesn't know where yet); R3 & R5 undefined
     bit 2: 1 -> ExtraBytes value provided in input was not acceptable, the new value provided in R2 must be used instead
       (this is just a hint so that the caller doesn't have to parse the full control list to work out if the new value needs injecting or not)
     bits 3+: reserved
R1 = required alignment of start of framebuffer (as per GraphicsV 8)
R2 = required/suggested ExtraBytes value (must be >= the value given in the VIDC list)
R3, R5 = external framestore base and size (as per GraphicsV 9)
R4 = 0 (call claimed)

In terms of functionality, it will vet the VIDC list as per GraphicsV 7, but with the exception that the driver can override the provided ExtraBytes control list item with a new value.

So for the use case of dealing with 1366-width modes on the Pi, when ScreenModes builds and vets a VIDC list it can try using this new call instead of the old vet call, and if the mode is supported (bits 0-1 of R0 non-zero) it can add the suggested ExtraBytes value on to the end of the VIDC list (then when the kernel goes to set the mode it can read that value from the control list and use it to adjust its memory allocation)

For multi-monitor systems, the multi-monitor manager will want to be able to plan the memory layout of the framebuffers ahead of time to try and work out the most optimal memory mapping for the CPU to use. By returning information about the memory area the framebuffer must be placed into, this will allow the system to cope with drivers which have unpredictable memory allocation strategies – e.g. on the Pi the GPU is in full control over the framebuffer address, so bits 0-1 will always be 3. Or on OMAP, the framebuffer will need to be in different places depending on whether display rotation is in use or not (and unlike the Pi we can change the rotation at runtime). The requirement that the new ExtraBytes value must be >= the provided value allows for the multi-monitor manager to use an iterative approach to finding values which all the drivers are happy with – the output of one feedback pass can be used to adjust the input to the next pass. If the ExtraBytes value becomes too large then a driver can complain (return with bits 0-1 zero), or if there are too many loop iterations the multi-monitor manager can give up and assume the arrangement is impossible.

GraphicsV 7 will probably be re-specced to say that:

• There’s no mode workspace list provided (I’m not sure if one has ever been provided)
• The “minor edits” to the VIDC list mustn’t affect the framebuffer layout (so e.g. driver can massage the timings a bit in order to make them work, but they can’t go adjusting the ExtraBytes value to arrive at an acceptable framebuffer row stride – because there’s never been any sensible way to feed back that new value to the caller)
• The input VIDC list should be treated read-only (keep your “minor edits” to yourself)

Can anyone spot any problems with the above?

Over the weekend I had a go at implementing the new mode vet call. I was half expecting to need to fix a bunch of things, but surprisingly the OS seems to work OK with modes where LineLength != (XWindLimit+1) << (Log2BPP-3) (i.e. situations where the ExtraBytes control list item has been used). I guess the widespread use of graphics windows, redirection to sprites, etc. means that most bits of code will already be designed to cope with that kind of situation.

I still need to update the kernel to use the new GraphicsV call (for the builtin VIDC lists), but since that’s basically the last thing that needs changing it shouldn’t be too long until the code reaches CVS. Apart from allowing the 1366-width pi-top mode to work, this should also allow a few other standard modes to work (e.g. 720-width modes in 8bpp, and 360-width modes in all colour depths – currently 360-width modes in 32bpp will just appear garbled, it looks like the row pitch needs to be a multiple of 32 bytes and 16 pixels, which previously BCMVideo wasn’t checking for)

I still need to update the kernel to use the new GraphicsV call (for the builtin VIDC lists), but since that’s basically the last thing that needs changing it shouldn’t be too long until the code reaches CVS

Of course, I then took a closer look at the code and realised that the kernel doesn’t vet the builtin VIDC lists. It checks that the driver supports the BPP, but that’s it. Doh!

So the new plan is likely to be that I’ll submit my updated code as-is (allowing MDFs & EDID to work), and tackle the builtin VIDC lists in a later checkin which will be focused around trying to tidy up the numbered mode handling

Some thoughts about where and how different settings should be configured.

An assumption is being made that users will only infrequently change which monitor(s) are connected to their machines. So the VMDF should focus on describing the modes the user wants to use with their current monitor setup, not the modes they want to use with all of their potential monitor setups.

With that in mind, it means that there’s no need for the VMDF to contain the ability to explicitly filter the availability of modes based around what monitor is connected, or what video driver is in use. The only filtering that will occur will be the implicit filtering that comes as a result of restrictions enforced by the video driver or underlying MDF/EDID.

Rotation will be a configuration setting, rather than a feature of the mode. I.e. the user will use the display manager to select the rotation of their display(s), and all future mode changes (via any API) will use that rotation. This also means that, e.g. OS_CheckModeValid won’t report that a mode is available if it can’t be supported for the current display rotation.

Multi-monitor setups are a bit different. A typical use case would be a multi-monitor desktop, but switching to single-monitor for single-tasking games/apps. So on a per-mode basis we’d want to configure whether the mode is multi-monitor or single-monitor. The physical arrangement of the monitors, however, should be a global configuration setting. This would encompass where the monitors are in relation to each other, and any scaling differences (e.g. if you have two monitors that are natively two different DPIs, you may prefer for one of the displays to be scaled so that windows won’t appear to change size when you drag them from one to another). There’ll also be an option to control behaviour of single-monitor modes (within a multi-monitor context); i.e. the ability to specify whether single-monitor the mode should be mirrored across all displays, or whether it should only be displayed on your primary display (and which display that primary display is).

This means that the only VMDF settings that relate to multi-monitor operation would be a flag to say whether the mode is available for single-monitor use, and a flag that says whether the mode is available for multi-monitor use. The system should be able to work out for itself that e.g. a 3840×1080 mode should be displayed on two side-by-side 1080p monitors by having each of them run at 1920×1080.