Simply put, you can't change a company without changing its management - Andy Grove - Only the Paranoid Survive
But the largest fame of Scitech Software's products can be found, even to this day, in the OS/2 users community. When IBM decided to leave their once beloved 32-bit operating system in "suspended animation" mode, just releasing fixes and drivers but not adding new core API changes, -that is in late '99, it licensed Scitech's Display Doctor for OS/2 product, instantly giving thousands of desperate IBM OS/2 users an almost-magical "universal video driver" that works -not only in "framebuffer mode" but with acceleration- with most of the graphics boards on the market.
One of the usual problems in getting Linux to run in some notebooks is something which can be seen at first sight: video drivers. Most linux distros in use these days include one version or another of Xfree86, even while many distros are already switching or planning to switch to the X.Org Project after the controversy surrounding the Xfree86 version 4.4.0 release. Yet, one problem scenario often seen is this: 1. user decides to switch his notebook to linux, 2. he decides on a linux distro and installs it. 3. He boots linux for the first time, only to find that while the screen looks right, the notebook is actually running using VESA mode (without acceleration), or not using the full resolution supported by the graphics card and lcd screen.
Sun Java Desktop System -Release 2- running in VESA framebuffer mode on the Sony PCG-FRV26
If you have a linux-hostile graphics chipset, like the ATI IGP-345M that I quickly found inside the Sony Vaio PCG-FRV26 notebook where I installed Sun's JDS Linux rel.2, you can attempt "following the manual" try the following: 1. Browse around trying to find if the chipset manufacturer (in this case, ATI) has official video drivers. 2. Update the Xfree86 version in your system to the latest release. 3. If you decide that Xfree86 doesn't cut it, download and install a different X server like X.org. The official drivers solution works best if you've got a nVidia graphics chipset -which has the best linux drivers-. ATI still has lot of work to do with their linux drivers, and even then, they don't support the "IGP" series of Radeon chipsets present in plenty of notebooks from Sony, Toshiba, HP/Compaq and others. The ATI IGP 3xx chipset is specially annoying and you can get a hint if a notebook uses one because this chipset uses shared system ram for video. But notebooks and ATI chipsets are hardly the only cause of grief when it comes to getting decent video drivers on linux, I've seen users of desktop PCs pulling their hair as well.
The second solution, updating the Xfree86 subsystem, can lead to problems specially to new users who have not completed such process before. Switching from Xfree86 to X.org can be an even more frightening task for the novice, and of course the moment you start changing subsystems in your linux distro, the less chance you have of obtaining support from the linux company.
The SNAP approach
With SNAP for linux, there's a fourth option: keep using the Xfree86 version included in your linux distro, and configure it to use Scitech Software's SNAP driver. Put in simple terms, SNAP is a "multi-chipset" graphics driver, that supports a number of chipsets ( 168 in version 2.1), including those of companies 3dfx, 3DLabs, AMD, ATI, Cirrus Logic, Cyrix, Intel, Matrox, NeoMagic, Nvidia, Philips, S3, Sis, Trident, and others) with a single driver. In other words, for the X server (Xfree86 in the case of Snap 2.1, and in the latest Snap 3.0 beta, X.org as well), you're using chipset "Snap", and at boot time it's the SNAP driver which kicks in and recognizes the video card. This has another side benefit and potential application as well: you could create a hard drive image of a linux distro of choice installed with SNAP for Linux, and then deploy it across your workplace, without having to worry about video configuration. Keep in mind that you would still have to register Snap on each machine, or purchase a site license from Scitech in that scenario.
Installation should be painless. It just involves executing the text mode binary installer, which places a set of executable binaries in the path /usr/bin/snap/. If your chipset is in the list of supported ones, everything's fine, you just reboot and see your linux graphical desktop restart in full colour glory and with hardware acceleration.
I quickly found after a reboot, however, that the support for the IGP-345M chipset was not present in version 2.1, so tech support advised I'd have to download and install the beta of v3.0. You can quickly find how is your chipset identified by SNAP by running the "gareport" utility from /usr/bin/snap. (hint to developers: why not create file system links to these files with more human readable names like 'snap-report'?, and why isn't /usr/bin/snap added to the system path by the installer so it can be called from everywhere?).
SNAP v2 didn't recognize the IGP-345M, time to switch to Snap 3.0 beta
Scitech takes their work seriously, and they "certify" drivers after in-house testing. While the beta 3.0 version I tested includes support for the Radeon IGP 340M, my Sony VAIO system uses a 345M, not 340 (a slight variation of the same chipset family), so Snap didn't automatically work with the 345. I had to manually enable the "non-certified" chipset by once again invoking the user-friendly command *cough* /usr/bin/snap/gaoption noncert on. Guess what, it worked!. You can see now why I think there should be some user-friendly text menu (why not invoked with the "snap" or "snapdriver" command?) that presents more user-friendly options. That would help SNAP for Linux get beyond the embedded market and linux geeks, and into the PCs of more users.
As a last example, if you run into problems, you're told to e-mail the SNAP log file, which resides in /usr/lib/snap/config/graphics.log. While this might seem like an easy task to do, keep in mind that when things go wrong with a video driver it usually means you have to do the debugging in ugly text mode. So, suppose you're connected on a broadband link, and that you have a gateway/firewall-router in place like one of those inexpensive Linksys units. You can still log on as root, fire a text-mode email program like PINE, and dispatch the log file. But seriously, why force the user to such hassle?. It would be great if Scitech implemented some sort of automated log submission utility that doesn't rely on the availability of external tools or e-mail programs installed, or even better, allows retrieving replies from tech support as well.
I'm sure that for a company that debugs video drivers, writing a script that uploads the snap log files to scitechsoft.com automatically when invoked would be quite easy for them and would please the lazy, "couch potato" spirited former windows users among us.
Succes!. Sun JDS Linux running on the ATI IGP-345M with Snap
The Yast2 configuration screen now identified the graphics card no longer as "vesa framebuffer" but "SDD Snap", which meant that Snap Graphics was now in charge. While I'm not particularly amused by benchmarks, I decided to do a couple quick tests. Since I couldn't find any flashy, colorful system benchmark utility that resembles my favourite PassMark Performance Test on Windows, I had to use XMark and X11perf, part of the xfree86-tools package. With SNAP enabled and snap 3.0 beta (build ), I got an Xmark score of 137.0751, certainly higher than the 25.4008 score I originally got without this build.
The Yast2 configuration utility in Sun JDS linux, showing the display card as "SDD Snap"
With SNAP installed and working, I was finally able to play DVDs with Xine without major stuttering. But, be advised that until Scitech adds hardware overlay support to the product -likely after version 3.0 is out of beta and is finally released, but that's a personal guess-, full screen DVD playback would still be prone to pauses and interruptions, specially if your dvd-rom reader is slow and your cpu is not among the fastest.
The Sony VAIO PCG-FRV26 playing back a DVD in Sun JDS Linux
Company founder and CEO Kendall Bennet comments: "That is because you are doing full software only playback which includes all the colour space conversion and stretching. If you are playing fullscreen then the performance will be dismal unless the driver has at least support for XV. SNAP doesn't yet, but will in a future release."
My personal SNAP outcome, so far?. It's better to have a working accelerated driver, even for everyday GUI work, than to stick with VESA framebuffer mode that you get when the linux distro you're running doesn't "recognize" your graphics card or notebook's graphics chipset. In the particular case of the IGP-3xx series, it's really a shame that ATI gives so little attention to linux users. There are plenty of help requests from IGP-34x chipset owners scattered throughout the Net, like this one with an HP notebook, or here, another with a different Sony notebook which shares the same bloody ATI IGP-345M. It's no wonder then that I've decided to get rid of the Sony VAIO, and switch to another notebook that has a "true" ATI Radeon (9600) which at least has plenty of linux drivers available (Xfree86, X.org, official drivers from ATI, and of course, SNAP support from the start -even in v2.1). For many users stuck with a linux-hostile graphics chipset, exchanging the computer for another might not be a realistic or financially viable option, there's where SNAP comes handy.
The Good, the Bad and the Ugly
Good: Inexpensive. Supports plenty of graphics chipsets, with more being added all the time. Friendly tech support. They've been "doing video drivers" for almost a decade. Small company, listens to its users. They also run their own news server where you can engage the guys behind SNAP, as well as other Snap users.
Bad: Proprietary product (hey, one could wish that some corporate benefactor purchases scitech and makes the product open source ;). Text-mode installer could be more user-friendly, or include a simple text-mode menu that calls all the Snap utilities with the right parameters used for common tasks such as "email logs to scitech software", for instance :). Still no hardware overlay support (expected for the v3.0 release)
If you let the trial version expire, you'll be left with a text-mode linux machine, better keep your registration data in a text file where you can easily find it, say /snap-reg.txt
No 3D support yet, just 2D (gui) acceleration. But seriously, do you know many linux gamers?. I'm not.
Ugly: Nothing really ugly about this product!, it's a "driver". Either it will work for you or it won't.
While not open source as the FSF purist in me would like, and surely "not for everybody" -there's plenty of users for whom the video drivers bundled with linux distros work just right- SNAP for Linux fulfils a need of some users in the linux community. It can be a good and technically interesting solution to video driver blues for those just jumping to Linux, -and at $19 per copy, it's an affordable one. Not a bad price to get an almost universal video driver that can work not only in your PC of today, but very likely in the one you'll get tomorrow as well. I give the beta 3.0 version I tested 4 Fernandos in my personal one-to-five rating scale. The 2.1 version? it gets 3 Fernandos due to lack of support for more recent chipsets.
While the current version 2.1 might not support your chipset yet, version 3.0 should be out of the door soon. If you ask nicely, the folks at Scitech Software might even allow you to test the 3.0 beta version. Or if you want to stick with the last version released, the trial of version 2.1 is here.
The company has a lot of plans for the future, a 64-bit AMD64 port and adding support for the "XV extension" used by DVD linux players Mplayer and Xine for hardware overlay, among other goodies. Kendall Bennett told the Inquirer "We are working on the new features that potentially will improve performance (and full hardware DVD playback for ATI cards!)". It certainly sounds like something worth supporting by trying out Snap and buying a licence if you find it eases your Linux video card blues. Notice that I said "ease", not "cure". To cure the linux driver blues, ATI should take an example or two from nVidia. µ
Sign up for INQbot – a weekly roundup of the best from the INQ