Screenmode IDs "rearranged" on boot sometimes

[whose]

Hi!

I experience a strange problem recently.

Sometimes on bootup a prefs-saved WB screenmode is reset to the monitors default or "preferred" resolution (as it should be with automatic mode, if a different monitor is plugged in). First I thought it is a bad VGA connection, but then I realized that in this case NO of the available modes for my monitor would be listed, just fake native and standard VGA modes.

In this case here, all monitor resolutions ARE displayed/listed, but the screenmode IDs are "rearranged" so that a requested screenmode ID isnt found! This is for programs requesting a screenmode ID (I didnt test all my programs yet, but e.g. CodeBench "forgets" about its screenmode sometimes, too), but it doesnt happen on every boot.

The same monitor works fine for a Windows machine, connected the same time (2 inputs, switchable). Monitor is a HP p1130, Amiga is a SAM440ep.

Maybe a problem with latest IPrefs?

[xenic]

I experience a strange problem recently.

Sometimes on bootup a prefs-saved WB screenmode is reset to the monitors default or "preferred" resolution (as it should be with automatic mode, if a different monitor is plugged in). First I thought it is a bad VGA connection, but then I realized that in this case NO of the available modes for my monitor would be listed, just fake native and standard VGA modes.

In this case here, all monitor resolutions ARE displayed/listed, but the screenmode IDs are "rearranged" so that a requested screenmode ID isnt found! This is for programs requesting a screenmode ID (I didnt test all my programs yet, but e.g. CodeBench "forgets" about its screenmode sometimes, too), but it doesnt happen on every boot.

Maybe a problem with latest IPrefs?

I've experienced similar problems over the years since I first started using OS4. It happened when I upgraded to OS 4.1 from OS 4.0, when I changed monitors and at least once after an OS4.x update. It was really a pain because I had to change the prefs in all the programs that remember screen resolution by ModeID. In your case, it sounds like the system isn't getting the right information from the monitor sometimes. Maybe you have a loose monitor connection or something. I don't really understand why the ID numbers can change.

[chris]

Programs are not supposed to remember the ModeID, rather they should request the mode through use of BestModeID() and the various attributes of the mode required.

In practice though, this doesn't happen, because it's a PITA to store all the possible attributes that uniquely identify the mode, and pass them back to BestModeID(), and even then there's no guarantee the mode returned is the one the user selected last time.

So, yeah, everybody just stores the ModeID (and I'm guilty of this too), which was fine on classic hardware where the IDs were pretty much fixed, even between different models, but on OS4 and RTG hardware, the IDs are assigned according to configuration. They don't normally change between boots though.

[xenic]

Programs are not supposed to remember the ModeID, rather they should request the mode through use of BestModeID() and the various attributes of the mode required.

In practice though, this doesn't happen, because it's a PITA to store all the possible attributes that uniquely identify the mode, and pass them back to BestModeID(), and even then there's no guarantee the mode returned is the one the user selected last time.

So, yeah, everybody just stores the ModeID (and I'm guilty of this too), which was fine on classic hardware where the IDs were pretty much fixed, even between different models, but on OS4 and RTG hardware, the IDs are assigned according to configuration. They don't normally change between boots though.

Unless the ModeID bits are flags of some sort, there is no shortage of ModeID numbers (64k). I don't see why the system couldn't keep a database of all ModeIDs (& their attributes) that have been used on a particular system and compare those to any new modes obtained from the current monitor and use a new mode that is equivalent to one that is requested by a program and exists in the database (but add the new mode to the database).

SInce most people are using LCD monitors that only have an optomal display in their native resolution and the native resolution is used for WorkBench, I think the standard ASL screen requester should should have a "Clone Workbench" mode in the modelist (or as a seperate button) or a Tag for programmers to add a "Clone WorkBench" mode to the ASL screen mode list.

I agree that ModeID's shouldn't normally change between boots. On some extremely rare occasions my system has fallen back to a default screen mode when I reboot. In most cases I think it was caused by an error or crash in a running application. In whose's case, maybe there is a flaw in the graphics card of the driver.

[chris]

Unless the ModeID bits are flags of some sort, there is no shortage of ModeID numbers (64k).

The top two-and-a-bit bytes are for the monitor ID, there doesn't seem to be much logic to how the lower bits are used (see graphics/modeid.h). If they were assigned based on pixel resolution and depth, rather than sequentially (as they are at the moment for RTG), then they would be more static.

As far as I can tell, how they are assigned is wrong anyway - the monitor portion of the mode ID is increased for each resolution (this explains why some "use the same monitor as WB, but in this different resolution" BestModeID code I wrote a while back doesn't work), and the low order bytes are:
0x000 CLUT8
0x102 RGB16
0x300 ARGB32

I assume there is some logic to those numbers.

Can we at least get the resolution incremental part shifted OUT of the top two bytes, so monitor-matching works again, please?

[whose]

@xenic:

I didnt experience the problem for while now... for me, it looks like a side effect of my mouse driver problem. As far as I can tell, it doesnt happen anymore since I moved the driver into the Kickstart. In exchange I have other problems I hope, these problems will be solved, soon. Im in touch with OS4 team regarding the mouse driver problem...

But I agree with chris, nonetheless. The ModeID assignment should be more canonical.

[fingus]

I just experienced this problem together with the Screen-Prefs after changing Graphic-card (what is maybe okay) or Monitor.