Wiring DRM into the system

Wiring DRM into the system

Never ascribe to conspiracy what is adequately explained by routine incompetence.

I had a laptop (Thinkpad A30P) for some years with an ATI Rage Mobility chipset. One day, the laptop broke. It was sent to an authorized IBM repair facility, which was paid a flat rate of $85 to fix the machine. Of course, CDN$85 doesn't buy a lot of highly skilled labor, so instead of doing proper diagnostics and fixing the real problem, they replaced the motherboard, display, case screws, and one or two other parts that broke in the shop. New BIOS firmware came along for the ride.

Before that day, I could play video through Xv overlay on both LCD and external CRT (indeed, I was actually watching a video this way when the failure occurred that caused me to return the laptop). When the laptop came back, I could no longer do this.

No changes to the software on the system occurred during that time (no such change could occur, since I kept the hard disk when I returned the laptop, and reinstalled it into the laptop when it came back--something I always do with laptop repairs since many vendors insist on running Windows software to run self-tests).

There were a number of changes on the motherboard (I had to upgrade the kernel's IDE driver to be able to use APM suspend and resume again), and several other quirky Xv behaviors changed (e.g. if the external CRT is used, its resolution didn't match the LCD, and you try to use Xv, there were different bugs after the repair than before).

The machine also had a rather annoying habit of putting the CRT in what looks like the VGA equivalent of Macrovision mode--random horizontal displacements between the start of video signal and the hsync pulse, which could only be cured by a suspend/resume cycle. This problem was present on the laptop from day one, and is still present now--it could be a genuine bug.

All of this could just be due to unintentional changes in the BIOS--since the driver is ATI and the power management is APM, a _lot_ of what the video subsystem does is specified by the BIOS, and there's a really good reason why IBM doesn't recommend users upgrade the BIOS unless they have specific problems--namely, that BIOS upgrades from IBM are more risky in terms of introducing new show-stopping problems than Linux 2.6.X-rcY kernels. There was a BIOS upgrade which broke 80x60 text mode (black screen on LCD), for example. Another BIOS upgrade intentionally changed the programming of the video chips to make less audible noise from the power supply (I'm not making this up--it's in the release notes from IBM), and a third BIOS upgrade started making noises from the Ethernet controller.