Re: SNAP refresh rate
- From: "David T. Johnson" <djohnson@xxxxxxxxxxxx>
- Date: Wed, 13 Jul 2011 15:07:30 -0700
tholen@xxxxxxxxxxxx wrote:
"David T. Johnson" <djohnson@xxxxxxxxxxxx> writes:
SNAP stores the refresh rate in x:\os2\drivers\snap\config\graphics\crtc00.dat
for the base monitor. It's a binary file so you can only edit it with binary editor.
Editing it with a binary editor isn't a problem. Finding the correct
byte is. There are at least a half dozen occurrences of the byte "41"
in the file, which is the hex value for 65 Hz, which assumes, of
course, that the refresh rate is stored in units of Hz.
As soon as I get to my office, I'm going to need to check whether
the "last written" dates on the crtc* files correspond to about
the same time as the date on the swapper.dat file, which corresponds
to the last reboot. That would at least provide a hint as to
whether they get written at graceful shutdown or not. I' trying to
think of a reason why they would NOT get written immediately upon
the user making the change in the System object.
I'm using SNAP 3.1.8 which identifies itself as build 505 and is the last one release by Scitech. The .dat file gets written immediately after a change to the refresh rate and does not get written again until another change is made to the configuration data stored in the file. If the next change is not made for 30 days, the file does not get written to for 30 days. You could find the correct bit by just making an arbitrary change, saving a copy of the file, and then doing at a file compare with the unchanged file to see where the change was written.
Sounds good in theory, but if making an arbitrary change to the refresh
rate actually changed the relevant byte, then I wouldn't be having the
problem in the first place!
Here are my directory listings:
11-07-07 15.51 2.097.152 0 ---- SWAPPER.DAT
The above represents when the system was last rebooted.
11-07-10 17.45 8.424 0 a--- crtc-10.dat
11-06-03 17.49 8.424 0 a--- crtc00.dat
11-07-07 15.52 8.378 0 a--- crtc10.dat 11-07-07 15.52 17.836 0 a--- graphics.log 11-07-07 16.00 232 0 a--- mon00.dat 11-07-07 15.52 232 0 a--- mon10.dat 11-07-07 15.52 623.983 0 a--- monitor.dbx 03-12-05 13.31 692 0 ---- options.dat 11-02-20 23.59 51 0 a--- snapos2.ini 11-05-03 18.25 258 0 a--- snapzoom.ini
As you can see, mon10.dat, monitor.dbx, crtc10.dat, and graphics.log were
all written about a minute after the reboot, while mon00.dat was written
about 8 minutes later, which probably represents the delay in hooking up
an old monitor to the system so that I could see my desktop (becaused the
new monitors don't like the refresh rate). Meanwhile, SNAP didn't touch
the crtc00.dat file for some peculiar reason. And even though crtc-10.dat
was written days later (following some other refresh rate test), it was
apparently based on the crtc00.dat file, given that the file sizes are
the same (but the contents are not the same).
So, something seems to be inhibiting the writing of the crtc00.dat file.
Or is there some reason to leave it untouched while the others are being
written following a reboot?
Regarding your question, on my system, the crtc00.dat file only gets written to if one of the associated parameters stored in it (such as refresh rate) gets changed. Otherwise, SNAP does not write to it, although it presumably reads from it at startup.
--
Posted with OS/2 Warp 4.52
and Sea Monkey 1.5a
.
- References:
- SNAP refresh rate
- From: tholen
- Re: SNAP refresh rate
- From: David T. Johnson
- Re: SNAP refresh rate
- From: tholen
- Re: SNAP refresh rate
- From: David T. Johnson
- Re: SNAP refresh rate
- From: tholen
- SNAP refresh rate
- Prev by Date: Re: SNAP refresh rate
- Next by Date: New USB host controller drivers: usbxhcd9.zip
- Previous by thread: Re: SNAP refresh rate
- Next by thread: eComStation: Question - answer
- Index(es):
Relevant Pages
|
