video sync timing

video sync timing

[Richard Cooper]

Any ideas how I might sync to bit 3 of port 0x3DA, the video card's  
vertical sync signal?

Just watching the bit in a loop doesn't seem like a good idea, since the  
CPU could be off doing something else, but as far as I know any timer  
function I might use will only be accurate to 1/100 of a second, which  
wouldn't be much better than watching the bit in a loop.

Since things like DOOM run in Linux, I think there must be some way to do  
it.  I've discovered that simutaneously changing the screen data and the  
color palette without synchronization creates a flicker of a mess on the  
screen, and DOOM doesn't do that in Linux, so I guess it must be  
synchronizing somehow.

Re: video sync timing + softer update

[Richard Cooper]

> Any ideas how I might sync to bit 3 of port 0x3DA, the video card's  
> vertical sync signal?

Well, I don't know if anyone cares, but since I asked the question here, I  
figure it's appropriate to let everyone know what I came up with.

As best I can tell, it's just not possible under Linux.  Everything that  
does vertical refresh syncing in Linux does it with a CPU-time-eating busy  
loop.  It seems it isn't possible to give up the CPU for a period of time  
shorter than 10-20ms.  Since vertical retraces occur every 17ms, and 17 <  
20, if you want to have the CPU when the next retrace occurs, you can't do  
any kind of sleeping.  This is the case even under "realtime scheduling,"  
which seems to be a misnomer for what would be better called "priority  
scheduling."

Anyway, I also updated Softer so that it has that fun command that lets  
you just give it video data and it displays it.  If you want it, you can  
download it from the link at the bottom of this message board post:

http://xerse.nfshost.com/funrestraints/post/000000000016.html

It's basically version 125, but I made it a "preview" because I'm too  
angry now to bother with putting it through the amount of testing I  
usually do.  Seems to work just fine, though.

The last couple of paragraphs in that message are about Softer, the rest  
is just ranting.  You don't have to read the rants, but if you like  
Softer, consider reading them as a way of supporting it's development.  Or  
some nonsense like that.

Re: video sync timing + softer update

[Frank Kotler]

Richard Cooper wrote:

>> Any ideas how I might sync to bit 3 of port 0x3DA, the video card's  
>> vertical sync signal?

I took the liberty or reposting your question to news:alt.lang.asm - 
more of a warzone than an asm forum, these days, but we were discussing 
polling loops, and I thought somebody might have some ideas.

One response was "I don't bother doing that anymore, vga doesn't need 
it." Would be nice if it were true, but your experience seems to differ.

Another poster (f0dder) posted a link to Kris Heidenstrom's PC timing 
FAQ, and its info on "emulating a Vertical Retrace Interrupt". All dos 
stuff, it wouldn't work on Linux as written, of course. But I thought 
the principles might be useful. However, that's pretty much what you've 
tried, without success. I didn't realize that the resolution on the 
timers was so bad. Oh, well...

I still think that this approach has as much promise as anything. If the 
arithmetic doesn't work out... jeez, I'm really reluctant to say 
anything's "impossible"...

...
> http://xerse.nfshost.com/funrestraints/post/000000000016.html
> 
> It's basically version 125, but I made it a "preview" because I'm too  
> angry now to bother with putting it through the amount of testing I  
> usually do.  Seems to work just fine, though.

Great. I haven't looked at 1.26pre yet - barely getting into 1.24 - but 
it looks like a useful little tool, even if it *won't* synch. Making it 
a command line option as you've done may be the best you can do.

> The last couple of paragraphs in that message are about Softer, the 
> rest  is just ranting.  You don't have to read the rants, but if you 
> like  Softer, consider reading them as a way of supporting it's 
> development.  Or  some nonsense like that.

Okay, I've done my part :) Sorry to hear you're meeting with such 
frustration. Look on the bright side: Softer's a *hell* of a lot better 
than no graphics at all (which is what I'm used to). Thanks for sharing 
it with us!

Best,
Frank

Re: video sync timing + softer update

[Richard Cooper]

> I took the liberty or reposting your question to news:alt.lang.asm -  
> more of a warzone than an asm forum, these days, but we were discussing  
> polling loops, and I thought somebody might have some ideas.

I subscribed to that group so I can read the responses.  Interesting to  
learn that even the kernel's FB driver doesn't implement syncing.  Even  
so, I couldn't use it if it did, since Softer is non-framebuffer.  When  
not in framebuffer mode, opening /dev/fb0 returns ENODEV or something like  
that, so using it's IOCTLs isn't possible.

> One response was "I don't bother doing that anymore, vga doesn't need  
> it." Would be nice if it were true, but your experience seems to differ.

Many things won't require it, but as this script shows, it's needed  
sometimes.  Just compare how it looks when running with -s as opposed to  
not running with -s.  There's quite a difference.

http://xerse.nfshost.com/secret/softer/sync_test.pl
(this script needs the general_functions.pl included with softer)

It's kind of hard to see, since softer doesn't do syncing when it's not  
the active console, and so just running 'top' you won't see it, but if you  
run the processor_utilization.pl script included with softer on another  
console, you can see that when softer runs with -s, you're basically using  
100% of the cpu (or close to it, those select calls in the script have to  
be sleeping a little).  Without -s it looks like it takes about 4%.

However, that's not what my problem is.  I haven't actually seen tearing  
outside of that test script.  Here's a script (and two files it needs)  
that demonstrates my problem:

http://xerse.nfshost.com/secret/softer/picture_sync_test.pl
http://xerse.nfshost.com/secret/softer/1.orange
http://xerse.nfshost.com/secret/softer/2.orange

It just flips between two images at 30 fps, to pretend like it's showing  
video.  (including enough images for a real video would have made one big  
tar file)  When run with -s it works fine, except that it takes about 50%  
of my CPU time.  When run without -s, it uses about 4%, however, it's got  
these bars of static in it that are about 1/4 of the screen tall, making  
it look kind of like a VHS tape on fast-forward.

It turns out that DOOM doesn't have this problem because even though it  
changes palettes, the pixel data on the screen is valid for both the old  
and the new palette.  These two images were each converted to their own  
256-color palette, and so each image when displayed with the other's  
palette just looks like garbage.

Since the palette changes take place immediately, (when softer writes to  
the registers), regardless of where the CRT beam is, you get that static  
stuff displayed between the time where you change the palette and the time  
when you change the pixel data, so you have to wait for the beginning of a  
retrace, change the palette, and then update the frame.

> Another poster (f0dder) posted a link to Kris Heidenstrom's PC timing  
> FAQ, and its info on "emulating a Vertical Retrace Interrupt".

I had a look at it, it basically describes what I was talking about on my  
message board, using the PIT to synchronize with the vertical retrace  
(although they call it the CTC which I believe is the Z80 equivelent,  
which isn't used in the PC).  Linux could do that on our behalf (using the  
PIT like I described to provide multiple timing signals), but it insist on  
keeping the PIT programmed to a single value, 100Hz.

> Sorry to hear you're meeting with such frustration.

Happens every time I work on Softer.  There's just so many stupid things  
about the kernel, like how with it's aquire/release signals, it'll send  
you one even if you're still in the signal handler for the last one it  
sent you.  There's no reason it should do that, and it's insane to expect  
any code to be able to deal with that.

On the not-so-dark side, at least the solution I came up with (in  
switcher.asm) seems to work.  I wrote a test script that told the kernel  
to switch consoles as fast as possible, and Softer didn't have a problem  
with it.

> Look on the bright side: Softer's a *hell* of a lot better than no  
> graphics at all (which is what I'm used to).

I just wish it did text in graphics modes.  I also wish it could draw  
circles.  (Yes, I could make it do both, but when I feel like working on  
it there always seems to be something else that should be done first.)   
And sprite support would be awesome, but I'm afraid to touch anything that  
involves memory management.  It'd make it really easy to make games,  
though.

There's also no way to tell from the video mode packet wether or not a  
given mode supports graphics.  I didn't realize that until last night.   
I've never actually used the video mode packet because I know what the  
modes are.

Email me if you run into any problems with it.  I rarely get emails about  
it, which I guess I should take to mean that it works just fine, but I  
can't help but worry that people just aren't reporting problems.  Also,  
I'd love to have an FAQ for it, but with no questions, that's not going  
anywhere.

Re: video sync timing + softer update

[Stephen Ray]

Richard Cooper wrote:
>> Any ideas how I might sync to bit 3 of port 0x3DA, the video card's  
>> vertical sync signal?
> 
> 
> Well, I don't know if anyone cares, but since I asked the question here, 
> I  figure it's appropriate to let everyone know what I came up with.
> 
> As best I can tell, it's just not possible under Linux.  Everything 
> that  does vertical refresh syncing in Linux does it with a 
> CPU-time-eating busy  loop.  It seems it isn't possible to give up the 
> CPU for a period of time  shorter than 10-20ms.  Since vertical retraces 
> occur every 17ms, and 17 <  20, if you want to have the CPU when the 
> next retrace occurs, you can't do  any kind of sleeping.  This is the 
> case even under "realtime scheduling,"  which seems to be a misnomer for 
> what would be better called "priority  scheduling."
> 

What kernel series are you using?  Did you compile it yourself?  What is 
HZ set at?  100? 250? 1000?  If it's a 2.6 kernel, did you try enabling 
preemption?  With HZ at 100, it is impossible for the kernel to give you 
  better than 10 ms resolution.  With HZ at 1000, it can achieve 1 ms 
resolution (in theory).  What else is running on your machine?  These 
questions could help answer whether it's possible.

Stephen

Re: video sync timing + softer update

[Richard Cooper]

> What kernel series are you using?

Linux version 2.4.26

> Did you compile it yourself?

Possibly, I've compiled kernels before, but I think this one did  
everything I needed out of the box, so I didn't have to recompile it.

> What is HZ set at?

Aparently 100.  I wasn't aware you could change it.  I wanted to once  
since Linux's multitasking is so sludgy sometimes, but I couldn't figure  
out how to do it.

(Turns out the slugyness is because it'll give processes more than one  
timeslice in a row, it'll give them like 20 before switching tasks, so  
you're only switching tasks 5 times a second.  Maybe I should just run  
everything under SCHED_RR...)

> If it's a 2.6 kernel, did you try enabling preemption?

I'm afraid to try 2.6.  I've heard nothing good about it.  (in fact, this  
is the first time I've seen 2.6 mentioned without being in relation to  
something not working because of it)

It's not a problem with kernel threads blocking the scheduling, the kernel  
is just sitting idle when I run my test program.  As best I can tell, the  
kernel simply doesn't want to schedule things outside of it's 10ms time  
slices.  So when I try to sleep for any amount of time, the wakeup time is  
always set for the beginning of one of those 10ms slices.  (which is the  
documented behavior, I'm just surprised to see that "realtime scheduling"  
doesn't fix it)  It's not that the kernel is incapable of splitting slices  
between processes, it does it all the time.  It just won't schedule  
anything that way.

> What else is running on your machine?

     1 ?        00:00:04 init
     2 ?        00:00:03 keventd
     3 ?        00:00:00 ksoftirqd_CPU0
     4 ?        00:00:06 kswapd
     5 ?        00:00:00 bdflush
     6 ?        00:00:00 kupdated
    10 ?        00:00:00 mdrecoveryd
    11 ?        00:00:00 kreiserfsd
    60 ?        00:00:00 syslogd
    63 ?        00:00:00 klogd
   172 ?        00:00:00 khubd
   872 ?        00:00:00 usb-storage-0
   873 ?        00:00:00 scsi_eh_1
   972 ?        00:00:00 inetd
   987 ?        00:00:00 cupsd
  1009 ?        00:00:00 crond
  1012 ?        00:00:00 httpd
  1013 tty1     00:00:00 bash
  1014 tty2     00:00:00 bash
  1015 tty3     00:00:00 bash
  1016 tty4     00:00:00 agetty
  1017 tty5     00:00:00 agetty
  1018 tty6     00:00:00 agetty
  1019 tty7     00:00:00 bash
  1020 tty8     00:00:00 bash
  1021 tty11    00:00:00 agetty
  1022 ?        00:00:00 adserver
  1023 ?        00:00:00 faucet
  1024 ?        00:00:00 httpd
  1025 ?        00:00:00 httpd
  1026 ?        00:00:00 httpd
  1027 ?        00:00:00 httpd
  1028 ?        00:00:00 httpd
  2191 tty8     00:00:00 startx
  2203 tty8     00:00:00 xinit
  2204 ?        00:01:09 X
  2208 tty8     00:00:00 xinitrc
  2209 tty8     00:00:00 startkde
  2222 ?        00:00:00 kdeinit
  2225 ?        00:00:00 kdeinit
  2227 ?        00:00:00 kdeinit
  2230 ?        00:00:00 kdeinit
  2241 ?        00:00:00 kdeinit
  2242 tty8     00:00:00 kwrapper
  2244 ?        00:00:00 kdeinit
  2245 ?        00:00:01 kdeinit
  2247 ?        00:00:00 kdeinit
  2249 ?        00:00:00 kdeinit
  2251 ?        00:00:00 kdeinit
  2254 ?        00:00:03 kdeinit
  2258 ?        00:00:00 kdeinit
  2260 ?        00:00:00 korgac
  2319 ?        00:00:00 adserver.pl <defunct>
  2768 ?        00:00:00 adserver.pl <defunct>
  2786 ?        00:00:00 adserver.pl <defunct>
  3407 ?        00:00:00 adserver.pl <defunct>
  6815 ?        00:00:00 httpd
  8789 ?        00:00:00 adserver.pl <defunct>
  9494 ?        00:00:00 adserver.pl <defunct>
10241 tty7     00:00:00 startx
10252 tty7     00:00:00 xinit
10253 ?        00:09:30 X
10257 tty7     00:00:00 xinitrc
10258 tty7     00:00:00 startkde
10277 ?        00:00:00 kdeinit
10280 ?        00:00:00 kdeinit
10282 ?        00:00:00 kdeinit
10285 ?        00:00:00 kdeinit
10294 ?        00:00:00 artsd
10296 ?        00:00:00 kdeinit
10297 tty7     00:00:00 kwrapper
10299 ?        00:00:00 kdeinit
10300 ?        00:00:04 kdeinit
10302 ?        00:00:00 kdeinit
10305 ?        00:00:02 kdeinit
10306 ?        00:00:03 kdeinit
10309 ?        00:00:06 kdeinit
10311 ?        00:00:00 kdeinit
10312 ?        00:00:00 kdeinit
10313 ?        00:00:02 kdeinit
10318 ?        00:03:35 opera
10344 ?        00:00:00 opera
10376 ?        00:00:00 adserver.pl <defunct>
11897 ?        00:00:00 adserver.pl <defunct>
11986 ?        00:00:00 adserver.pl <defunct>
11989 ?        00:00:00 adserver.pl <defunct>
11990 ?        00:00:00 adserver.pl <defunct>
11991 ?        00:00:00 adserver.pl <defunct>
12417 ?        00:00:10 gedit
12419 ?        00:00:00 gconfd-2
12421 ?        00:00:00 bonobo-activati
12480 ?        00:00:12 kdeinit
12498 ?        00:00:00 kdeinit
12879 ?        00:00:00 kdeinit
12891 ?        00:00:00 httpd
12892 ?        00:00:00 httpd
12893 ?        00:00:00 httpd
12894 ?        00:00:00 httpd
13338 tty2     00:00:00 softer
13340 tty2     00:00:00 processor_utili
13493 ?        00:00:00 kdeinit
13494 pts/1    00:00:00 bash
13565 pts/1    00:00:00 ps

top says 0.3% user, 0.7% system, 99% idle

No, I didn't mess it up, there really are two copies of X running.

> These questions could help answer whether it's possible.

I don't want to require that people modify their kernel just to run  
Softer.  The way it is now, you download it, and it just works.  (Or it  
tells you your in framebuffer mode.)  I download Linux programs now and  
then, and 75% of the time they don't work.  I don't want Softer to be like  
that.

The reason it works so well now is because it doesn't depend on anything.   
You don't need libraries, you don't even have to compile it, the binary  
will work just fine.  If people have to modify their kernel, then it's  
working becomes dependant on wether or not the kernel modifications are  
sucessful.  I can make sure that Softer will work, but I can't do anything  
to make sure that kernel modifications will work.

Re: video sync timing + softer update

[Stephen Ray]

Richard Cooper wrote:
>> What kernel series are you using?
> 
> 
> Linux version 2.4.26
> 
>> Did you compile it yourself?
> 
> 
> Possibly, I've compiled kernels before, but I think this one did  
> everything I needed out of the box, so I didn't have to recompile it.
> 
>> What is HZ set at?
> 
> 
> Aparently 100.  I wasn't aware you could change it.  I wanted to once  
> since Linux's multitasking is so sludgy sometimes, but I couldn't 
> figure  out how to do it.
> 
> (Turns out the slugyness is because it'll give processes more than one  
> timeslice in a row, it'll give them like 20 before switching tasks, so  
> you're only switching tasks 5 times a second.  Maybe I should just run  
> everything under SCHED_RR...)
> 
>> If it's a 2.6 kernel, did you try enabling preemption?
> 
> 
> I'm afraid to try 2.6.  I've heard nothing good about it.  (in fact, 
> this  is the first time I've seen 2.6 mentioned without being in 
> relation to  something not working because of it)
> 
I know there were teething problems.  I suspect a lot of it was due to 
widespread use of certain assumptions about kernel behaviour.  When the 
behaviour changed, it broke libraries and applications.  But, it's been 
almost 2 years now, and it's not like they're going to be returning to 
the 2.4 way of doing things.  2.6 also introduces a lot of improvements 
in the way the kernel works.

> It's not a problem with kernel threads blocking the scheduling, the 
> kernel  is just sitting idle when I run my test program.  As best I can 
> tell, the  kernel simply doesn't want to schedule things outside of it's 
> 10ms time  slices.  So when I try to sleep for any amount of time, the 
> wakeup time is  always set for the beginning of one of those 10ms 
> slices.  (which is the  documented behavior, I'm just surprised to see 
> that "realtime scheduling"  doesn't fix it)  It's not that the kernel is 
> incapable of splitting slices  between processes, it does it all the 
> time.  It just won't schedule  anything that way.

Realtime scheduling doesn't change the fact that the clock only ticks HZ 
times a second.  If you've got a 100 Hz tick rate, you'll only do 
scheduling on 10 ms intervals.  It will split slices between processes, 
but (if I recall correctly) only when the kernel is interrupted, and the 
scheduler finds that a higher-priority process is ready to run, or 
currently running process yields the process (waiting for I/O, or 
explicitly yielding).  You certainly can't rely on this, and the kernel 
has no universally-available way of telling how far into a tick it is.

> 
> I don't want to require that people modify their kernel just to run  
> Softer.  The way it is now, you download it, and it just works.  (Or it  
> tells you your in framebuffer mode.)  I download Linux programs now and  
> then, and 75% of the time they don't work.  I don't want Softer to be 
> like  that.
> 
> The reason it works so well now is because it doesn't depend on 
> anything.   You don't need libraries, you don't even have to compile it, 
> the binary  will work just fine.  If people have to modify their kernel, 
> then it's  working becomes dependant on wether or not the kernel 
> modifications are  sucessful.  I can make sure that Softer will work, 
> but I can't do anything  to make sure that kernel modifications will work.

Well, the 2.6 kernel has been the mainline kernel since December 2003. I 
don't know of any major distros that doesn't distribute a 2.6 kernel, 
and most no longer ship 2.4.  In addition, several distros, notably 
Redhat, shipped 2.4 kernels with the tick rate set at 1000 Hz rather 
than 100 in later versions.  Unfortunately, Hz (with almost all kernels) 
has to be set at kernel compile time (although there is a lot of work 
being done trying to set the PIT tick rate dynamically).

I understand why you'd want something that runs with stock kernels. 
However, I would suspect that most people are running with kernels using 
1000 Hz.  Why not embrace that fact, rather than beating your head 
against the 100 Hz tick rate?

Re: video sync timing + softer update

[Richard Cooper]

> I understand why you'd want something that runs with stock kernels.  
> However, I would suspect that most people are running with kernels using  
> 1000 Hz.  Why not embrace that fact, rather than beating your head  
> against the 100 Hz tick rate?

I wasn't aware that 2.6 used HZ=1000 by default.  I'll have to look into  
that then, because it's certainly possible to make Softer do what it's  
doing now with HZ=100, and actually do some sleeping with HZ=1000.  I  
thought all kernels used HZ=100, and I wasn't about to tell people "you  
should recompile your kernel to make Softer work better."

Anyway, the Softer download page has been begging for someone to send me a  
register dump from a 2.6 kernel, but it doesn't look like anyone is going  
to do it.  A friend of a friend ran Softer on 2.6, and all I ever heard  
back about it was that Softer says "unknown error," which doesn't tell me  
much.  (Just that the EAX error code wasn't one that's regdump.asm, and  
it's got them all up to #124, so it must be a new 2.6 error code.)  I  
tried to get the friend to get the other friend to get me the full  
debugging output, but somehow all I ever got back from that was "EAX has  
some numbers and a lot of zeros."

However, this all might be a bit pointless.  It occured to me that slower  
machines might not be able to write the whole palette before vertical  
retrace ends.  It looks like my other computer doesn't completely get the  
palette changed until half-way through the first scanline of the picture.   
Maybe changing the palette every frame is trying to do too much.

I bumped into another problem.  When testing that on the other computer,  
Softer started saying "stdin and stdout must refer to a console TTY."  So  
I made it so that when it gets that error, it puts the r_dev field of stat  
into eax and ebx and calls the register dump code.  For some reason the  
kernel was giving it (3,224) for stdin and (3,217) for stdout.  For  
console TTYs, the last number is between 1 and 63, and softer only accepts  
1 through 12 because Slackware by default has 666 permissions on the  
others, which lets a non-in-front-of-the-monitor user start Softer, which  
is a bad thing.  224 is /dev/ttyd0 and 217 is /dev/ttyc9, I don't even  
know what those are supposed to be.  I tried it on another console, and  
then it returned (0,0) (regular file) for stdin and something else for  
stdout.  I had to reboot Linux to get it to quit doing that.  I tried  
doing again what I did before to see if it would start doing it again, but  
it wouldn't.  The never-ending fun of Linux.

video sync: result of 2.6 kernel experimenting

[Richard Cooper]

Vsync on 2.6 seems to work really well.

I downloaded 2.6.7 from slackware.com.  For some reason, after printing "BIOS data check sucessful" (or something like that) it doesn't do anything at all for 30 seconds.  I was about to give up and hit reset, but then it started going.

I ran Softer, it didn't give me any error messages, so I don't know what that guy's problem could have been.  It worked just fine for me.  May only happen on a specific 2.6 version, or maybe he deleted "/dev/mem" or something.  I dunno.

Anyway, I typed 'set' to see what HZ was set to, it was set to 100, but I figured the environment variable might be wrong.  Playing around in /proc/ I found that there was an interrupt going off 1000 times a second, so I figured it was probably HZ=1000.

I ran my test program and it basically worked, it just missed a retrace now and then, but got like 80% of them.  It stuck the itimer delay so that it bounced between 15998 and 15999.  Curious as to why it was there instead of 16000 and 16001 where the next 1ms boundary is, I did some investigating.  It seems 2.6 kernels, although they still schedule to the next clock tick, take into consideration how far into the current tick you are when they round the value up.  So when it set the itimer, it was 0.002ms past the last tick, so that was added to the itimer value, and the result rounded up to the next 1ms, making it bounce between 16ms and 17ms.  The 2.4 kernel didn't take this into consideration, it would have rounded the itimer value up to the next millisecond (if it were HZ=1000), then wait until the end of the current 1ms interval to start measuring, making 16000 delay for 16998, and 
 16001 delay for 17998.  Basically, it always assumed it was near the end of the current t!
 ick  
when rounding.

Anyway, attempting to sync the timer to the vertical retrace seemed a bit silly with such a low resolution timer.  So I just made it keep the timer at 15000us, which would delay between 15000 and 15999, and just poll from that point on.  I also made the script determine how many microseconds it took after the timer went off for the actual retrace to occur, and if it was more than 3333 (20% of a vertical retrace interval), it counted it as a miss.  This way if the kernel gave it the signal just a little too late, it would count something like 16000us, and know that it missed a frame.  If the kernel was more than 13000us late, then that wouldn't be caught, but since that's 13 timeslices, I figure it wouldn't happen.

So, I tested the thing, running it for 3600 retrace cycles (60 seconds).  On an idle system, it missed 2 retraces out of 3600, 0.06%.  Then I ran it with "cp -R /usr trash & cat /dev/urandom > /dev/null" running on another console.  Even with all of that going on, it still missed only two retraces.

I couldn't figure out a way to get rid of those two misses per minute, but I didn't expect the kernel to do it perfectly anyway, I just expected it to try.

While it's running, it uses 4.7% of the CPU.  Since the CPU usage depends on how close the itimer signal is to the actual retrace, the CPU usage should be the same regardless of CPU speed.

If anyone wants to play with the test program, the source is here:

http://xerse.nfshost.com/secret/softer/vsync.tgz

It's set up now for 80x30 text mode's refresh rate of 60 Hz, which will make it miss the retrace every time in 80x25.  To use it with 80x25 which runs at 70 Hz, change the itimer delay on line 134 from 15000 to 13000, the 3333 on line 85 to 2857, and the 60 on line 91 to 70.

Also, on 2.4 kernels with HZ=1000, you'll have to subtract 1000 from the itimer delay to correct for rounding differences in the kernel.  And it won't work at all if HZ=100.

Re: video sync: result of 2.6 kernel experimenting

[Stephen Ray]

Richard Cooper wrote:

>
>
> Anyway, I typed 'set' to see what HZ was set to, it was set to 100, 
> but I figured the environment variable might be wrong.  Playing around 
> in /proc/ I found that there was an interrupt going off 1000 times a 
> second, so I figured it was probably HZ=1000.
>
My understanding is that HZ is set to 100 in userspace, to avoid 
breaking some userspace programs.  It's not the same HZ value that is 
used in the kernel source in 2.6.