BIOS Problem: Bootup to Blank Screen

I had a working computer.  Then I decided to fix it.  Now the screen was completely black.  The computer seemed to have booted up nonetheless -- the hard drive light was flashing now and then, suggesting that some program was playing with itself in what I hoped was a nondestructive fashion -- but I could not see anything onscreen.  The monitor was plugged in and turned on, but I guess we were no longer on speaking terms.

What I had tried to fix was a setting in the BIOS.  I was using a Gigabyte GA-MA785GM-US2H motherboard with an Award BIOS (v. 6.00PG).  On bootup, I hit DEL and went into the BIOS settings -- specifically, into Advanced BIOS Features > IGX Configuration > UMA Frame Buffer Size.  My objective was to dedicate some system RAM to video.  So I hit Enter and changed the IGX Configuration from Auto (the default) to 512MB and rebooted.  This gave me the aforementioned black screen, just as it had done for another poor soul.

So now the question was how to fix it.  I first tried to do it blindly.  I booted the machine and kept hitting DEL for a while, figuring that this would take me into the BIOS setup.  Then, following the sequence of steps that would have been required to change the IGX Configuration back to Auto on another machine, I went through a series of keystrokes (Down, Enter, etc.).  Those steps, done in the proper order, took me to the IGX Configuration part of the BIOS on that other machine.  But they didn't seem to work on the blacked-out machine.  When I hit the keys needed to save the settings and reboot, I found myself still looking at a black screen.

If the BIOS was fubared such as to produce a black screen immediately upon bootup, without ever showing a trace of life, then it wouldn't seem to matter whether I booted with a CD, USB drive, floppy, or hard drive.  The one exception, I figured, would be if I booted with some program designed to speak directly to the BIOS.  And for that, the candidate was presumably a BIOS flasher.

In other words, I saw an opportunity, here, to update my BIOS while fixing it.  For this solution, I went to the motherboard's BIOS upgrade download webpage.  Gigabyte had a program called Xpress Recovery2, but its purpose seemed to be to recover hard drive data, not to recover the BIOS.  They also had @BIOS, a live update utility, which would have been great if I could have booted Windows to run it.  The motherboard's manual seemed to be telling me that I needed, instead, to use its Q-Flash utility.  Q-Flash was said to be embedded in the motherboard's hardware, so I wouldn't need any particular drive to run it.  It said I could use Q-Flash to install a BIOS update that I would download on the other computer and save to a FAT32/16/12 USB flash drive.

But could I use Q-Flash if I couldn't even see it?  The way to fire up Q-Flash, according to the manual, was to hit the End key while the system was booting.  The blanked system was currently running, so I tried using WinKey-U-R to restart it, since I could see that those keystrokes were what it would have taken to reboot the other computer from Windows 7.  I gave that several minutes, since I had no idea what was running on that computer at this point.  I never got a beep, though, so I thought maybe it was waiting for me to Force Restart.  I hit the F key.  Nothing happened.  I tried Enter.  A brief hard drive flicker.  I gave it another minute and then just punched the reset button on the computer.  Then I kept hitting End for a while.  Perhaps I was now in Q-Flash.  No way of knowing:  the screen was still blank.

I thought of trying to trace my way through a BIOS flash blindly, as I had tried to trace through the reset of the IGX Configuration option.  Thinking of that gave me an obvious idea:  reset!  Maybe I could just take the steps needed to reset the entire BIOS back to its defaults.  I punched the computer's restart button again and then, after I got the reboot beep, I kept hitting Del, twice a second for about 15 seconds.  The keys I hit at this point (copied, again, from the sequence on another machine running a hopefully similar CMOS setup utility) were:  right-arrow (to take me to the option for Load Fail-Safe Defaults), Enter (to actually load those defaults), then Y to confirm, then F10 to save and exit.  That produced no results, so I hit Esc several times, in hopes of backing out to the main CMOS menu, and tried again:  Right, Enter, Y, F10.  This time I added another Enter for good measure.  And oh, my Christ, it worked.  I was able to read my screen again.  Fricking brilliant.  Amazing what you can do when you can't see a thing.

I went back into the BIOS, because of course I hadn't had enough of this, to take a look at how things were now.  The UMA Frame Buffer Size was back to Auto.  Funny, I didn't recall even seeing a UMA Frame Buffer option on the other computer.

It seemd obvious, now, that I should have just gone directly for the Fail-Safe option in the first place.  I reconfigured the BIOS as desired, saved, and rebooted.  Everything was fine.  I wasn't going to need to root around anymore in my Google search for solutions.  Although I did realize, a bit later, that I probably could have achieved the same thing, without working blindly -- resetting the BIOS (a/k/a clearing the CMOS) -- by either removing the quarter-sized battery from the motherboard for five minutes or shorting across the motherboard's "clear CMOS" jumper, which the manual would probably have helped me to find.

But no.  Not so fast.  On reboot, I was back to a black screen.  Why?  I hadn't even touched the IGX Configuration stuff this time around.  But, ah, false alarm.  Apparently the fail-safe options concealed the Power-On Self-Test (POST) information.  After a short panic, I had Windows onscreen.  I'd just have to take another look at the CMOS setup, next time I rebooted, to find the setting that would restore the POST display during bootup.  There may have been a way to do that with Gigabyte's Easy Tune utility, though if there was, it wasn't immediately obvious to me.

I decided to go ahead and deal with that now.  Unfortunately, when I rebooted and hit Del repeatedly, it just gave me a blank screen.  I hit Esc and then Enter, to exit the BIOS and reboot without saving any changes, but that didn't do anything.  I tried again, and then tried F10 and Enter.  After a blank screen, that got me back into Windows, at least.

Well.  Were the fail-safe defaults preventing me from getting into the CMOS setup?  It seemed that maybe I should go ahead and update the BIOS after all, or else open the computer and use one of those hardware BIOS-reset methods.  I ran Gigabyte's @BIOS utility and selected the "Update BIOS from Gigabyte Server" option.  I had to approve a couple of choices, and then it ran.  In a half-minute or so, it had apparently downloaded the new version.  It said this:

The screen will freeze for a few seconds while updating the BIOS.
Do you want to update the BIOS?

I clicked OK.  After a moment, it said, "BIOS Update completed!  You must restart your system to take new changes."  I said, "Restart Later."  I didn't want to lose all the stuff I had open, so I hibernated the machine (Start > Shut Down > Hibernate) and then, after it died, I pushed the power button and started it back up.  That worked:  I could now see the POST screen.  I hit Del and went into the CMOS setup.  I had to reset the clock and make other adjustments.  Then I rebooted.  And yet, once again, I was not seeing the POST screen, though once again at least the computer did proceed on into Windows.  It seemed that maybe one of my changes was responsible for this, or else perhaps that the hibernation was fouling things up.

It was hard to tell what ultimately fixed this.  Something did.  When I returned to these notes a while later to wrap up this post, I was no longer having the problem.  Possibly the steps described here did solve it on reboot, though I think in that case I would have made note of it.  It seemed I would need to have the problem again in order to comment further on it.

Documenting Computer Work with Screenshots and Duplicate Detectors

I was doing some work in Windows 7.  I wanted to log the changes periodically as I went along.  I had already developed a batch file, which I called Shotshooter.bat, to take screenshots and save them as .png files periodically.  (I think this will work in all versions of Windows.)

Having already done the NirCmd setup required to make that batch file work, I slightly revised it to read as follows.  (If the print is too small, use Ctrl-+ or copy and paste into Notepad.  Batch files are best not edited in a word processor like Word, since they change characters sometimes.)

:: Shotshooter.bat

:: Captures a series of screenshots.

:: See http://www.nirsoft.net/utils/nircmd.html for info on NirCmd.exe.

:: Takes two arguments:  how many shots, and how many milliseconds between shots.

:: Sample usage:  shotshooter 3600 1000
:: That example would take screenshots every second for an hour,
::   assuming the computer could work that fast.

:: To kill the program sooner, use Task Manager (Ctrl-Alt-Del) > Processses > nircmd.exe.
:: IrfanView provides a fast way to play back results.

:: Create Screenshots folder on drive D

D:
md \Screenshots
:: Go to the drive and folder where you put NirCmd.exe

W:

cd "\Start Menu\Programs\Tools\Programming and Scripting\NirCmd"
:: Run NirCmd with the desired settings

nircmd.exe loop %1 %2 savescreenshot D:\Screenshots\scr~$currdate.yyyy-MM-dd$-~$currtime.HH_mm_ss$.png

:: Go see what you've created in D:\Screenshots

start explorer.exe /e,"D:\Personal Projects\View These Weekly"

Having created Shotshooter.bat, now I wanted to run it.  I had already used Ultimate Windows Tweaker (UWT) to install a right-click option to open a command window in any folder I would select in Windows Explorer, so all I had to do was open a CMD window where I had saved Shotshooter.bat, and just type "shotshooter 1200 30000" and hit Enter.

(If I hadn't installed that option with UWT, I could also have gone to Start > Run > cmd and then navigated manually to the proper folder with change-drive (e.g., D:) and change-folder (e.g., cd "folder name") commands like those used in Shotshooter.bat, above.  Note that quotation marks are necessary if folder names contain spaces or possibly if they are too long.)

Those parameters of 1200 and 30000 meant that Shotshooter.bat would use NirCmd to take a screenshot every 30000 milliseconds (i.e., every 30 seconds), and would take a total of 1200 screenshots (i.e., would run for 10 hours).  It would save them in D:\Screenshots, and now I would have to decide what to do with them.

When I was writing up these notes, I didn't recall whether NirCmd could also produce JPGs or other image formats.  It probably could.  But after getting used to IrfanView, it probably would have been easier to just use IrfanView (File > Batch Conversion/Rename) to do a mass conversion of PNGs into JPGs if necessary.

The problem with a straightforward slideshow was that, if I allowed a few seconds for each screenshot, I could easily wind up with an hourlong show that would feature extended periods of no change.  On this particular day, I had gone to the store and out to lunch, so presumably nothing was happening during those periods.  The changes that I would want to see might pop up for only a few seconds in that hourlong show.

It seemed I had better get rid of the PNGs that merely repeated the same unchanging screenshot for long periods of time.  To do this, I tried a couple of approaches.  After making a backup of my Screenshots folder, I started with Awesome Duplicate Photo Finder (ADPF).  I adjusted its settings to examine PNGs and told it to search only the D:\Screenshots folder.  It felt that, out of my 1,200 screenshots, 1,160 were potential duplicates.  Closer examination revealed that, while many of those files were not what ADPF considered 100% identical, hundreds were.  Unfortunately, ADPF did not offer a way to bulk-delete the 100% matches.  I did not take the time-consuming approach of just letting ADPF guide me through the 580 pairs of images comprising those 1,160 alleged duplicates, making manual choices as to whether I should delete one of the two images it showed me.

I tried another approach.  Among the many free duplicate file finders, I had long used DoubleKiller.  (Exact Duplicate Finder gave the same results as one type of DoubleKiller comparison, but offered fewer comparison options.)  For some reason, a CRC and size comparison in DoubleKiller gave me only 161 duplicates.  I suspected DoubleKiller was being too precise.  Doing an unreliable size-only comparison, it still found only 340 duplicates.

Following the advice on a page that recommended five duplicate file detectors, I downloaded and installed Dup Detector.  It was not easy to understand, but some tinkering I was able to get it to work.  The first time I ran it, I told it to search only for 100% matches.  (By default, it was set to search for "Dup if within 98.5% to 100% match.")  The thing that made it work was to go into its Options > "Automatic and Semi-auto delete setup," highlight the "Delete left image" criterion (the only criterion I needed to use in this case) and use the "Swap up" and "Swap down" buttons to make "No delete" come after "Delete left image."  Then, to make it run, I had to start with Get data > Build.  Also, because of the number of files, I thought I had better start with Find > "Find dups setup (method and restrictions)" set to find 9999 pairs.  I still wasn't sure, at the time when I was writing these remarks, whether that was a good number to put there.

When I ran Dup Detector to search for only 100% matches, it found that about half of the PNGs were duplicates.  I eyeballed some of them, using IrfanView to flip through them quickly with just a right-arrow keypress.  There did appear to be a lot of exact duplicates.  I ran an automatic delete to get rid of those dups.  Then I ran a DoubleKiller search for matches that had both identical sizes and identical CRC checksums.  DoubleKiller still turned up 79 pairs of duplicates.  Apparently there had been more than 9999 pairs, first time around.  (If there were more than 100 exact duplicates, then there would be more than 9999 possible pairs.)  To check this, I ran another Dup Detector search for 100% matches.  It found a bunch more.

It seemed, then, that the best strategy would have been to run DoubleKiller first, so as to get rid of one item in each exact pair.  I did that now.  Then I ran Dup Detector, looking again only for 100% matches.  It found none.  I tried again, this time with a search for 99.9% to 100% matches.  Again, it found 9999 pairs.  Some looked identical, in the program's necessarily reduced and imperfect matchup screen, but the differences in others were visible -- more than 0.1% different, I would have thought.  I tried another search, this time adding a decimal point -- looking, that is, for 99.99% to 100.00% matches.

While that was underway, I ran another of the simple comparisons available in ADPF.  It said that, of the 851 pictures remaining (out of the original 1,200), it found 811 similar pictures.  In the bottom pane, I clicked twice on the Similarity column heading, so as to see what it considered the 100% matches first.  I couldn't tell any difference between the ones that I looked at.  I wasn't sure why ADPF had not considered them identical.

Before doing anything with that ADPF comparison, I went back to Dup Detector.  It had completed its 99.99% search.  It was still finding 9,999 pairs.  I had already noticed that, unlike ADPF, Dup Detector was not able to show the right portion (maybe one-sixth) of my widescreen screenshots.  I also noticed that the first line of the Dup Detector report, in the top left corner of the screen, said that it was comparing 99.9% (not 99.99%) matches.  So unless there was a bug in that report, apparently one decimal place was as precise as it got.

I preferred ADPF's visual comparison, so I went back to it.  In the bottom pane, it looked like about two-thirds of its similar pictures were at the 100% level.  That would apparently mean I would have to do hundreds of manual comparisons:  Picture 1 might match Picture 2, and also Pictures 3, 4, 5 . . . I went down to the 99% matches.  These, too, were identical, as far as I could tell.  I had noticed, in IrfanView, that the only thing that had changed since the previous screenshot, among some screenshots, was that the system clock, in the bottom right-hand corner of the screen, had moved ahead by one minute, so maybe that sort of thing kept ADPF from catching them at the 100% level.  ADPF wasn't showing the taskbar or other outer edges of the screenshots, so I couldn't tell for sure.

With hardly any exceptions, I found that even the 95% matches in ADPF were virtually identical.  The only differences that I could detect, in the 50% of less of matches where I did see a difference, was that a different window might be foregrounded -- that, in other words, its title bar would be a different color in one screenshot than in the other.  In other words, the ADPF matching levels seemed more realistic than those in Dup Detector:  this was the kind of difference that I would expect to be detected at the 96% level, well before the 99.9% level.  A 99.9% match, I felt, should involve no more than the tiniest flyspeck of difference.

For my purposes, I did not get regular, visible differences in matches, in ADPF, until I was down at the 91% level.  There were few matches at that level, so I decided to err on the safe side, manually deleting duplicates down to the 95% level.  But in the process, I stopped along the way to re-run Dup Detector.  It seemed I might be able to calibrate it against ADPF.  In other words, I first deleted all of the 100% matches in ADPF, and then ran Dup Detector.  There were about 360 of those, or about 45% of the 811 similar pictures detected by ADPF.  Deleting them was pretty fast, once I got the keystroke combination worked out; it probably took 6-7 minutes.

Rerunning Dup Detector at the 99.9% setting, after deleting ADPF's 100% matches, still produced 9999 matches from the 482 screenshots remaining.  I expected it to produce matches that were extremely difficult to tell apart.  This was not the outcome I got.  There were a number of rather obvious (although still very minor) differences.  It seemed, at this point, that Dup Detector's supposed 99.9% match was not realistic and, for my purposes, not meaningful.  In general, it seemed that Dup Detector had been useful only for purposes of automated deletion of 100% matches, though possibly that function would have been served equally well by an easier DoubleKiller comparison in terms of file size and CRC.  It didn't look like Dup Detector had anything more to offer me at this point.

In the interests of automating future comparisons, I looked around for a free bulk CRC calculator, but ultimately got better results searching for an MD5sum program in CNET.  I thought about FSUM but finally went with the somewhat higher-ranked MD5summer.  Both would do batch work and yield text-file output, but FSUM was command-line.  MD5summer did give me the option of saving its calculated sums as a text file, which I then imported into Microsoft Excel.  Using text parsing functions (e.g., MID, LEFT, TRIM), I extracted the 32-character checksum, sorted, and used a formula to compare cells.  MD5summer had evidently identified only 322 duplicates in 161 pairs.  Possibly the reason the duplicates were found only in pairs was that I had run Shotshooter (above) in 30-second intervals:  there would be only two screenshots per minute, before the system clock changed, producing a screenshot with a different checksum.  That had probably been the case with the DoubleKiller CRC checksum results as well.

One workaround would have been to see if I could conceal the system clock before starting, or I could batch-trim the PNGs in IrfanView (File > Batch Conversion/Rename > Advanced > Crop) before running the checksum, but in this case I wanted the clock to be visible on the output.  (I could also have used cropping, or could have drawn circles and arrows on my PNGs, using something like Photoshop, to narrow the focus to particularly interesting changes on the screen, so as to reduce the percentage match that ADPF or other duplicate detectors would calculate.)  I could have done the batch-trim with a copy of the snapshots backup folder, so as to produce a list of files to be deleted without harming the originals (or, in this case, the copies).  But what if the only thing that changed (in some future application) was a small item in the center (i.e., not at the edge) of the screenshot?  I could use the spreadsheet to identify not only the duplicate pairs but also the time periods during which every minute had a matching pair, so as to lead me toward large stretches of time when nothing would change, and then maybe a manual comparison in ADPF would be manageable for the rest.

So those were possibilities for future projects.  At present, having deleted the ADPF matches down to the 95% level (leaving a few near-duplicates where I could quickly see a difference), I continued on a bit further in ADPF, deleting some additional near-duplicates.  At the 91% level, almost every pair of near-duplicates contained visible differences, so I stopped there.  So I was done with ADPF.

I now had 442 fairly distinct screenshots, out of the original 1,200.  I would have had more if I hadn't abandoned the computer for several hours while Shotshooter was running.  I viewed a bunch of them in IrfanView, again using the right-arrow key to move quickly to the next.  I had already set IrfanView (Options > Properties > Browsing/Editing) to go to the next file after I deleted one -- or maybe it did that anyway, by default.  It now occurred to me that some of my ADPF work might have been faster, and that differences might have been easier to see, if I had just paged through the screenshots (or at least some of them) in IrfanView, using the Delete key (alternately, the X button, up by the menu bar) to delete apparent duplicates.  When I ran into a stretch where there seemed to be many duplicates, I stopped hitting Delete (in case, by deleting too fast, I would accidentally delete one after the screen did change) and instead just selected and deleted many at once in Windows Explorer.

Holding down the right-arrow key in IrfanView allowed me to page quickly through obviously similar or dissimiliar screenshots.  There were still quite a few, requiring as many as 90 virtually duplicate screenshots to be deleted in one case.  It seemed that ADPF may have been fooled, not only by the system clock (which still seemed to be the only thing that was changing, in many cases), but also by relatively complex screenshots (e.g., showing photographic or Google Earth images rather than just text documents, spreadsheets, and Windows Explorer sessions).  That is, to my way of thinking, many of these images were 99% similar, but ADPF hadn't even considered them 91% similar, so possibly its comparison engine was miscalculating similarities in some conditions.

After these other steps, I took a final trip through the snapshots, in IrfanView, and deleted a few more that were very similar to the ones immediately preceding them.  I wound up with 207 snapshots, out of the original 1,200, that seemed to represent fairly well what I had been doing over a 10-hour period.  Again, the number could have been substantially larger -- maybe around 300-350 -- if I hadn't spent a few hours away from the computer.

Now I wanted to put these snapshots into some kind of slideshow.  I rarely made slideshows.  On a few of the screenshots, I decided to use Adobe Photoshop Elements to draw circles and lines to draw attention to changes, from one slide to the next, that might otherwise escape attention.  Then I figured I would use IrfanView (File > Slideshow > Save slideshow as EXE/SCR) to create a slideshow.  (I could also have used something like PowerPoint, except that apparently that would have required me to create 207 slides and then import a photo into each.)  But IrfanView wouldn't let me add circles and arrows or, as seemed increasingly appropriate, a voiceover, to explain what was going on.

I tried using both Adobe Premiere Elements and CyberLink PowerDirector, but neither of them wanted to let me export to a full widescreen format.  Saving it in a reduced format (e.g., 720x480) lost so much detail that it was hard to read what was being displayed.  They also created huge files.  These programs -- especially Premiere Elements -- were also pretty terrible at giving me a simple way of arranging slides.  I wound up just creating an IrfanView EXE slideshow in full-screen mode -- and you know what?  It was beautiful.  Visually, it was perfect.  It looked exactly like the regular computer screen from which I had created all those screenshots.  And it was only 91KB.  Tiny!  The only drawback was that it couldn't incorporate a voiceover and lines and arrows.  So the output side of this project was still in development.

Windows 7: KVM in a Multimonitor Setup

I was using two monitors with two computers.  After reflecting on multiple monitor possibilities, I installed an ASUS EN210 video card in each computer.  This allowed me to connect dual displays.  I decided that monitor A would be available to both computers, and monitor B would be available only to computer B.  To make this happen, I connected monitor A to a keyboard-video-mouse (KVM) switch.  So computer A was visible only on monitor A, whereas computer B was visible across the two monitors (assuming that's where I had the KVM set).

Problem:  every time I switched back to computer B on the KVM, monitor A would go blank.  This was not a problem when I was using the KVM only to switch the mouse and keyboard, leaving each monitor dedicated to one computer.  It arose only in the dual-monitor setup.  It seemed that the computer was not remembering the dual-monitor settings for monitor A on computer B.  Each time, I had to go back into Control Panel > Display > Change Display Settings > Detect.  (This KVM problem also seemed responsible for screwing up Adobe Acrobat 9. It was no longer remembering my toolbar settings the way I had previously set them. This seemed to be fixed by going into Acrobat's Help > Repair Acrobat installation.)

A search led to the suggestion that the problem I was having with monitor A was with the KVM:

It is a problem found with those KVM switches which did not pass the console display's EDID and DDC information to all the systems connected to the KVM switch. ...
Windows 7 checks display and display card constantly different from what XP and other operating systems did.
To solve this issue, just replace the KVM switch with those KVM switches supporting FULL TIME Active DDC function.
Please check ConnectPRO new UR or PR serial KVM switches which support Active DDC function to all the ports.

That post pointed me toward a Microsoft webpage with more technical information.  I did another search and saw references to ConnectPRO there too.  A different search suggested that lots of users were running into this problem.  Newegg's Power Search didn't offer an operating system selection, and they didn't seem to carry ConnectPRO KVMs.  A Google Shopping search led to two ConnectPRO KVMs, each costing at least $130.  I ran across a workaround suggestion to hit Win-D before and after switching with the KVM, but apparently that worked only with XBOXes, or anyway it didn't work for me.  There was another workaround, too technical for my blood.  Another thread prompted me to check for the most current driver for my ASUS EN210 graphics card.  As I recalled, the usual advice was to look for the latest drivers on the chipset manufacturer's webpage, so after consulting the details on the EN210, I went to the NVIDIA website and searched for GeForce 210 drivers.  I went with the most recent WHQL-certified driver.  After reboot, I saw that this did not solve the problem.  Note:  the machine had all current Windows updates at this point.

It seemed I had a choice.  I could go back to using one monitor per computer, or I could look for a hardware multimonitor solution.  Going back would mean waiting for Microsoft to fix this problem with Win7.  There was no guarantee that that would ever happen.  Basically, if I wanted multimonitor support for KVM-type functionality for two computers running Win7 (as distinct from one Win7 and one WinXP), it seemed I would either have to buy an expensive KVM or maybe come up with some other kind of funky plugging and switching.  For instance, I wondered whether I could make a go of it with two keyboards, two mice, and a switch just to flip monitor A from one computer to the other.  But this wouldn't circumvent the problem that Windows 7 was constantly polling the monitor, and that was the only thing that counted.  I found a device called the Geffen DVI Detective, which for $80 would remember the EDID and therefore defeat the problem (but only for monitors using DVI connectors).

Then I saw that Amazon carried a bunch of ConnectPRO KVMs, and some were far less expensive.  They did not carry the PR-12, which was the one PS/2 (as distinct from USB) KVM that ConnectPRO offered for my humble purposes:  two computers, one keyboard, one monitor, one mouse.  USB did not work reliably for both keyboard and mouse when Win7 was not running -- when, for instance, I was booting from a CD, or was adjusting the BIOS settings before the operating system booted.  But then I remembered that my new motherboards had only one PS/2 port, and the PR-12 would definitely require two (one each for keyboard and mouse).  I did have the option of using USB mice, one dedicated to each computer, and in fact had been doing that for a while, partly for the reason of pre-boot capability just mentioned and partly to reduce the strain on either wrist.  Another option was to use an adapter or some other gizmo to give me a second PS/2 port.

From ConnectPRO's product comparison page, it seemed there were several options to consider.  One was the choice between VGA and DVI.  DVI provided superior video, but VGA (using D-Sub connectors) was functioning well for me at the moment.  (DVI achieved using DVI-VGA adapters had, in my impression, the same risk of video problems as plain old VGA.)  It seemed that a couple of inexpensive video cards had eliminated problems of ghosting that I was getting when I had the monitors connected directly to the motherboards.  There was also the choice of two- or four-computer KVMs.  I needed only two.  Switching via hotkey was preferable to having to reach up and punch a button on the KVM in order to switch between computers.  All of the relevant ConnectPRO KVMs had All-time Full DDC, which was evidently the core need behind this KVM search.  ConnectPRO's Pro line of KVMs apparently did not have the Dynamic Device Mapping (DDM) technology that would remember attached USB peripherals (e.g., speakers, mice) and would thus eliminate lag time required for the switched computer to re-detect the devices.  It was confusing, shopping among these devices on Amazon, because there were various "kit" options that were described as "new" and yet did not appear on ConnectPRO's website, and also because now it started to look like some of these products did not have Full DDC and/or DDM.  What I came up with was a choice, for me, between the UR-12 PRO, with VGA and DDC but not DDM and no hotkey option ($102 with shipping from ConnectPRO through Amazon); the UR-12 PLUS, with VGA, DDC, DDM, and a hotkey option ($176); and the UD-12 PLUS, which was the same as the UR-12 PLUS but with DVI (and therefore with VGA as an option, via adapter) ($191 from a couple of sellers).

Since I was having no video issues at the moment, and might not have any again for some time, I decided to go with VGA rather than DVI, all other things being equal.  If I did get video problems, I could sell one KVM and upgrade to another later.  So then it was a question of whether I was willing to pay an extra $74 for DDM and a hotkey option.  DDM was nice -- I had noticed the lag in responsiveness at some point, hard to recall at the moment but apparently when I had upgraded from Windows XP to Windows 7 -- but that was not really bothering me much at present.  Those delays, and the hotkey, were especially important when I was doing a lot of switching between computers, which happened primarily when I was testing or tinkering with hardware or software on one machine and logging the developments on the other.  I was not presently doing much of that, and didn't plan to be doing much of it anytime soon.  It occurred to me that, if the DDM lags did bother me at such times, I could always dedicate one mouse, one monitor, and one keyboard to each computer at those times.  I could arrange that on my desk, and then the only lag would be the time needed to reorient my hands on the other keyboard.  Indeed, for purposes of working with the BIOS and such, I could simply keep a PS/2 keyboard always plugged in and standing off to the side of each computer, in addition to the USB keyboard connected to the KVM.  (PS/2 was not hot-swappable; it would be necessary to reboot to have the keyboard be recognized if it were not plugged in at time of bootup.)  Looking at the choice again, I reconsidered that the price difference between the UR-12 PLUS and the UD-12-PLUS was only $15.  From that perspective, I would choose the latter over the former, so as to wrap up the best product at not much additional cost; and in that case, the price difference between the solution with or without DDM, hotkey, and DVI was substantial:  the UD was almost twice the price of the UR.

As long as I was sure I did want to use dual monitors on computer B, sometimes swapping monitor A between computers A and B, I would need Full DDC, and it seemed the choice was then to spend $102 on a ConnectPRO UR-12 PRO KVM.  If I hadn't gotten the video cards for only $18 each, the decision to add dual monitor capability (with KVM and video cards) would then have cost me more than $150.  It was worth it -- dual monitor capability added a lot to a workspace -- but it was turning into more hassle and expense than it should have been.  I belatedly realized that perhaps I should have looked for a motherboard with dual monitor capability and with enough video memory so that the computer would not struggle to switch between windows on the same monitor, as computer A had been doing before I added the video card.  Desk space permitting, that kind of expense also raised the question of perhaps having three dedicated monitors -- one for computer A and two for computer B, and recabling one of the latter to computer A if a multimonitor need arose there -- thereby reducing the KVM need to a simple $20-30 device that would swap keyboards and mice, assuming those were not likewise dedicated to single machines.  The temptation to just get a third monitor and forget about the Full DDC KVM would be even stronger if I were looking at the nearly $200 price tag for a ConnectPRO UD-12 PLUS KVM.  But even without that, as I considered the time I had devoted to screwing around with KVMs, on this and on previous occasions, I did think that possibly the best approach would be to go with the third monitor, wait for someone to compete with ConnectPRO and/or for Microsoft to get its act together -- to buy a third monitor as an interim solution, in other words, and to sell it when and if a superior KVM alternative emerged.

Adding a PS/2 Port

I had always used PS/2 rather than USB mice and keyboards.  USB had the drawback of not being functional in some circumstances (e.g., when I was booting from some kinds of CDs, or was adjusting the BIOS settings before the operating system loaded).  This seemed to be true even when USB devices were enabled in BIOS.  Unfortunately, my new motherboard had only one PS/2 port.  I would now have to go with at least one USB device.  Between the two, USB mice seemed to function better than USB keyboards in the environments just mentioned, so I could live with a PS/2 keyboard and a USB mouse.

Problem:  I had two computers, and was using a keyboard-video-mouse (KVM) switch to share my mouse, keyboard, and monitor between the two computers.  Now I needed two PS/2 connectors unless I wanted to get a USB KVM, mouse, and keyboard.  I didn't want to spend the money, and I liked the PS/2 KVM better than what I was seeing in the USB KVMs.  So there was a question:  could I add a second PS/2 port to a computer with just one PS/2 port?

I tried using Y-splitter cables, which were physically able to connect two PS/2 devices to one PS/2 port.  But they didn't work:  only one device or the other (i.e., mouse or keyboard) would operate.  I ran a search and saw some references to adapters that would convert the computer's serial port to PS/2, though apparently that could have its complications.  The pictures looked familiar.  I dug around and found that I already had something like that.  I didn't want to reboot the computer right then to try it out, so I searched a bit more.  There seemed to be some USB to PS/2 adapters; presumably those wouldn't have the serial port problems.  I also found a PS/2 adapter backplate, which would have required an unused PS/2 header on the motherboard.  I wasn't sure if my mobo had one of those, but I could scope it out when I did shut down.

I wasn't sure which of these solutions I would ultimately wind up using, or even if I would definitely try to stick with PS/2 rather than USB.  This is as far as I took the question at this moment.

Two Computers, Two Displays, Together and Apart: TeamViewer, KVM, and Input Director

I had just installed Windows 7, after working out networking hassles between two computers.  I had set up a home network.  Now, following up on a previous post, I wondered whether I could use TeamViewer and Input Director to permit smoother use of those two machines.  The general idea was that I had two networked computers, each with its own monitor, and I wanted to use one or both of those programs to facilitate a seamless desktop experience.  This post describes my exploration of related possibilities.

I decided to start with Input Director.  The purpose of this program was to let me use a keyboard and mouse on computer A to do work on both computers A and B, without needing a keyboard-video-mouse (KVM) switch.  To give this a whirl, instructions advised installing Input Director (ID) on each computer.  I started ID on computer A, turned aside for a moment to attend to something else, came back to computer A, and found that ID had disappeared.  I restarted it and clicked "Enable as Master," and likewise enabled computer B as slave.  I started to change the default hotkey from the way they had it set up, which looked very complex but apparently just meant left-Ctrl-Alt-Break -- but then ID disappeared again!  It wasn't in the system tray either.  It had just died.  But on retry, it was OK.  I wasn't sure what happened there.  I went into Master (or Slave) Configuration.  Not to much to do there.  On computer A, I clicked Add and then tried to figure out what I should use as Hostname and Port for the slave I was trying to attach.  I tried just using the name of computer B.  This brought an error, "Slave 'ComputerB' didn't respond," and on computer B I got a popup balloon saying this:

Unauthorised access
A request to direct input by the unauthorised system ComputerA was rejected.

I thought maybe this was because computer B wasn't set up yet.  So in its Slave Configuration tab, I clicked "Allow computers only on this subnet to take control."  It asked for Network and Mask, which I wasn't sure of, so I clicked "Select from list."  I had VMware on this computer, so there were a couple of options for that, but I went with the one for the Realtek PCIe GBE Family Controller.  I also clicked on Add and typed in the name of computer A as Master Hostname.  Now both computers were visible in the Master Configuration tab on computer A.  In the Master Preferences tab, I cleared hotkeys, since I didn't think I would want to use them and didn't want them interfering with other programs.  And then, what do you know, it was working.  The mouse on computer A was able to keep going rightwards, past the right edge of the computer A display, and move across onto the monitor for computer B and do things there.  The keyboard was still going where my KVM set it, so I unplugged it from the KVM and plugged it directly into the computer.  Wow, just like that, the monitor that I selected with the mouse was also the monitor where the keyboard was active.  If I moved the mouse to the monitor that was plugged into computer A, I had a keyboard on computer A.  If I moved the mouse over to computer B's monitor, I had a keyboard there instead.  Basically, a mouse-controlled KVM.

To get adjusted to this new arrangement, I unplugged and rearranged mice and keyboards and rebooted both machines.  Now, suddenly, computer B was unable to go online.  It had been fine until now.  I disabled Input Director and rebooted.  The disabling was not persistent; ID was back.  I uninstalled Input Director and rebooted again.  Now, for a moment there, my customized Start Menu was broken.  I still was not able to go online.  Unfortunately, I now discovered that System Restore had somehow gotten turned off -- on computer B only, despite having set it up from a mirror of computer A, where System Restore was still working -- so I had to restore an image of computer B.  While nothing is certain, these problems were new.  They seemed likely to be due to Input Director.  As soon as the mirror was restored, I uninstalled ID.  The problems did not recur in the next 24 hours of fairly intensive work, so it looked like ID was the culprit.

Without Input Director, I hoped that something of my multiple desktop vision would remain.  From my understanding of TeamViewer, it did not seem that I would have the option of switching my two computers and two monitors back and forth between dedicated and dual-monitor formats.  But maybe I still could, with a KVM.  To investigate that, I had to get TeamViewer working first.  I installed and ran it on both computers A and B.  It started with a dialog that gave me a Remote Control tab containing a session ID.  I typed the session ID appearing onscreen in computer A into the dialog box on computer B and chose the Remote Control option.  It said, "You have entered the ID of your own computer."  Well, that was true.  Both machines were showing the same ID.  So apparently I was not doing this right.  But there did not seem to be an alternative.

I stepped back and reviwed the concept.  I wanted to use computer A to control either computer A or B.  This, again, was to be a KVM-type solution without using a KVM.  Instead of switching between computers (e.g., changing the focus of my mouse and keyboard from computer A to computer B) by hitting a hotkey or physical button linked to the KVM, I would switch between computers by clicking on a button onscreen or by hitting a hotkey linked to Teamviewer via the network cable.  In this way, I would not need the KVM.  But I was not sure TeamViewer was ready to play this game.  The solution, someone said, was to click on Extras, at the top-right corner of the first Teamviewer dialog, and go into Options > General tab > Incoming LAN connections > accept.

Instead of doing that, at this point I decided that I was already getting the functionality I needed for the time being.  Hence, I decided to shelve this project until later.  The KVM situation was acceptable.  GoodSync had recently begun to provide much of what I had thought I wanted from Teamviewer.  Also, that brief taste of Input Director had caught my attention.  That seemed to be the next step forward in this area.  The Teamviewer concept, or an alternative, seemed to be something that I should review later, after I had some experience with this setup, and after waiting a bit for possible improvements to Input Director or for good alternatives to it.

Windows 7: Multiple Monitors, Multiple Computers: Possibilities

I planned to be using Windows 7 on two computers.  At the start, I had two monitors, each dedicated to its own computer.  I wondered if I could set up the system so that I could use both monitors for computer A, and could also use both monitors for computer B.  I also wondered if I could use monitor A to see what was happening on both computers A and B at the same instant.

My first search led to ads for KVM switches, but that wasn't what I wanted.  I did look into KVM switches at Newegg, just in case someone had invented a switch that would do everything.  But then realized I wasn't going to read through all those product descriptions to see if any of them had the possibilities I wanted.  A different search got closer to what I wanted.  Actually, it went well beyond it.  There were possibilities I hadn't even imagined.

One possibility was that of Synergy, which had originally been Synergy and then became Synergy-Plus and was now back to being Synergy.  It looked like the Synergy concept ws that I could have two or more computers, each having its own monitor, and I could have just one keyboard and one mouse, and would move among these computers simply by moving the mouse to the left or right, until it left one monitor and then appeared on the next.  No KVM switch; just move the mouse to switch computers.  The connection was by ethernet -- just get all computers on the same network.  They said you could also copy and paste between the computers.  But apparently Synergy wasn't entirely stable yet; that was their stated goal for 2012. For that reason, I decided I would prefer a KVM for now, if necessary.  Presumably a problem with the network would render all computers other than the server (i.e., the one to which the keyboard and mouse were connected) unavailable.  Bruce Tyson pointed out that there would also be a problem if the user wanted to access the BIOS of a slave or client computer during bootup.  It seemed like it might be a good idea to have a spare keyboard and mouse handy.  Another possibility:  Input Director.  This Windows-specific freeware application seemed to have the same concept as Synergy.  These sorts of programs seemed to have the same idea as a KVM switch that would allow one keyboard (e.g., that on a laptop) to take control of another computer even if it did have its own keyboard and mouse.

Bruce Tyson also pointed me toward web-based sharing services, Virtual Network Computing (VNC), and remote desktop software.  These apparently all were, or could be, variations of "headless" computing, where the keyboard, video, and mouse (KVM) are all connected to just one computer, which is then linked to others whose contents may display on that monitor.  He also noted that some monitors have dual inputs, which could be plugged into separate computers, but that the user would have to switch between them using buttons on the monitor.  That would prevent simultaneous viewing of two computers and would also be klunky in daily use.

It seemed that GoToMyPC.com was one of the leading web-based services.  But when I looked into it, these appeared to be simply ways of accessing the computer remotely.  At $10/month or more, it was pricey.  LogMeIn and others seemed to offer good free alternatives.  I decided I didn't want a web-based service, even if it did exactly what I wanted, because it would be relatively slow and it would be vulnerable to anything that might go wrong with the modem, the network connection, etc.

According to Wikipedia, VNC was both platform-independent and remote-capable, and some versions were "optimised for Microsoft Windows."  A list of versions indicated that UltraVNC (free) was the most advanced mainstream version and was the basis for several others.  Current alternatives for connecting a few Windows PCs included EchoVNC (free), RealVNC (free+), SmartCode VNC Manager ($129+), SupportAnyPC ($149), TeamViewer (free), and TightVNC (free).  Among these, a RealVNC feature comparison page indicated that its free version was not compatible with Windows 7.  Wikipedia pages for the free versions indicated that RealVNC was similar to UltraVNC, but the latter had more features; EchoVNC differed from UltraVNC in being more firewall-friendly; Teamviewer was mostly for remote control of computers; and TightVNC likewise had spun off a firewall-friendly variant, RemoteVNC ($25 per computer), among others.  A Wikipedia comparison page, only in it formative stages at this point, named Skype, TigerVNC, and xpra as other free Windows-compatible remote desktop programs.  The Wikipedia pages just linked for those additions indicated that TigerVNC was a fork of RealVNC; that Skype was (of course) primarily for VoIP; and that xpra (currently a beta product) used an approach that differed from that of VNC; but it later looked like xpra was not for Windows.  For my purposes, the survivors of this discussion were EchoVNC, TigerVNC, TightVNC, and UltraVNC.

I looked at a Wikipedia page showing a comparison of Java remote desktop projects. I was not sure what this was about. The project that seemed most feature-rich at this point was WallCooler VPN, so I looked into that. This actually led to a page for Vedivi, which seemed to be in the business of giving people access to remote computers at a low monthly price.

Eventually I figured out that there are many remote desktop protocols.  VNC was one; Remote Desktop Protocol (RDP) was a Windows-specific alternative.  There were others.  I eventually found a chart that, although officially for Mac, pulled together some of this.  Revisting the Synergy and Input Director webpages (above), I saw that Synergy was not a VNC project; I was not clear what type it was, and likewise for Input Director.  Supposedly Microsoft's own version of RDP was currently called Remote Desktop Services, previously Terminal Services; but when I went looking for it, I wound up in Remote Desktop Connection (RDC).  A search led me to a description that sounded like what I was looking for.  I wondered why someone would have bothered creating Input Director, with its Windows orientation, if this feature already existed in RDC.  I decided to start by trying to use RDC, to see what would happen.  That would be the subject of another post.

Two Computers: Dividing the Workload

In this post, as part of my New Year's housecleaning, I introduce several investigations, involving various ways of setting up two computers in a workspace.

*  *  *  *  *

KVMs and Monitor-Sharing Options

I had developed the habit of working with two computers, using a KVM switch so I needed only one mouse and keyboard.  A KVM switch would let me use just one monitor with two computers:  it would be showing me what was happening on the computer that the mouse and keyboard were then connected to.

I had two monitors.  I didn't have them connected to the KVM.  Instead, I connected them directly to the two computers, one for each.  So the KVM switch would have me working on computer A or computer B, but monitor A would continue to show what was happening on computer A, and monitor B would continue to display the state of things on computer B.

Actually, one KVM had started malfunctioning, and I had replaced it with another.  In the process, I decided to disconnect the mouse from the KVM too.  So now the KVM just controlled the keyboard.  It made sense:  the keyboard was big.  I couldn't fit two keyboards on my desktop.  But I could fit two mice.  Mouse A, on the left side, was controlled by my left hand, and was controlling computer A, while mouse B was preoccupied with computer B on my right.  I wasn't sure if I liked this arrangement.  It had its advantages.  It gave my hands a more equal workout.  I could glance over at the other computer and click something, to make some process move ahead, without having to hit ScrollLock twice, which was how the KVM switched the keyboard back and forth.  The main problem was that it was hard to tell which computer the keyboard was controlling at any given time.  I was still occasionally hitting the Del key and deleting things on computer A and wondering why they weren't disappearing from monitor B.  It was a bit nutty.  But I was adapting and, like I say, it had its advantages, at least until I worked out something better.

The monitor situation was OK, too.  I had widescreen monitors, so I was able to accommodate a couple of different open windows at the same time on each of them.  But there were times when it would have been helpful to have both monitors attuned to just one computer.  I had previously used an arrangement where monitor A was dedicated to computer A, but monitor B was connected to a second KVM switch, so I could reach up and punch the button and switch monitor B back and forth between computer A and computer B.  This would let me use a multiple monitor approach on computer A, so as to spread out my work.  The problem with this was that, when there was no monitor turned on to computer B, I tended not to use it.  That was a problem because the purpose of having two computers was to let me continue to work when one of them would crash or need maintenance or get involved in some process, like scanning or rendering, that would make it virtually unavailable for other purposes.  I also used this arrangement to write these blog posts, tinkering with one machine and recording the steps in the other.  I found that, if I got too fixated on one computer, the other one tended not to be organized and capable enough to take over when I needed it.

There didn't seem to be a way to share one monitor between two computers simultaneously, with computer B running in a little window in the corner -- a real "monitor" as distinct from a big display.  There was the option of buying a little display, connecting it to the second DVI connector on computer B, and putting it off to the side, so I would always have that information about what was happening on computer B.  But that little monitor would cost more than $100.  I could probably go down to Goodwill and pick up an old CRT for less than $10, but the other problem was that it would still be more clutter, more heat, more power consumption.  And the desk didn't have room for it, so it would have to go onto a side table or shelf or something.  I would also need a video card, since my motherboard only supported one monitor.

A decision on that question of how to use multiple monitors would await the outcome of an investigation of various non-KVM strategies.

*  *  *  *  *

Dual-Booting and Virtual Machines

Over the past couple of years, my two computers had different missions.  Computer A was running Windows XP in a VMware virtual machine on Ubuntu.  Computer B was running WinXP natively.  Now I was moving away from Ubuntu and back to Windows.  I had planned to just install Windows 7 on both.  I'd been having problems with my WinXP installation on computer B, even when I restored from an image, so it seemed like a good time to upgrade rather than continue to fight it.

I liked the idea of dual-booting WinXP and Win7.  Actually, though, I rarely used my dual-boot setups.  I pretty much always went with one or the other.  Right now, for instance, I already had a dual-boot Ubuntu and WinXP setup on computer B, but I couldn't remember the last time I had gone into Ubuntu there.

Meanwhile, on computer A, it seemed like I should consider just replacing Ubuntu with Win7:  continue to run WinXP in a virtual machine (VM), that is, but run it on Windows 7 instead of Ubuntu.  This would give me access to the familiar way of doing things in WinXP, while easing the transition to Win7.  I looked into the VM option in more detail.  It looked like I would be able to use the Windows version of VMware Workstation as long as I wasn't using my Workstation license in Ubuntu.  So the tentative plan was to have WinXP running in VMware on Win7 on one machine, while just running Windows (either XP or 7) natively (i.e., without a VM) on the other.

Although I was moving away from Ubuntu, it occurred to me that this strategy would leave a door open for a possible return to Ubuntu.  Ubuntu had been far more stable than WinXP.  Assuming the virtualization setup worked, I could install Ubuntu as a VM on Win7, essentially reversing what I had tried to do previously, and I could thus continue to identify projects and programs that Ubuntu could handle just as well as Windows for my purposes.

*  *  *  *  *

Differences Between Machines

The decisions described above meant that, contrary to my assumptions, I probably should not set up identical hardware on both computers.  Computer A was probably going to need more muscle to handle the VMs.  WinXP on computer B had been struggling to run video editing software, though that may have been due to a flawed installation.

Part of the tradeoff here was simplicity versus options.  The more operating systems and hardware arrangements I had in play, the more different ways I had of configuring things, and the more time it would take.  I had always viewed the computer hobbying as a means to an end of being more productive, while having its own intrinsic interest too, and for that reason I had tended to think, in recent years, in terms of getting myself set up for the next six months or a year.  During that kind of timeframe, the problems of a setup would tend to emerge and sometimes become overwhelming.  The current Windows XP installation was a case in point.  I had been able to nurse it along despite its obvious dysfunctionality, occasionally replacing its current state with an Acronis image backup, but it was now crashing one or more times per day.  So, oddly, in this case it was the simpler installation that had become the more problematic.

The switch from Windows XP to Windows 7 probably meant that I would be spending quite a bit of time getting up to speed on the best way to configure the latter.  I was probably going to install it in a RAID array, for purposes of performance, with an external backup option.  There would be some things to figure out and play with.  Most likely, some hardware would be getting shuffled around.  So, contrary to my first thoughts during this particular housecleaning, it did not appear likely that the two computers would take on any clear definition:  they would not be mirror images of one another, in hardware terms, so as to simplify maintenance, and they would also not feature one being considerably more powerful than the other.  The plan for the coming six months to a year was just to make them both capable and to explore options without investing more time than I wanted to spare for this kind of project.

Since I was now in a period of computer housecleaning, it seemed likely that my posts over the next few weeks would explore these considerations in more detail.