Wiring DRM into the system [LWN.net]

Wiring DRM into the system

Posted Aug 4, 2005 14:56 UTC (Thu) by dmantione (guest, #4640)
In reply to: Wiring DRM into the system by tialaramex
Parent article: Wiring DRM into the system

Here is a confirmation and further explanation from ATI hardware (I have
the driver DDK's):

Both old Mach64 based hardware (Rage LT pro, Rage Mobility) and modern
Radeon based hardware (Radeon) do have two CRT controllers. Both the LCD
panel and the external CRT display connector can be assigned to one of
them, you can both assign to the first, both to the second, or one on
each CRT controller.

On Mach64 hardware, only the first CRTC has access to the hardware
overlay. On Radeon hardware, both CRT controllers can use the overlay.
Unfortunately, on Mach64 hardware, only the first CRTC can do display
strecthing, necessary to run the laptop panel into something other than
its native resolution.

So, it makes sense to assign the first CRTC to the laptop panel. Now, you
can assign your external monitor to the first monitor, but then it needs
to run the same resolution and refresh rate as your LCD panel. You can
assign it to the second CRTC, so you can change the resolution, but then
you loose access to the overlay.

The newer versions of the Mach64 Windows drivers give you the choice if
you want to use one or two CRTC's. On the Radeon this choice is still
there, but both CRTC's can use the overlay.

(Log in to post comments)

Wiring DRM into the system

Posted Aug 6, 2005 6:22 UTC (Sat) by zblaxell (subscriber, #26385) [Link]

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.

Wiring DRM into the system

Posted Aug 6, 2005 11:16 UTC (Sat) by dmantione (guest, #4640) [Link]

It is possible that the new video card, with new BIOS puts the chip into
two CRTC mode. That should be solvable by using the atyfb framebuffer
driver. You need a kernel version that includes my LCD support patches,
recent 2.4 and 2.6 ones do.

It will put the chip into single CRTC mode (because the framebuffer layer
hardly can handle multiple CRTC's) and should thus allow display Xv on
both displays.

If there's still trouble with that driver loaded (even if you are running
X), I'd like to hear, allthough I'm no longer capable to debug myself as
my Mach64 based laptop has died some time ago.