http://bugs.freedesktop.org/show_bug.cgi?id=10418
------- Comment #31 from [EMAIL PROTECTED] 2007-10-04 07:13 PST ------- (In reply to comment #30) > > right now I'm using a 1600x1200 external panel, which afaik can be driven > > single link (as I've been using it on my single-link mac mini as well :-) > Right. I saw your log after I replied. that should be single link. It's > probably a different TMDS chip. If you have an sil chip, try reading back the > values from 0x00 and 0x02. Those are the vendor and device ids for the chip. well, reading back those registers, I get what's expected for the vendor and device id according to the sil164 data-sheet: (II) RADEON(0): HVR: reg 00 = 01 (II) RADEON(0): HVR: reg 01 = 00 (II) RADEON(0): HVR: reg 02 = 06 (II) RADEON(0): HVR: reg 03 = 00 (II) RADEON(0): HVR: reg 04 = 00 (II) RADEON(0): HVR: reg 05 = 00 (II) RADEON(0): HVR: reg 06 = 19 (II) RADEON(0): HVR: reg 07 = a5 (II) RADEON(0): HVR: reg 08 = 33 (II) RADEON(0): HVR: reg 09 = 34 (II) RADEON(0): HVR: reg 0a = 80 (II) RADEON(0): HVR: reg 0b = 00 (II) RADEON(0): HVR: reg 0c = c9 (II) RADEON(0): HVR: reg 0d = 70 (II) RADEON(0): HVR: reg 0e = 01 (II) RADEON(0): HVR: reg 0f = 4c > you can find links to a bunch of sil and other TMDS chip databooks here: > http://wiki.x.org/wiki/DataSheets thx 4 the pointer > It also may be an ordering issue. The sil164, you need to set up the chip > properly before setting the enable bit (bit 0 IIRC) in 0x08. right now I'm using the following intialization sequence, which does set the enable bit only after everything else as been set: + RADEONDVOWriteByte(radeon_output->DVOChip, 0x08, 0x32); + RADEONDVOWriteByte(radeon_output->DVOChip, 0x09, 0x34); + RADEONDVOWriteByte(radeon_output->DVOChip, 0x0a, 0x80); + RADEONDVOWriteByte(radeon_output->DVOChip, 0x0c, 0xc9); + RADEONDVOWriteByte(radeon_output->DVOChip, 0x0d, 0x70); + RADEONDVOWriteByte(radeon_output->DVOChip, 0x0e, 0x01); + RADEONDVOWriteByte(radeon_output->DVOChip, 0x0f, 0x4c); + RADEONDVOWriteByte(radeon_output->DVOChip, 0x08, 0x33); btw, I've noticed an interesting behaviour with the radeon driver using the code above when going to sleep by "pbbcmd sleep" (I need so switch to a text-vt before doing so, otherwise when doing this from within X11 the powerbook will perform some kind of power-off... I'm not sure yet, whether to file this against Xorg or rather against the linux kernel :-/); anyway there are two scenarios: a) going to sleep with Xorg running -> ok 1. switching from DVI dual-head Xorg session to text VT 2. pbbcmd sleep 3. waking up again 4. switching back to Xorg session -> external DVI output still fine b) going to sleep without Xorg running -> not ok 1. terminating working dual-head Xorg session and switch to text VT 2. pbbcmd sleep 3. waking up again 4. starting new Xorg session -> external DVI output still fine ...seems as if Xorg is able to restore some setup/initialization it saved before going to sleep? > > ...except that it doesn't compile (the #defined constants are missing) :-) > Fixed now in git. I'll try that soon -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. _______________________________________________ xorg-driver-ati mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-driver-ati
