os2world website script problem?

[Pete]

Hi Dave

I reset layout.frame_rate to 0 and had a look at the links in your post.
No reaction from Seamonkey here ie no cpu peaking, no animated gifs either...


Regards

Pete

[Dave Yeo]

Hi Pete, my system was busy at the time so just assumed it was the same bug. I was looking for the one that fixed our problem, which IIRC, I only saw referenced as being fixed. The problem was partially Gimp producing broken GIF's that triggered the animation even though not animated, or might have been one frame.

[Dave Yeo]

Hi Lars, I'll see if Mozilla still builds here. Have to restore from a backup and my first try was the wrong one.
Stupid Intel USB3 is slow, 3 hours to restore the tree, currently going at 2.4 MB/S, maxes out around 6. The addon USB3 card I had max out at about a 100 MB/S. Speed is just about as slow under Linux too.

[Dave Yeo]

I had written a device driver to sync on the VGA sync signal:
https://github.com/lerdmann/vsync

And here, it has already been discussed:
https://github.com/bitwiseworks/mozilla-os2/issues/220

It reads the VSYNC sync bit from some VGA register and blocks on it to toggle (waits for the beam to return from bottom right to top left, so to say). It is somewhat system friendly in that it will yield the CPU if the yielding flag indicates that there is some other thread waiting to be continued.

1) I have no clue if every graphics card still contains the original VGA register set
2) I have no clue how and where to integrate this into Firefox

If someone could either point me to the place in Firefox where to add this or if someone could build Firefox (of which I also have no clue) then maybe it would be worth giving it a try.

Lars

Hi Lars, finally got Firefox building again, moved computers and had to restore environment and fix the tree.
Pushed the latest to https://github.com/dryeo/mozilla-aos branch esr45.9.
The vsync stuff is scattered around thebes, such as https://github.com/dryeo/mozilla-aos/blob/esr45.9/gfx/thebes/VsyncSource.cpp. The Windows implementation might be a good start, https://github.com/dryeo/mozilla-aos/blob/esr45.9/gfx/thebes/gfxWindowsPlatform.cpp#L2733

Whether using the VGA registers will work is a good question. I doubt it on a UEFI install, I haven't had any luck accessing the registers there, and it is loaded at a weird address. Might be possible to get info from Arca Noae how to access it in their VGA BIOS.
Might work on a legacy install.  The screensaver has a fall back of directly manipulating the VGA registers to put the monitor to sleep (set VSYNC/HSYNC to zero), which doesn't seem to work on recent hardware.

[Pete]

Hi Dave

Retested with the new profiles - standard Seamonkey, no addons.

Both those show the gif bug ie https://bug1793279.bmoattachments.org/attachment.cgi?id=9296847 causes cpu peaking.


Regards

Pete

[Lars]

I had written a device driver to sync on the VGA sync signal:
https://github.com/lerdmann/vsync

And here, it has already been discussed:
https://github.com/bitwiseworks/mozilla-os2/issues/220

It reads the VSYNC sync bit from some VGA register and blocks on it to toggle (waits for the beam to return from bottom right to top left, so to say). It is somewhat system friendly in that it will yield the CPU if the yielding flag indicates that there is some other thread waiting to be continued.

1) I have no clue if every graphics card still contains the original VGA register set
2) I have no clue how and where to integrate this into Firefox

If someone could either point me to the place in Firefox where to add this or if someone could build Firefox (of which I also have no clue) then maybe it would be worth giving it a try.

Lars

Hi Lars, finally got Firefox building again, moved computers and had to restore environment and fix the tree.
Pushed the latest to https://github.com/dryeo/mozilla-aos branch esr45.9.
The vsync stuff is scattered around thebes, such as https://github.com/dryeo/mozilla-aos/blob/esr45.9/gfx/thebes/VsyncSource.cpp. The Windows implementation might be a good start, https://github.com/dryeo/mozilla-aos/blob/esr45.9/gfx/thebes/gfxWindowsPlatform.cpp#L2733

Whether using the VGA registers will work is a good question. I doubt it on a UEFI install, I haven't had any luck accessing the registers there, and it is loaded at a weird address. Might be possible to get info from Arca Noae how to access it in their VGA BIOS.
Might work on a legacy install.  The screensaver has a fall back of directly manipulating the VGA registers to put the monitor to sleep (set VSYNC/HSYNC to zero), which doesn't seem to work on recent hardware.

The driver does not use the VGA BIOS in any way. It directly accesses the legacy VGA registers.
In PCI config space, it looks for a VGA compatible device when it loads and if it cannot find one, it outputs an error message and aborts. Maybe that is the way to test ...

[Rich Walsh]

it looks for a VGA compatible device when it loads and if it cannot find one, it outputs an error message and aborts. Maybe that is the way to test ...

Lars, the best way to test is to post the binary so people can test... 

[Lars]

Yes, of course. I have built it, I just need to upload to GitHub...

[Lars]

I have now created a release on github.com/lerdmann/vsync/releases.

[Dave Yeo]

I have now created a release on github.com/lerdmann/vsync/releases.

Doesn't seem to be there. Perhaps just post here for testing purposes

[Lars]

Here it is.

[Dave Yeo]

Unluckily, all that happens when running test.exe after installing the device driver is it instantly locks up the system needing a power off to recover (USB Keyboard). Tested on a legacy and a EUFI install.

[Lars]

That would mean that there is no HW that would offer the legacy VGA register set.
Can you provide PCI.EXE output for that system?
The driver checks for a VGA device on the PCI bus and should fail to load if it does not find any.

[Dave Yeo]

Sure.

[Lars]

Hm, your PCI exe output lists a "VGA device".
Can you try the attached ? There is an issue: a VGA compatible color device should have its register block be located at 0x3Dy and a mono device at 0x3By but it looks like many devices have their register block located at 0x3By even if they are color devices.

I have now hardcoded the register block at 0x3By in VSYNC.SYS. Can you try if that makes a difference ?