Average at 100% brightness, I presume?
That explains why some displays would flicker unter CFL room lighting when brightness is reduced only a bit (80-90%).
You're then coming close to their freq. and get interference effects...

I presume, those pins are only missing on cheaper cables that should not be used anyhow due to improper shielding  of electro-magnetic emissions.
It's those thin and flexible ones that feature (if, at all) only tiny ferrit rings...
Thankfully, so far all build-in cables I have found on monitors where of the thicker, prersumably high-quality type.
And nowadays, most cables are pluggable anyhow, thankfully.

Having refresh rate clocks being set by the AC rate is a bad idea since even with modern power grids, there is still some deviation in the nominal 50 Hz for Europe and 60 Hz for the US. Even if it's just ± 2 Hz there may be undesired side-effects.
Of course, with LCDs, you no longer have that pulsed cathode ray but the CCFLs, even on DC, (cf. to CFLs on AC used for lin-room lightning) are oscillating (you can see this very "neatly" when they are broken and start flickering, just like your old 60 Hz CRT wink). This is a form of PWM used to dim the backlight. Unless you operate at 100% brightness (and maybe even then to optimise contrast and/or colour trueness on a factory-calibrated display) it will pulse with the rate being dependent on the brightness.
With LEDs, I suppose, it would be a similar as you cannot simply dim them like a bulb by reducing the Voltage. Of course, if they were to run on AC, being diodes, they'd flicker.

As Jeff's said, you either have to match the room illumination frequency exactly on that on the monitor or you'd have to use a freq that is different enough to prevent interference (cf. beat).

Of course, in the Ancient Times™ when illumination was done by bulbs and monitors and TVs were CRTs and had their flyback transformers were driven by the same frequency, that of the power grid.
Hence, even with variations in power supply, they'd correspond. There were no PLLs to generate clock, only coils and capacitors...
Naturally, it was wise to use a frame rate equal to that frequency, hence PAL with 50 Hz and NTSC with its 60 Hz (nowadays 59.94 Hz, whyever...)


Anyway, as to the advantage of 75 Hz to 60 Hz on an LCD, I'm not quite sure.
Naturally, higher freq means higher bandwidth but the question is, what gives...
One advantage may be a higher frame raten when running on V-Sync; that should result on smoother animations.
If you playback video material, synching to 75 Hz may even be more complicated and could result in tearing artifacts.
For browsing the web or word processing, I doubt it really matters.

Hence the question, why all this efford?
Usually, I do integrate/install monitor drivers if available but rather to have the supported resolutions and horizontal frequencies set up properly for the graphics driver.
Also, some contain ICCs which improves colour reproduction and calibrates them to sRBG colour space (much needed with most LCDs --> new, true white (not fake blue LEDs with yellow phosporous coating!) LED-powered backlights can sometimes even outdo CRTs in this field and cover even more than the Adobe colour space).

I'd rather be able to enforce per-pixel display on LCDs rather than have them bloat the image to full size, more often than desired not even respecting aspect rartio, resulting in a blurry, distorted image.
Yuck!

TechDud wrote:

Do European LCD's use a refresh-rate of 59Hz, instead of 60Hz like here in North America?

Nope.
If anything, we'd need 50 Hz to sync them to the electric grid (which is what had been done to the PAL TV standard).

Abput time!
Seeing as MSFT's server OSes are already 64bit-only, it's a logical step.
And it even more enforces HW manufacturers to supply 645bit drivers, though the situation has eased up a lot lately.

Still, it would be nice to have 64 bit drivers for some legacy hardware - on 32 bit you can even use XP 32 bit drivers on Win7 (for non-Kernel drivers) but that obviously won't work on Win7 64 bit (as there are hardly any drivers for XP 64 tongue)...

55

(4 replies, posted in Software)

Flash is really bad for website design.
Best is not to use it at all and stick with W3C standards and HTML5 compatibility.

A good website does not need to be flashy and animated.
A good website is one that makes it easy for the users to find the information they are looking for.

Alright then.
Just wanted to make sure. smile

Experience has shown, not many folks know about this >2 TB barrier.
Then again, not many seemed to know about the 127 GB one, either...

Just in case you haven't considered it, yet:
Whith drives/partitions > 2 TB, you may encounter strange bugs and incompatibility due to the fact that MBR only addresses around 2 TB (you'd have to use GPT on the drive) and some controller drivers may be bugged (Intel had such a problem with their AHCI drivers in the past - using MSAHCI instead worked fine).
Of course, XP will totally crap out on anything larger than 2 TB as in cannot use GPT and drivers may not be updated by manufacturers.

As you do not want to boot from the drive, obviously, you will not have to worry about EFI - otherwise, you'd need an EFI-compatible mobo and OS (such as Win7 x64).

Just saying...

I could pass you more info, but it's mostly in German, so...

The BASE only works for NT5 DriverPacks.
For NT6, use http://forum.driverpacks.net/viewtopic.php?id=4954 for SAD and http://forum.driverpacks.net/viewtopic.php?id=5199 for integration!

59

(16 replies, posted in Software)

Thanks for the info!

60

(4 replies, posted in German)

Erledigt!

61

(9 replies, posted in News)

Individual Packs are neither the idea of the DriverPacks (it's supposed to be universal) nor do we have the staff to fulfill such requests (at least, in time).
Exclusive access for donateors is something we have already considered, it just has not been implemented, yet.

You know you can edit your post clicking on the link titled the same...
Keeps confusion down to a minimum and the board SF will automatically add time and date of edit.
Just so you know wink

63

(7 replies, posted in Other)

Jeff, don't bother...
http://forum.driverpacks.net/viewtopic. … 633#p42633
He's apparently completely inept to properly c&p.
Guess you copied those shortened URLs as plain text from some forum, not even realising that it renders them useless (on that note, I never understand while fora have to auto-shoten them, but whatever...).

If you are going to c&p links, at least do it properly...
Hint: Right-clicking helps a lot.
The way you posted them, apart from the second, well-known one, they are utterly useless!

PunBB will then automatically convert proper URLs (that is, including the http or ftp URN) to clickable links.

65

(10 replies, posted in Software)

mr_smartepants wrote:
OverFlow wrote:

the method(s) mr_smartepants describes is far superior to going to device manager and hitting search... However if you are dead set on doing it that way his recomendations will not work.

the only way to make that work (and it is slow and clunky) is to extract all the drivers to a DVD, then select search removable media.

Isn't that what I said? big_smile LOL, I need coffee.

Well..., not exactly.
While the outcome will be the same, if one insisted on using on Windows-supplied methods for installing/updating drivers, then you need to put the extracted files on an ODD medium.
That way, when choosing "have disc" in the Device Manager, Windows routines will automatically search the whole disc for drivers.
For some reasons unknown, this will not work with a directory on an HDD - hence you'd have to work at least with mounted disc images...

What you said was simply executing SAD directly for the disc.
(Which, of course, needs the DriverPacks to be extracted on said medium, hence the above will also work... It's 2 in 1 basically smile )
As said, the outcome will be the same, however, some purists may prefer Jeff's method for whatever reason (not trusting us, beleiving the MSFT way is better etc...).

Just saying wink

Virtual PC also runs very fine under Win7.
If you own Professional, Ultimate or Enterprise, you can even use it for XP Mode, a special VM of XP of which programmes will integrate seamlessly into 7.

You should give that a try first, IMO.
You can even connect legacy USB HW for which no 7 drivers are available.

Well, you *could* install it, given the x86 support in the recent versions, however, Apple made sure that it does not work. There are projects around, that try to achieve this: http://www.osx86project.org/ and you can even buy specific HW to enable it, but Jobs already sued them over it...
Anyway, the main reason is that Apple uses some special kind of EFI on the Macs, that is neither compatible with EFI 1.1 or UEFI, as it can be found on certain MBs already.

As for running better on a PC than a Mac:
Well, as I initially said, both are x86 nowadays, so there's hardly any difference.
Intel supplies the CPUs and chipset, and they are the same as for PCs.
Memory, drives, GFX cards are all PC components.
Basically, it's an overpriced PC in a very stylish case with a BIOS mod that makes it appear special wink

Oh, what a question... roll

Which is better, apple pie or rump steak...?

As you cannot install OSX on a PC, that point is really moot.
And if you own a Mac, you might as well install them both.


Oh, and cut the spam or we'll get ya!

Wow, great job at resurrecting the thread.
You only missed the anniversary by a couple of days...

Anyhow, seeing as this is a pointless discussion any way you look at it, let me just say this much:

If XP x64 had not been abandoned by MSFT and (which is directly related to the former) had there been better support by HW and SW makers all around I'm sure we'd include proper support for it.
It's not that we hate XP x64 (or you, for that matter), but facts are, it was merely a tech demo by MSFT at that time and not intended for productive use (which complies with the lack of third-party support).
Our resources are meager so we focus on what's most important and that is not XP x64 support, for the aforementioned reasons.

If you want to dedicate some time and efford into creating NT5 x64 DriverPacks, you are more than welcome.
Please, go ahead! I'm sure, if you were to encounter any issues with the BASE, we'd be glad to help out, if possible.

But all you do is troll about lack of support (for reasons that have been told you several times...) and call any user of Win7 (which is, AFAIK, all of the Team) ignorant noobs.
Great way of begging for a favour, mate...

If you are so expert (and you surely must be, using XP x64 and all), why haven't you accomplished creating a DP for that in over a year (see top of post)?
As your skills excel those of all of us combined, that shouldn't have taken you longer than a week, methinks...

mr_smartepants wrote:

Holy Crap!  >4000 HWIDs in a single .inf!  What were realtek thinking?!?

Taking the phrase "unified drivers" quite verbatim, I guess wink

OverFlow wrote:

@Pants  wouldn't the client still seed even if the folder were redirected???

AFAIK, yes.
When I manually DL the DP torrents, I usually directly let them be placed into the respective sub-dir of the DP folder - disregarding the default save path that I have set in µtorrent.
It still gets seeded until I manually delete it out of the program's list.

So I would say, even with a path given via command line that should work just fine (at least for µtorrent, but that's probably the most common client around from what I've gathered. Not as blown-up as Azureus have become and it's even available portable - for instance as part of LiberKey).

Anyway, I like the idea, too, Rick! smile

Not entirely correct.
In order to create a RAID array, yes, you need at least two HDDs.
However, if you switch the controller mode to RAID in the BIOS, it will also work with only one drive connected.
If you do not create an array, it will work the same way as in AHCI mode, however, a different HWID will be assigned to the controller, therefore enforcing the installation of the RAID drivers rather than ordinary AHCI. That way, you can test whether the driver installs correctly w/o losing any functionality over AHCI (it should still be enabled in RAID mode).

73

(10 replies, posted in Software)

Just about four years late...
The problem is gone for me in the meantime, btw ^^

Whoa! That's quite a lot of text to translate...
I was about to give it a go thinking of a task that could be done quickly.
Guess I'll have to postpone, unless someone else volunteers...

75

(8 replies, posted in Other)

If you really mistrust the DriverPacks (not that there is any reason for, but better safe than sorry) you can scan the archives prior to integration or even afterwards. Doing that while disabling the AV during integration ususally turns out to be faster than leaving it on with no preliminary scan (suffice to say that the packages will be scanned when DL'ed anyhow).

Of course, while AV is disabled, you should not do any other potential harmful stuff on that machine (surfing the web etc...).