WimpMode query
Martin Avison (27) 1425 posts |
With a screen running with a mode of: However, if on a Dual-screen Titanium the mode is: The only descriptions I have found for *WimpMode indicate that EX and EY are optional, and if omitted the default will be used, which I believe is 1. This effect is very noticeable on any displayed windows, but can can also be seen either by DisplayManager → Menu → Mode, or by having a program watching for &400C1 Mode Change messages and using OS_ReadModeVariable to get the values, or by a module watching for Service_ModeChange. It also can cause other problems: eg a program which reacts to a mode change by getting the values and reacting wrongly. This problem is compounded by the Display Manager, because if it is used to make the change it just issues a *WimpMode without th EX1 and EY1 parameters. Can anyone verify my findings, or better still suggest any explanation for it? My suspicion is that it could be a bug in the *WimpMode code. Edit: |
Jeffrey Lee (213) 6046 posts |
The default eigen values aren’t always 1. If the mode height is less than half the width, it’ll use EY2 (a throwback to modes like 640×256) https://gitlab.riscosopen.org/RiscOS/Sources/Kernel/-/blob/Kernel-6_37/s/vdu/vduswis#L384 Possibly there are other bits of the OS which implement that same logic, but I think the kernel is the main place. |
Martin Avison (27) 1425 posts |
Thanks Jeffrey – that explains the problem I saw. It means that if the colour depth is changed (and maybe other similar changes) in any mode where height < width/2, the result will be a corrupted screen – particularly if Display Manager is used. That does not seem right to me – and it has certainly caused me many wasted hours. |
Jeffrey Lee (213) 6046 posts |
Yes – PRM5A, OS_ScreenMode 0. It’s just not made totally clear that the defaults listed there apply to *WimpMode and OS_ReadModeVariable as well.
A related issue is that of EX0 EY0 modes, which has come up from time to time on the forums. Changing the kernel so that it can ask ScreenModes (or other mode providers) what the default eigen values should be feels like the right kind of solution, but I’m not sure what other changes would be needed beyond that.
|
Rick Murray (539) 13422 posts |
Given that you say:
Maybe the behaviour could be clipped so that it doesn’t happen for modes where the width is more than, say, 1024? [what’s the biggest this actually needs to be? my gut feeling is less] In that way, old style modes get the 1,2 behaviour while modern and very wide modes such as the one you mention aren’t affected and remain 1,1 or 0,0. |
Andrew Rawnsley (492) 1415 posts |
Side note that if you’re running with !DualHead / !MultiMon combination (as with our Titanium software), !MultiMon should auto-correct this on mode changes, AFAIK. That’s its job, anyway – I use it all the time on my RISCube to auto-correct 3840×1440 which otherwise defaults to the wrong eigen values. |
Martin Avison (27) 1425 posts |
Normally I do run DualHead & MultiMon, and they do normally hide the problem from the user. I stopped them so I could investigate this problem without them helping/confusing. Now I know the underlying problem, I can go back to the original problem I saw with them running. Thanks for letting me know they are involved in this. |
Martin Avison (27) 1425 posts |
Gosh, yes. There is an (obscure) reference there, on page 5a-136. That is about the one place I had not looked … but I had looked in my paper PRM5, and it is also in there on page 5-109 but I had missed it. It is certainly not obvious that it applies to *WimpMode. Indeed, I can find little documentation for that at all, even in the RO5 User Guide. In PRM5-105 it talks about Mode Strings, as used by *WimpMode, but just says EX and EY are optional and the default is used if not given. With no references to what defaults. Regardless of the underlying processing, I still think that changing the colour depth in Display Manager or *WimpMode on a X3360 Y1050 screen should NOT change EY from 1 to 2. I support Rick’s proposal that EY should only be changed if the width is less than eg 1024. |
Martin Avison (27) 1425 posts |
To add to this problem, I have just gone back to running RComp MultiMon on my TiMachine, and indeed it detects the change to EY2, and changes it back to EY1. That would be fine, but I run two apps which act on the Message_ModeChange and read the EY2 value. The first one data aborts with a ZeroPain, and the other fails with a message from an IconSprites command that a file cannot be found … which is there! (I suspect it may be looking for one with another suffix). Both may be program errors having to cope with an unanticipated situation. The first is not my app, but the second I may be able to fix, as I have the source. The screen suddenly doubling in width (in OS Units) may be an issue. It was these problems which started me on this trail of investigation. There may be many other apps which are similarly affected, as it is a common thing to act on mode changes. |
Bryan Hogan (339) 563 posts |
Mode 16 is 1056×256 so the cutoff point will need to be set higher than that. I used to use that on my A3000 when looking at two files side by side, although it was not easy to read on the old 14" CRT monitor! |
Martin Avison (27) 1425 posts |
True. Modes 16, 17, and 24 all have height < width/2, have width 1056, and they are the widest. |
Rick Murray (539) 13422 posts |
Okay, then the cutoff should be “greater than 1056”, as that’s the largest width of a numbered mode that has a very small height – https://www.riscosopen.org/wiki/documentation/show/Screen%20Modes I feel that anything larger than that is likely to be done intentionally and wouldn’t appreciate EY being munged for hysterical raisins. |