Author Topic: Monitor DPMS controls : SNAP config?  (Read 3319 times)

Dave Yeo

• Hero Member
• Thank You
• -Given: 11
• Posts: 2467
Re: Monitor DPMS controls : SNAP config?
« Reply #15 on: November 12, 2019, 05:04:53 am »
Yes, it's hard coded, which is why I asked you if C:\ was writeable. I don't really feel like updating it to use %TMP% right now but changing the hard coded path is simple so where do you want it to point?

Dariusz Piatkowski

• Hero Member
• Thank You
• -Given: 14
• Posts: 716
Re: Monitor DPMS controls : SNAP config?
« Reply #16 on: November 12, 2019, 01:57:10 pm »
Hey Dave!

Yes, it's hard coded, which is why I asked you if C:\ was writeable. I don't really feel like updating it to use %TMP% right now but changing the hard coded path is simple so where do you want it to point?

Damn...sorry man, I completely missed that. I know I read it, but for some reason it just translated to "is your bootable partition writeable"...yeah, I know...makes no sense, but because my bootable is G:\ I just got used to always converting any mention of C:\ into G:\. Sorry again.

Dave Yeo

• Hero Member
• Thank You
• -Given: 11
• Posts: 2467
Re: Monitor DPMS controls : SNAP config?
« Reply #17 on: November 12, 2019, 04:26:41 pm »
Here. Non-logging DLL removed
« Last Edit: November 12, 2019, 06:31:53 pm by Dave Yeo »

Dariusz Piatkowski

• Hero Member
• Thank You
• -Given: 14
• Posts: 716
Re: Monitor DPMS controls : SNAP config?
« Reply #18 on: November 12, 2019, 05:34:44 pm »
Here.

Hmm...replaced the module, re-booted, re-tested, did not find the LOG file anywhere, not in the root, nor anywhere else.

Dave Yeo

• Hero Member
• Thank You
• -Given: 11
• Posts: 2467
Re: Monitor DPMS controls : SNAP config?
« Reply #19 on: November 12, 2019, 06:26:25 pm »
Confirmed . Seems the makefile defines DEBUG_BUILD instead of DEBUG_LOGGING
Another try, this one is tested here. BTW, restarting the desktop after replacing should be good enough.

Dariusz Piatkowski

• Hero Member
• Thank You
• -Given: 14
• Posts: 716
Re: Monitor DPMS controls : SNAP config?
« Reply #20 on: November 13, 2019, 02:05:23 am »
Confirmed . Seems the makefile defines DEBUG_BUILD instead of DEBUG_LOGGING
Another try, this one is tested here. BTW, restarting the desktop after replacing should be good enough.

OK, here is a section of the LOG (right from the start onwards), I had it set to a pretty short interval, so following the initial test the monitors went through a couple more cycles before I replaced with the latest non-debug DLL.

Code: [Select]
[LibMain] : INITIALIZE DLL (start)[LibMain] : INITIALIZE DLL (done)[SSDPMS_Initialize] : SNAP is installed, trying to initialize it.[SSDPMS_Initialize] : SNAP DPMS support initialized successfully.[SSDPMS_Initialize] : Service initialized.[SSDPMS_GetCapabilities] : Calling GA_queryFunctions and DPMSdetect[SSDPMS_GetCapabilities] : Returning supported modes[SSDPMS_GetCapabilities] : Calling GA_queryFunctions and DPMSdetect[SSDPMS_GetCapabilities] : Returning supported modes[SSDPMS_GetCapabilities] : Calling GA_queryFunctions and DPMSdetect[SSDPMS_GetCapabilities] : Returning supported modes[SSDPMS_GetCapabilities] : Calling GA_queryFunctions and DPMSdetect[SSDPMS_GetCapabilities] : Returning supported modes[SSDPMS_SetState] : Shortcut exit.[SSDPMS_GetCapabilities] : Calling GA_queryFunctions and DPMSdetect[SSDPMS_GetCapabilities] : Returning supported modes[SSDPMS_GetCapabilities] : Calling GA_queryFunctions and DPMSdetect[SSDPMS_GetCapabilities] : Returning supported modes[SSDPMS_GetCapabilities] : Calling GA_queryFunctions and DPMSdetect[SSDPMS_GetCapabilities] : Returning supported modes[SSDPMS_SetState] : Query DPMS functions from SNAP[SSDPMS_SetState] : Calling DPMSsetState()[SSDPMS_SetState] : Saving current state, and returning[SSDPMS_GetCapabilities] : Calling GA_queryFunctions and DPMSdetect[SSDPMS_GetCapabilities] : Returning supported modes[SSDPMS_GetCapabilities] : Calling GA_queryFunctions and DPMSdetect[SSDPMS_GetCapabilities] : Returning supported modes[SSDPMS_SetState] : Query DPMS functions from SNAP[SSDPMS_SetState] : Calling DPMSsetState()[SSDPMS_SetState] : Saving current state, and returning...
There are no RCs or DPMS specific modes, so I'm not sure if this Dave gives you anything to narrow things down?

Now, there is something weird I did notice (given that the test timings were really short, like: 1 min of screen saver, than 1 min later do STAND BY and 1 min later do SUSPEND).

So here it is: when STAND BY kicks in the PRIMARY monitor goes blank and does not shut-OFF (which is correct since that is how the STAND BY mode operates), however the screen saver display (module output) is put on the SECONDARY monitor and it of course stops updating.

Following this, when the SUSPEND kicks in at the next stage the opposite actually happens, so the screen saver output is put back on the PRIMARY monitor but the SECONDARY actually goes into a SUSPEND mode.

Dave Yeo

• Hero Member
• Thank You
• -Given: 11
• Posts: 2467
Re: Monitor DPMS controls : SNAP config?
« Reply #21 on: November 13, 2019, 03:05:59 am »
Yes, it doesn't really say much besides no obvious errors. Without looking, I'd guess more printf's could be added to get the capabilities etc. Be interesting to know if it works for anyone with a dual head setup. And of course it could be a SNAP shortcoming or the screensaver. I doubt that Doodle gave much thought to dual monitor setups when writing the code. Unluckily the code is quite hard to follow.
One other test you could do is to try using direct VGA access. There's a couple of icons in the screensavers folder, one for enabling direct VGA access and one for using snap. Need to restart the desktop after switching. The direct VGA access probably won't work but it is easy enough to test.
Eventually it might be best to move to the bug tracker where we might get input from more knowledgeable people.

Andi B.

• Sr. Member
• Thank You
• -Given: 1
• Posts: 494
Re: Monitor DPMS controls : SNAP config?
« Reply #22 on: November 13, 2019, 02:32:11 pm »
My main system is a dual-monitor setup with ATI X300, SNAP of course. I've a lot of other systems running and tested with Panorama. But I've never seen a system which switches monitor(s) off with the eCS/ArcaOS included Screen Saver.

On my main system with (ATI X300, SNAP) I've extended the old blackout utility to switch of the monitors after a period of inactivity. SNAP couldn't do that with the X300. I extended my blackout version for some other systems too. F.i. for Paul who used an ATI X550 at that time IIRC. SNAP couldn't handle the special registers this cards needed for power off. Probably to new for the SNAP code. And the cards BIOS do not react on the standard VGA commands.

As this is all a minor nuisance I don't expect someone will spend time on it. Neither extending Panorama nor SNAP to handle the cards shortcomings. I can only suggest to use the monitors power button instead. If you've a X300 or X550 you can try my blackout version too (hobbes).

Btw.
Quote
that monitor has a weird EDID coding. It is meant to facilitate the LANDSCAPE to PORTRAIT mode switch, but unfortunately that has always caused the secondary monitor on my OS/2 box to insist on running in in 960x1200 mode, which as you can imagine is absolutely dreadful looking when in LANDSCAPE mode.
IMHO this has nothing to do with landscape/portrait mode. Your monitor is simply faulty. It reports WRONG data. Obviously there is no workaround for your monitor with wrong EDID in any of our display drivers. It seems SNAP relies on the data supplied from the monitor. If the data is wrong SNAP can't guess what the correct data should be and so can't drive it. No clue if SNAP can be forced to a fixed resolution when there is no EDID data (cutting the pins from the D-sub connector) or if it refuses to work completely. Remember at the time SNAP was invented automatic display capability detection was a necessary feature to prevent damaging some of the old tube monitors. So SNAP may rely on correct data or may refuse to work for safety reasons.

Dariusz Piatkowski

• Hero Member
• Thank You
• -Given: 14
• Posts: 716
Re: Monitor DPMS controls : SNAP config?
« Reply #23 on: November 15, 2019, 12:17:33 am »
Hi Andi.
My main system is a dual-monitor setup with ATI X300, SNAP of course. I've a lot of other systems running and tested with Panorama. But I've never seen a system which switches monitor(s) off with the eCS/ArcaOS included Screen Saver.

OK, so what I'm seeing maybe not be all that un-common after all.

...On my main system with (ATI X300, SNAP) I've extended the old blackout utility to switch of the monitors after a period of inactivity. SNAP couldn't do that with the X300...If you've a X300 or X550 you can try my blackout version too (hobbes).

Hmm...what's the name, b/c current search for blackout across the entire archive results in NO HITS. I'm guessing 'black103_ab.zip' is the file though? d/l'ing it right now...

Well, for what it's worth, as I wrote earlier, testing this out with SNAP's gactrl.exe and option #7 here (DPMS tests) actually provides a working STAND BY and SUSPEND functionality. it's just that Doodle SSaver does not appear to utilize it correctly???

...Btw.
IMHO this has nothing to do with landscape/portrait mode. Your monitor is simply faulty. It reports WRONG data. Obviously there is no workaround for your monitor with wrong EDID in any of our display drivers.

Ahhh, and here, with all due respect I have to differ. So here is the thing, I've actually re-written the EDID coding on the 245T display, progressively simplifying it right down to literally just the bare definition of basic VESA modes and the panel's native 1920x1200 resolution. The DVI and VGA ports have their own EDID records, so I adjusted the VGA side of course. Still the monitor would insist on coming up with this dreaded screen flip display. I thought I would completely take the EDID out of the equation. This meant I actually picked up an EXTRON EDID 101D & 101V module, which are pre-programmed with vanilla (VESA basically) modes, as well as allowing you to record a good EDID off of a monitor that works so that I could fake the video card & video drivers out.

Results => NOPE, nuthin'....still broken.

Better yet, given that my new DELL is recognized correctly, both on DVI & VGA I actually used the EXTRON module to copy the DELL EDID and drive the SNAP driver with that data...nah, no-go, the Samsung 245T would still come up with the wrong resolution.

Therefore, I attribute this completely to an internal monitor logic fault (in terms of how it actually responds to the video signal). This btw is across multiple 245T panels, I have some 4 of them here and am using them with my Winx based machines very successfully, albeit all connected through DVI.

Dariusz Piatkowski

• Hero Member
• Thank You
• -Given: 14
• Posts: 716
Re: Monitor DPMS controls : SNAP config?
« Reply #24 on: November 16, 2019, 03:51:40 pm »
Dave,

...One other test you could do is to try using direct VGA access. There's a couple of icons in the screensavers folder, one for enabling direct VGA access and one for using snap. Need to restart the desktop after switching. The direct VGA access probably won't work but it is easy enough to test...

Yeah, I was thinking of going down this route next, should the SNAP direction not get a result I'm looking for.

So, with the direct VGA access the only option is to actually issue a DPMS OFF call, or at least that's what the DSSAVER tab implies.

I did test this out and BOTH monitors go dark. Now, is that 'dark' an OFF state? Nope, the power LED remains blue and does not go to amber, which is what that gactrl.exe tests show when I test directly. However, there is something different here because if I am in fact running an animated screensaver module upon the VGA access being activated BOTH screens freeze at that instant. This is different from what the SNAP approach does (see my earlier comment on how this works). So this could be getting me a STAND BY mode since the screens respond very quickly once I re-active them.

Anyways, for now I'm just going to stick with the VGA access. I am trying to get the AN folks to release an updated SNAP SDK build, the one I have here is from 10/2006 "Version 3.1 - Release 23", and SDDHELP.SYS build V3.0 - Build 460. Unfortunately any sample SDK code I build refuses to load due to driver load issue. I am playing with their DPMS calls to see if I can write a very simple DPMS mode tester which specifically deals with a multi-head installation.

Dave Yeo

• Hero Member
• Thank You
• -Given: 11
• Posts: 2467
Re: Monitor DPMS controls : SNAP config?
« Reply #25 on: November 16, 2019, 06:11:57 pm »
I talked to the AN folks about an updated SDK a while back. They seemed to think there was no need for an update and weren't interested in updating it.

Dariusz Piatkowski

• Hero Member
• Thank You
• -Given: 14
• Posts: 716
Re: Monitor DPMS controls : SNAP config?
« Reply #26 on: November 16, 2019, 06:28:13 pm »
I talked to the AN folks about an updated SDK a while back. They seemed to think there was no need for an update and weren't interested in updating it.

LOL...well, the real world results sure indicate a different approach is necessary. I shared below information with Lewis earlier today, I'm hoping they will re-consider.

So in my specific case, I wanted to run the EDIDTEST sample code. Compile is OK, however running it produces the following response: "Unable to load SNAP device driver!".

In particular, it turns out this is being brought on by the following procedure call:

Code: [Select]
static GA_devCtx *LoadDriver(   N_int32 deviceIndex){   GA_devCtx *dc;#ifdef ISV_LICENSE   /* Register ISV license for SNAP DDC API */   DDC_registerLicense(OemLicense);#endif   if ((dc = DDC_loadDriver(deviceIndex)) == NULL)       PM_fatalError(DDC_errorMsg(DDC_status()));   init.dwSize = sizeof(init);   if (!DDC_queryFunctions(dc,GA_GET_INITFUNCS,&init))       PM_fatalError("Unable to get device driver functions!");   return dc;}
Either DDC_loadDriver fails, or DDC_queryFunctions. In either case it is the calling code in MAIN that actually handles the 0 (zero) return code from this procedure and puts out that error message.

I have SNAP build 505. The SNAP SDK I have here is build 460 and attempting to boot with it's SDDHELP.SYS causes a freeze at bootup time (right before the GUI stuff comes up). I expected to see that, but I thought I'd give it a go anyways.

Dave Yeo

• Hero Member
• Thank You
• -Given: 11
• Posts: 2467
Re: Monitor DPMS controls : SNAP config?
« Reply #27 on: November 16, 2019, 08:07:43 pm »
Interesting, I've been using the same SDK but didn't look into it much as I'm generally not using SNAP, so was just interested in getting the screensaver to build. It does bring up the possibility that the c:\scitech\lib\release\os232\ow10\pm.lib that I'm linking against is not quite right.

Dave Yeo

• Hero Member
• Thank You
• -Given: 11
• Posts: 2467
Re: Monitor DPMS controls : SNAP config?
« Reply #28 on: November 16, 2019, 08:09:45 pm »
Doodle also had this to say, didn't post sooner as I was hoping he'd show up or at least follow up.
Quote
Hi Dave,

I've just noticed that there is a conversation on www.os2world.com about DSSaver and a problem with multiple monitors.
I've seen that you've written that : "I doubt that Doodle gave much thought to dual monitor setups when writing the code."
This is completely true. I had a Matrox G400 at that time, and did not have multiple monitors to test the code with.

On the other hand, I got curious, and had a look at the old code (SSDPMS.c) to see if it should (in theory) or should not be able to deal with multiple monitors.

It seems that the code is completely dependent on SNAP and its DPMS support. It initializes the SNAP SDK API, and uses its DPMS functions to do the DPMS mode switching.

There are two clues in the code that may have information on multi-head / dual-monitor setups.
The first one is in the SSDPMS_SetState() function, when it calls into SNAP to set a given DPMS state:

#ifdef DEBUG_LOGGING
#endif

// If all goes well, this should set dpms state on all heads of the
// primary video device.
DPMSFuncs.DPMSsetState(stateToSet);

Please note the remark (highlighted in red). I don't remember all the details, but I believe that the SNAP API documentation said for the DPMSsetState() function that it sets the given DPMS state for all heads of the given graphics card.
On the other hand, looking at the SNAP SDK (into include/snap/ddc.h), the GA_DPMSFuncs structure has the definition of DPMSsetState() function, but it also has DPMSsetStateExt() defined, which might be used to specify the head number to set the DPMS state for. It might worth trying, if that helps or not.

Another clue is in the SNAP_Initialize() function, in which the SSDPMS.c code loads the SNAP driver. It says:

static int SNAP_Initialize()
{
// Load SNAP driver for primary display
// Note that we do not handle the case, when there are
// multiple video cards in the system.
// If that should also be handled, we should load a driver for
// all the cards, and call DPMSsetState() for all the drivers
// in SSDPMS_SetState().

{

As you can see, SSDPMS is NOT PREPARED for multiple graphics cards. However, it should be prepared for having ONE graphics card with multiple heads.

So, in my opinion, it's SNAP which fails to properly set the DPMS state for both of the monitors.
(I fail to remember, but didn't SNAP used to have a tool executable installed that could be used to set DPMS modes from command line? That could be used to test its capabilities...)

Sorry for not answering through os2world.com, but I could not register there (the registration currently seems to be broken in there). Still, I thought it might worth telling my opinion, so I wrote this email. Feel free to forward it / post it as you wish, wherever you want.

Thanks,
Doodle (Peter Kocsis)

Dariusz Piatkowski

• Hero Member
• Thank You
• -Given: 14
• Posts: 716
Re: Monitor DPMS controls : SNAP config?
« Reply #29 on: November 17, 2019, 02:32:16 am »
Dave,

Interesting, I've been using the same SDK but didn't look into it much as I'm generally not using SNAP, so was just interested in getting the screensaver to build. It does bring up the possibility that the c:\scitech\lib\release\os232\ow10\pm.lib that I'm linking against is not quite right.

Hmm...so how is it that your version of DSS successfully managed to load SNAP and yet mine does not?

OK, I have the VA365 versions present here, because I have been primarily working with the IBM compiler in all my previous attempts. Therefore, i find the following in the \snap\lib\release\os232\va36 location:

Code: [Select]
Directory of G:\code\source\snap\lib\release\os232\va36 8-25-18   5:43p     <DIR>         124  . 8-25-18   5:43p     <DIR>         124  .. 3-17-09  10:02p     12354           0  gconsole.lib 3-17-09  10:02p     12277           0  n_ga.lib 3-17-09  10:02p    104231           0  pm.lib10-26-06   4:19p        60         124  readme.txt        6 file(s)     128922 bytes used
...as such, my pm.lib is what should be getting linked when any locally compiled code is attempting to call SNAP APIs, correct?