Wiring DRM into the system [LWN.net]

Wiring DRM into the system

Posted Aug 4, 2005 13:38 UTC (Thu) by tialaramex (subscriber, #21167)
In reply to: Wiring DRM into the system by kh
Parent article: Wiring DRM into the system

The hardware manufacturer is right, here's what's going on and there's no DRM or secret handshakes or anything...

The modern hardware has effectively two DACs to drive two separate devices, this allows it to run at say 800x600 for a cheap VGA projector while also offering 1024x768 on the main LCD screen. Now the YUV overlay used to accelerate video playback performance is normally connected to the DAC and so it cannot overlay onto two different surfaces at once. Another part would have to be added (more expense, more heat) to "fix" this. Hence if you want the acceleration (and most DVD software does) you can only see DVDs on one of the two output devices.

As to why the older laptop can do it, well first note that the newer laptop CAN display a DVD to both outputs, you just need to use software which doesn't require the accelerated YUV overlay. You may be able to switch this off in the existing software (it's easy in mplayer for example). This will probably run the CPU very hard if you make the DVD fullscreen, but there you are, that's why they added the accelerated overlay hardware... Anyway, the older laptop either happens to have two copies of the overlay hardware (unlikely) or it doesn't have such hardware at all, always relying on CPU power. Does it get pretty hot and maybe "chug" a little bit when playing DVD fullscreen on both outputs?

(Log in to post comments)

Wiring DRM into the system

Posted Aug 4, 2005 14:56 UTC (Thu) by dmantione (guest, #4640) [Link]

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.

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.