Monitor ID from monitor name

BSzili · 17 February 2021, 10:05

Is there a way to map monitor names (e.g. "pal.monitor") to monitor IDs I can pass to the BestModeID function via BIDTAG_MonitorID tag? I'm trying to add a convenience option to my screen opening function, so the user can force it to only use screen modes of a specific monitor.
I looked at OpenMonitor, but couldn't find anything related to the id in the MonitorSpec structure. As a last resort I could make a function where I hardcode the common name-id pairs ("pal.monotor" -> PAL_MONITOR_ID, "ntsc.monitor" -> NTSC_MONITOR_ID, etc.), but I would prefer to avoid this to keep the code flexible.

Thomas Richter · 17 February 2021, 19:32

Quote:

Originally Posted by BSzili

Is there a way to map monitor names (e.g. "pal.monitor") to monitor IDs I can pass to the BestModeID function via BIDTAG_MonitorID tag?

For that, traverse the display info data base with GetDisplayInfoData() (see its documentation), and check for the struct NameInfo (see graphics/displayinfo.h), i.e. DTAG_NAME for the mode name, or DTAG_MNTR for the struct MonitorInfo. In there, is a struct MonitorSpec. Its node structure (see graphics/monitor.h) has the name of the monitor.

BSzili · 18 February 2021, 07:03

I didn't know the node name of the MonitorSpec struct was the monitor name. That did the trick, thanks!

Thomas Richter · 18 February 2021, 07:55

My concern is that the monitor name is rarely useful, i.e. it is not shown in an ASL requester, and it is not necessarily the name of the icon in DEVS:Monitors. The later can be changed by the user to whatever he wants. It is better to enforce a particular mode ID. The monitor-dependent part of the mode ID are the 16 most significant bits - they stay constant throughout all modes of a particular monitor.

Why graphics does this "dual housekeeping" of the display info data base, and the monitor, I do not know. There must be some legacy reason for that I'm not aware of.

BSzili · 18 February 2021, 12:07

I thought about using the monitor ID first, but how does the user find out the ID of a particular monitor? Since the file name can be changed, I'm probably better off hardcoding the names of the monitors that ship with AmigaOS: NTSC, PAL, Multiscan, Euro72, Euro36, Super72, DblNTSC, DblPAL. These names should stay consistent with the ones shown before the modes in the ScreenMode prefs, even if the monitor file was renamed.

Thomas Richter · 18 February 2021, 14:25

If you mean "monitor", you do mean the name of the icon in DEVS:Monitors? Unfortunately, you cannot in general predict which IDs the monitor icon will generate, and as the user can rename the icon as desired, there is no clear correspondance between icon name and installed modes.

There are some system conventions for the system provided monitors (PAL,NTSC,EURO36,SUPER72,Multiscan), but as soon as you go to RTG graphics, it is an individual choice of the user, made at the time a graphics card is setup at installation time.

I just wonder why that information is useful? What is useful is the *mode name* as this is what pops up in the workbench screen mode and the ASL requester, and what is useful are the mode properties you find in the display info database.

Concerning display IDs, this is a 32 bit number, as stated, of which the 16MSBs are the monitor ID, and the LSBs are the mode information. One cannot, in general, conclude from the mode ID to the mode properties - that's what the display info data base is good for.

BSzili · 18 February 2021, 16:22

By monitor name I meant the mode name, not the actual monitor file name, sorry for the confusion. The problem I'm trying to solve is when a user has a bunch of monitor files in DEVS:Monitors instead of Storage, which causes the BestModeID function to pick some unexpedted mode. By restricting the display ID I could tell the user to set a tooltype in the program's icon to PAL for example, so they don't end up with a MULTISCAN modes even if they have the corresponding monitor file in DEVS:Monitors.
I don't intend to restrict RTG modes this way, as they already take precedence when I open the the screen, and most users don't have more than one RTG board in their system.

Thomas Richter · 18 February 2021, 18:51

The typical solution to that problem is to use an ASL screen mode requester, probably both to select a mode, and to setup a default mode for the program configuration that ends up in the tool types. You can add a filter function to the ASL screen mode requester and by that restrict the modes seen by certain properties.

BSzili · 19 February 2021, 06:55

That would be the most flexible solution, but the games I intend to use this code in have on-the-fly resolution switching. To me opening an additional requester when the resolution is changed is a bit too much.
This way can set a tooltype and still have a set of resolutions available in the game.

17 February 2021, 10:05	#1
BSzili old chunk of coal Join Date: Nov 2011 Location: Hungary Posts: 1,289	Monitor ID from monitor name Is there a way to map monitor names (e.g. "pal.monitor") to monitor IDs I can pass to the BestModeID function via BIDTAG_MonitorID tag? I'm trying to add a convenience option to my screen opening function, so the user can force it to only use screen modes of a specific monitor. I looked at OpenMonitor, but couldn't find anything related to the id in the MonitorSpec structure. As a last resort I could make a function where I hardcode the common name-id pairs ("pal.monotor" -> PAL_MONITOR_ID, "ntsc.monitor" -> NTSC_MONITOR_ID, etc.), but I would prefer to avoid this to keep the code flexible.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
PC monitor vs TV?	Borgy	support.Hardware	1	13 August 2019 19:07
C=64 using Pc monitor	Retrofan	Retrogaming General Discussion	44	25 March 2014 11:49
Which Monitor to use?	trydowave	support.Hardware	11	10 October 2013 16:39
C Monitor 2.02	redblade	request.Apps	3	10 January 2010 09:42
Which Monitor	ikorodu	support.Hardware	4	05 December 2005 20:03

18 February 2021, 07:03	#3
BSzili old chunk of coal Join Date: Nov 2011 Location: Hungary Posts: 1,289	I didn't know the node name of the MonitorSpec struct was the monitor name. That did the trick, thanks!

18 February 2021, 07:55	#4
Thomas Richter Registered User Join Date: Jan 2019 Location: Germany Posts: 3,215	My concern is that the monitor name is rarely useful, i.e. it is not shown in an ASL requester, and it is not necessarily the name of the icon in DEVS:Monitors. The later can be changed by the user to whatever he wants. It is better to enforce a particular mode ID. The monitor-dependent part of the mode ID are the 16 most significant bits - they stay constant throughout all modes of a particular monitor. Why graphics does this "dual housekeeping" of the display info data base, and the monitor, I do not know. There must be some legacy reason for that I'm not aware of.

18 February 2021, 12:07	#5
BSzili old chunk of coal Join Date: Nov 2011 Location: Hungary Posts: 1,289	I thought about using the monitor ID first, but how does the user find out the ID of a particular monitor? Since the file name can be changed, I'm probably better off hardcoding the names of the monitors that ship with AmigaOS: NTSC, PAL, Multiscan, Euro72, Euro36, Super72, DblNTSC, DblPAL. These names should stay consistent with the ones shown before the modes in the ScreenMode prefs, even if the monitor file was renamed.

18 February 2021, 14:25	#6
Thomas Richter Registered User Join Date: Jan 2019 Location: Germany Posts: 3,215	If you mean "monitor", you do mean the name of the icon in DEVS:Monitors? Unfortunately, you cannot in general predict which IDs the monitor icon will generate, and as the user can rename the icon as desired, there is no clear correspondance between icon name and installed modes. There are some system conventions for the system provided monitors (PAL,NTSC,EURO36,SUPER72,Multiscan), but as soon as you go to RTG graphics, it is an individual choice of the user, made at the time a graphics card is setup at installation time. I just wonder why that information is useful? What is useful is the mode name as this is what pops up in the workbench screen mode and the ASL requester, and what is useful are the mode properties you find in the display info database. Concerning display IDs, this is a 32 bit number, as stated, of which the 16MSBs are the monitor ID, and the LSBs are the mode information. One cannot, in general, conclude from the mode ID to the mode properties - that's what the display info data base is good for.

18 February 2021, 16:22	#7
BSzili old chunk of coal Join Date: Nov 2011 Location: Hungary Posts: 1,289	By monitor name I meant the mode name, not the actual monitor file name, sorry for the confusion. The problem I'm trying to solve is when a user has a bunch of monitor files in DEVS:Monitors instead of Storage, which causes the BestModeID function to pick some unexpedted mode. By restricting the display ID I could tell the user to set a tooltype in the program's icon to PAL for example, so they don't end up with a MULTISCAN modes even if they have the corresponding monitor file in DEVS:Monitors. I don't intend to restrict RTG modes this way, as they already take precedence when I open the the screen, and most users don't have more than one RTG board in their system.

18 February 2021, 18:51	#8
Thomas Richter Registered User Join Date: Jan 2019 Location: Germany Posts: 3,215	The typical solution to that problem is to use an ASL screen mode requester, probably both to select a mode, and to setup a default mode for the program configuration that ends up in the tool types. You can add a filter function to the ASL screen mode requester and by that restrict the modes seen by certain properties.

19 February 2021, 06:55	#9
BSzili old chunk of coal Join Date: Nov 2011 Location: Hungary Posts: 1,289	That would be the most flexible solution, but the games I intend to use this code in have on-the-fly resolution switching. To me opening an additional requester when the resolution is changed is a bit too much. This way can set a tooltype and still have a set of resolutions available in the game.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)