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 firstname.lastname@example.org.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- Designing Electronics with Linux
- Elliptic Curve Cryptography
- Getting Help With Linux
- Remote Compilation Using ssh and make
- Mediated Reality: University of Toronto RWM Project
- Writing Real-Time Device Drivers for Telecom Switches, Part 1
- NLE Video Editors
- Memory Leak Detection in Embedded Systems
- Linux Powers Four-Wall 3-D Display
- ViaVoice and XVoice: Providing Voice Recognition
25 min 8 sec ago
- Kernel Problem
10 hours 27 min ago
- BASH script to log IPs on public web server
14 hours 54 min ago
18 hours 30 min ago
- Reply to comment | Linux Journal
19 hours 3 min ago
- All the articles you talked
21 hours 26 min ago
- All the articles you talked
21 hours 29 min ago
- All the articles you talked
21 hours 31 min ago
1 day 1 hour ago
- Keeping track of IP address
1 day 3 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
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?