SciTech Display Doctor 1.0
Manufacturer: SciTech, Inc.
Price: $39.95 US
Reviewer: James Youngman
SciTech has been selling their product for DOS and Windows for some time now. It is used mainly for installing VESA display services for graphics adapters. This is not an issue for Linux, since Linux programs never need to call the video BIOS.
Display Doctor 1.0 for Linux achieves a goal even more useful than the DOS product; it uses SciTech's driver technology to provide drivers for video cards not supported by XFree86. This includes cards from those manufacturers who will not release the information required in order to allow XFree86 drivers to be written.
This review will cover the Preview Release of SciTech Display Doctor 1.0 for Linux. You can download the trial version from SciTech's web site (http://www.scitechsoft.com/).
Display Doctor can be installed on any glibc2 system which already has XFree86 (3.3.2), GPM, and Tcl/Tk (7.4 or higher) installed. These requirements match one of the machines on which I run Linux. The preview is available as both a compressed tar file and as an RPM package. I chose to install the RPM package, since I was reviewing Display Doctor on a Red Hat 5.1 system.
You can install the package with rpm -i, but you must do this from a virtual console as opposed to a TELNET session, xterm or serial console. After the files are installed, the post-install script proceeds to set up the program interactively. This latter aspect may come as a surprise to those who are used to installing packages with RPM.
The first problem I had was that I needed to tell the install program which mouse protocol to use, even though this information was in a configuration file (an existing XF86Config and the file /etc/sysconfig/mouse on my Red Hat Linux system). The installation program immediately provided a dialog box for the purpose of fixing this, which was quite easy. After doing that, the rest of the configuration process can be navigated with the mouse.
The setup program detected the Matrox Millennium card I installed, but I had to give it the horizontal and vertical retrace specifications of my monitor (this may be because my monitor is four years old). I also have a UK-layout Microsoft Natural keyboard, which some X-server setup programs don't acknowledge, but to my surprise this went without a hitch and I could type the British pound symbol quite happily.
The final step in the configuration process is selecting the screen modes to be available for the X server. At the start of the selection process, every possible screen mode is pre-selected for you. When I started the X server for real, with startx, I was presented with a 1920x1080 screen mode, which unfortunately offers an aspect ratio of 16:9 and looked peculiar on my conventional 4:3 monitor. Exiting X, I removed this mode from the ModeLine list in the configuration file (which, oddly, is still called XF86Config). Restarting X, I was presented with a 1600x1200 screen mode—the same aspect ratio as my monitor.
In use, the SciTech Display Doctor X server worked well. From an installation point of view, it is just another X-server binary (/usr/X11R6/bin/XF86_SDD) and doesn't interfere in any way with the regular XFree86 files. I found this to be of immense benefit and in marked contrast to the MetroX and AcceleratedX products.
The server implementation appears strikingly similar to the XFree86 server; the same set of extensions are provided and the same configuration file name and format is used (with driver name “scitech” instead of “svga” or “accel”). This is a handicap, since it prevents easy changing between X servers (XFree86 bails out when it sees the unknown driver name “scitech”). If you query the Display Doctor X server with xdpyinfo, it appears to be version 3.3.2 of the XFree86 server, which is quite confusing. I assume this particular oddity will disappear with the official release of the final product.
Since this is the preview release, benchmarks are not very illuminating. I look forward to benchmarking the full release of Display Doctor against the next full release of XFree86.
One thing I find most exciting about this technology is that it is just as applicable to Linux as it is to Windows. Even the same executables are used (Display Doctor installs a bunch of Windows-format 32-bit PE dynamic-link libraries in /usr/lib/nucleus). This is of interest to Linux fans, because SciTech is planning to use this same technology to bring the same level of support to KGI/GGI, SVGAlib and the forthcoming frame-buffer support currently in the Linux 2.1 kernel. According to the readme.txt file, Mesa may even benefit from the same treatment.
Unfortunately, I cannot say how Display Doctor made it possible for me to use X on a graphics card that XFree86 does not support. While it would have been nice to try this, the fact of the matter is that I have deliberately bought only hardware supported by Linux. If all Linux users did this, the market for SciTech's Display Doctor would be constricted; on the other hand, some of the things they are planning will advance the scope of the product beyond just X. I think Display Doctor is an interesting option for a bundling deal, particularly if SciTech follows through with their planned feature list.
James Youngman has recently changed jobs from VG Gas Analysis Systems to Logica. He has no significant hobbies apart from drinking real ale (see http://www.camra.org.uk/). James has been (very!) happily married to Erica for just over a year now. James claims to be intending to take up sailing again. You can reach him at email@example.com.
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
|Introduction to MapReduce with Hadoop on Linux||Jun 05, 2013|
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Linux Systems Administrator
- Validate an E-Mail Address with PHP, the Right Way
- Introduction to MapReduce with Hadoop on Linux
- RSS Feeds
- Weechat, Irssi's Little Brother
- New Products
- Tech Tip: Really Simple HTTP Server with Python
- Poul-Henning Kamp: welcome to
1 hour 50 min ago
- This has already been done
1 hour 51 min ago
- Reply to comment | Linux Journal
2 hours 36 min ago
- Welcome to 1998
3 hours 25 min ago
- notifier shortcomings
3 hours 49 min ago
5 hours 26 min ago
- Android User
5 hours 27 min ago
- Reply to comment | Linux Journal
7 hours 20 min ago
10 hours 10 min ago
- This is a good post. This
15 hours 23 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?