July 2008 - Radeon HD - openSUSE Mailing Lists

[Bug 16400] New: Gamma of white+grey is wrong (all seems like white)
by bugzilla-daemon＠freedesktop.org 29 Aug '08

29 Aug '08

http://bugs.freedesktop.org/show_bug.cgi?id=16400 Summary: Gamma of white+grey is wrong (all seems like white) Product: xorg Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/radeonhd AssignedTo: lverhaegen(a)suse.de ReportedBy: patrick.matthaei(a)web.de QAContact: xorg-team(a)lists.x.org Hello, as explained in IRC I've got problems with my Sapphire X1650Pro card. I'm using the latest git master and this problem doesn't occur on my laptop (X1250). The "color" grey seems like white so on I can't figure out many things correctly on my TFT. I attached a screenshot (if I take a screenshot of it there it's all normal) and marked some points with comments. I hope it will be enough if I quote the irc log here: <the-me> libv, hm no, I try to explain it :) on my desktop (it doesnt occur on my notebook) with my x1650 pro from sapphire the white has a very big brightness, also grey, too. now for example at kde I can't see any differences between white and grey "colors". I would like to show you it but if I took a screenshot it seems normal again. with my tft setup everything is fine and I also tried to tune it so that it looks normal again :( <the-me> both setups are based on debian sid with radeonhd git master <libv> the-me: have you played with xgamma? <the-me> hmm never played with. at the moment every value eq 1.000 <the-me> ah: if I start it with fglrx for example everything is fine again (or vesa) - it just occurs with radeonhd <libv> the-me: can you play with xgamma, and if this doesn't fully solve the issue file a bug? <the-me> libv, hm okay also not very usefull (like tuning my tft itself). I created a screenshot on the box and added some comments on it - would be nice if you would have a look first on it (not so easy to explain it in english *grml*) ;) <the-me> libv, ok here is the screenshot: (***SEE ATTACHMENT***) to the comment numbers: #1: the font is just an little little bit grey, nearly unreadable. #2: the color of the lower and upper arrow are nearly the same (white). #3: unable to see this grey breaking line #4: same like #2 and #3 but there I can see an little little difference between both :) <libv> the-me: is this on tmds or on the dac? <libv> the-me: is this a digitally connected monitor, or is it connected to analog? <the-me> ah. this graphic board just has two digitally connector. there's such a digital -> analog plug after that and then the tft is plugged about a vga cable to it <libv> right, so a dac <libv> find out which dac from the log, DACA or DACB <the-me> libv, http://nopaste.linux-dev.org/?615 Okay right now here are the results: Is it DACA or DACB?: ==================== # grep -i dac /var/log/Xorg.0.log (II) RADEONHD(0): Connector[0] {RHD_CONNECTOR_DVI, "DVI-I CRT1 DFP3", RHD_DDC_0, RHD_HPD_1, { RHD_OUTPUT_DACA, RHD_OUTPUT_LVTMA } } (II) RADEONHD(0): Connector[1] {RHD_CONNECTOR_TV, "SVIDEO TV1", RHD_DDC_NONE, RHD_HPD_NONE, { RHD_OUTPUT_DACB, RHD_OUTPUT_NONE } } (II) RADEONHD(0): Connector[2] {RHD_CONNECTOR_DVI, "DVI-I DFP1 CRT2", RHD_DDC_1, RHD_HPD_0, { RHD_OUTPUT_TMDSA, RHD_OUTPUT_DACB } } (--) RADEONHD(0): Attaching Output DAC A to Connector DVI-I 1 (--) RADEONHD(0): Attaching Output DAC B to Connector TV SVIDEO (--) RADEONHD(0): Attaching Output DAC B to Connector DVI-I 2 (II) RADEONHD(0): RandR: Adding RRoutput DVI-I_1/analog for Output DAC A (II) RADEONHD(0): RandR: Adding RRoutput TV_SVIDEO for Output DAC B (II) RADEONHD(0): RandR: Adding RRoutput DVI-I_2/analog for Output DAC B (II) RADEONHD(0): DAC B: Sensed Output: VGA (II) Loading sub module "ramdac" (II) LoadModule: "ramdac"(II) Module "ramdac" already built-in (WW) RADEONHD(0): RandR: While switching off TV_SVIDEO: output DAC B is also used by DVI-I_2/analog - ignoring (WW) RADEONHD(0): RandR: While switching off TV_SVIDEO: output DAC B is also used by DVI-I_2/analog - ignoring (WW) RADEONHD(0): RandR: While switching off TV_SVIDEO: output DAC B is also used by DVI-I_2/analog - ignoring (WW) RADEONHD(0): RandR: While switching off TV_SVIDEO: output DAC B is also used by DVI-I_2/analog - ignoring rhd_dump output with radeonhd: ============================== exez:/usr/src/xf86-video-radeonhd/utils/conntest# ./rhd_dump -r 7A00,7A70 05:00.0 rhd_dump: v1.2.1, git branch master, commit 1f65f354 0x7A00: 0x00000001 0x7A04: 0x00000000 0x7A08: 0x00000000 0x7A0C: 0x00000000 0x7A10: 0x3FFFFFFF 0x7A14: 0x0000003F 0x7A18: 0x3FFFFFFF 0x7A1C: 0x0000003F 0x7A20: 0x00000000 0x7A24: 0x00000000 0x7A28: 0x00070000 0x7A2C: 0x0000000B 0x7A30: 0x00000000 0x7A34: 0x02020200 0x7A38: 0x00000000 0x7A3C: 0x00000000 0x7A40: 0x00000000 0x7A44: 0x00000000 0x7A48: 0x00000000 0x7A4C: 0x00000000 0x7A50: 0x00000000 0x7A54: 0x00050602 0x7A58: 0x00000000 0x7A5C: 0x00000000 0x7A60: 0x00000000 0x7A64: 0x00000000 0x7A68: 0x00000002 0x7A6C: 0x00000000 0x7A70: 0x00000000 rhd_dump output with vesa: ========================== exez:/usr/src/xf86-video-radeonhd/utils/conntest# ./rhd_dump -r 7A00,7A70 05:00.0 rhd_dump: v1.2.1, git branch master, commit 1f65f354 0x7A00: 0x00000001 0x7A04: 0x00000000 0x7A08: 0x00000000 0x7A0C: 0x00000000 0x7A10: 0x3FFFFFFF 0x7A14: 0x0000003F 0x7A18: 0x3FFFFFFF 0x7A1C: 0x0000003F 0x7A20: 0x00000000 0x7A24: 0x00000000 0x7A28: 0x00070000 0x7A2C: 0x0000000B 0x7A30: 0x00000000 0x7A34: 0x02020200 0x7A38: 0x00000000 0x7A3C: 0x00000000 0x7A40: 0x00000000 0x7A44: 0x00000000 0x7A48: 0x00000000 0x7A4C: 0x00000000 0x7A50: 0x00000000 0x7A54: 0x00051002 0x7A58: 0x00000000 0x7A5C: 0x00000000 0x7A60: 0x00000000 0x7A64: 0x00000000 0x7A68: 0x00000002 0x7A6C: 0x00000000 0x7A70: 0x00000000 How you can see, the only option which is different from vesa is 0x7A54 => 0x00050602 (radeonhd) vs. 0x00051002 (vesa). :) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. _______________________________________________ xorg-team mailing list xorg-team(a)lists.x.org http://lists.x.org/mailman/listinfo/xorg-team -- To unsubscribe, e-mail: radeonhd+unsubscribe(a)opensuse.org For additional commands, e-mail: radeonhd+help(a)opensuse.org

1 10

Re: [radeonhd] 0x9591: A new device ID for a radeon HD 3650
by Egbert Eich 21 Aug '08

21 Aug '08

Egbert Eich writes: > Michel Ganguin writes: > > Hi, > > I have a radeon HD 3650 with pciid 1002:9591 as Ilyes Gouta. > > > > I tried to start X with latest radeonhd git sources, but no success (no > > device found). > > > > I added 9591 to rhd_id.c (with RV635, lspci reports rv635 for hdmi audio > > but only HD 3650 for graphic card). X started, but there is only a white > > screen with some vertical colored lines (~1/3 of the screen), without > > any reaction when moving mouse. The shell comes back to normal when > > killing X. > > > > > > Unknown card detected: 0x9591:0x1043:0x1633 > > Radeon HD 3650 with 1024MB video ram on an ASUS laptop model M50SA > > > > What can i do, where can I try to tweak code, ...? > > > > Michael, > > can you dump me your BIOS, please? > > Thanks! Oh, and please also send a log file generated with '-logverbose 7'! Thanks! Cheers, Egbert. -- To unsubscribe, e-mail: radeonhd+unsubscribe(a)opensuse.org For additional commands, e-mail: radeonhd+help(a)opensuse.org

2 1

Re: [radeonhd] My Radeon card
by Egbert Eich 17 Aug '08

17 Aug '08

Thomas Vander Stichele writes: > Hi, > > > > This is really in 'interesting' configuration: > > > > You've got an HDMI port and a VGA port. > > The connector table lists the DAC2 and the TMDSA controller > > both being routed to the HDMI port (although HDMI doesn't > > handle analog signals). > > Instead the DAC2 signal is routed to the VGA connector. > > There it shares the DDC lien with the HDMI connector - but > > of course VGA doesn't do HPD. > > This of course is not covered by our logic. Let me rethink > > the logic. > > I did not understand any of what you said :) I assume that's not a > problem. Does this mean you will rework the patch ? Can I have hopes of > it landing at some point ? Yes, but some things need to be redesigned for that first. The easiest way to fix your problem at the moment would probably be to blacklist your HDMI connector as DMS59. The DMS59 connector has the same properties as your HDMI + VGA combination. I hope to get a patch out today. > > As a minor aside, last week I had one of the two connectors a little > loose. X refused to start on a reboot, asserting every time because the > config expected randr to find the second screen, and it didn't. Is that > expected behaviour ? This may be a side effect of your other problem. Cheers, Egbert. -- To unsubscribe, e-mail: radeonhd+unsubscribe(a)opensuse.org For additional commands, e-mail: radeonhd+help(a)opensuse.org

2 1

[Bug 15989] New: Using RanrR radeonhd driver passes wrong resolution information to applications
by bugzilla-daemon＠freedesktop.org 13 Aug '08

13 Aug '08

http://bugs.freedesktop.org/show_bug.cgi?id=15989 Summary: Using RanrR radeonhd driver passes wrong resolution information to applications Product: xorg Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/radeonhd AssignedTo: lverhaegen(a)suse.de ReportedBy: marcelo.magallon(a)gmail.com QAContact: xorg-team(a)lists.x.org Created an attachment (id=16600) --> (http://bugs.freedesktop.org/attachment.cgi?id=16600) Xorg.log file without a configuration file If I configure the radeon driver to use RandR, some applications like GDM and the GNOME panel don't occupy the full screen but a fraction of it. Looking at the log file I see: (II) RADEONHD(0): Output VGA_1 disconnected (II) RADEONHD(0): Output TV_SVIDEO disconnected (II) RADEONHD(0): Output DVI-D_1 connected (II) RADEONHD(0): Output DVI-D_2 connected (II) RADEONHD(0): Output DVI-D_1 using initial mode 1280x800 (II) RADEONHD(0): Output DVI-D_2 using initial mode 1680x1050 It's a RS690 as the log says. It's integrated in the motherboard. Physically the motherboard has two display connectors, one VGA, one DVI. The monitor is connected to the DVI output. The monitor resolution, as seen in the log file is 1680x1050. Problem: GDM behaves as if the display resolution was set to 1280x800. Furthermore, the output of xdpyinfo says the display resolution is in fact 1680x1050, but xrandr reports only up to 1280x800. Initially the GNOME panels are only 1280 pixels wide and the lower one is located at the "edge" of the 800 pixel tall display, but I can drag it to the lower edge of the monitor and it will expand to occupy the full 1680 pixels. If I disable RandR using the NoRandR option, everything behaves ok. Is this a problem in the radeonhd driver or a problem in GNOME? The problem is easy to reproduce for me, I can provide more information on request. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. _______________________________________________ xorg-team mailing list xorg-team(a)lists.x.org http://lists.x.org/mailman/listinfo/xorg-team -- To unsubscribe, e-mail: radeonhd+unsubscribe(a)opensuse.org For additional commands, e-mail: radeonhd+help(a)opensuse.org

1 19

0x94CC:0x1545:0x3650: <Radeonhd RV610 HD2400Pro>
by Tai Tri Nguyen 12 Aug '08

12 Aug '08

Hi Folks, I'm developing VGA for powerpc with Radeonhd RV610 HD2400Pro, but the Linux can't detect the card. Following the error recommendation, I contact you. Please help me. Here is some infos: root@sequoia:/var/log# vi Xorg.0.log [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0x7ffec000 - 0x7ffec000 (0x1) MX[B] [5] -1 0 0x7fff0000 - 0x7fff0000 (0x1) MX[B](B) [6] -1 0 0x80000000 - 0x80000000 (0x1) MX[B](B) [7] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [8] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [9] -1 0 0x0000ff00 - 0x0000ffff (0x100) IX[B](B) (II) resource ranges after probing: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0x7ffec000 - 0x7ffec000 (0x1) MX[B] [5] -1 0 0x7fff0000 - 0x7fff0000 (0x1) MX[B](B) [6] -1 0 0x80000000 - 0x80000000 (0x1) MX[B](B) [7] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [8] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [9] -1 0 0x0000ff00 - 0x0000ffff (0x100) IX[B](B) (==) RADEONHD(0): Depth 24, (--) framebuffer bpp 32 (**) RADEONHD(0): Selected ShadowFB. (II) RADEONHD(0): Unknown card detected: 0x94CC:0x1545:0x3650. If - and only if - your card does not work or does not work optimally please contact radeonhd(a)opensuse.org to help rectify this. Use the subject: 0x94CC:0x1545:0x3650: <name of board> and *please* describe the problems you are seeing in your message. (--) RADEONHD(0): Detected an RV610 on an unidentified card (II) RADEONHD(0): Mapped IO at 0x30020000 (size 0x00000001) (II) RADEONHD(0): Getting BIOS copy from legacy VBIOS location (EE) RADEONHD(0): rhdAtomGetTables: No AtomBios signature found (II) RADEONHD(0): Query for AtomBIOS Init: failed Backtrace: 0: X(xf86SigHandler+0x94) [0x10093f44] 1: [0x100474] 2: /usr/lib/xorg/modules/drivers//radeonhd_drv.so [0xf8f330c] 3: X(InitOutput+0xb08) [0x1006e2c8] 4: X(main+0x294) [0x1002e064] 5: /lib/libc.so.6 [0xfc72380] 6: /lib/libc.so.6 [0xfc725c4] Fatal server error: Caught signal 11. Server aborting - infomation from lspci: root@sequoia:/var/log# lspci -vv 00:0a.0 PCI bridge: PLX Technology, Inc. PEX 8111 PCI Express-to-PCI Bridge (rev 21) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 128 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 0000f000-0000ffff Memory behind bridge: 7ff00000-8fffffff Prefetchable memory behind bridge: 8ff00000-8fffffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR- BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B- Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0+,D1+,D2-,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [60] Express Unknown type IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s <64ns, L1 <1us Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- Device: MaxPayload 128 bytes, MaxReadReq 512 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 0 Link: Latency L0s <1us, L1 <16us Link: ASPM Disabled CommClk- ExtSynch- Link: Speed 2.5Gb/s, Width x1 Capabilities: [100] Unknown (4277) 01:00.0 VGA compatible controller: ATI Technologies Inc Unknown device 94cc (prog-if 00 [VGA]) Subsystem: VISIONTEK Unknown device 3650 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin A routed to IRQ 67 Region 0: Memory at 90000000 (64-bit, prefetchable) Region 2: Memory at <ignored> (64-bit, non-prefetchable) Region 4: I/O ports at ff00 [size=256] Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Express Legacy Endpoint IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag+ Device: Latency L0s <4us, L1 unlimited Device: AtnBtn- AtnInd- PwrInd- Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed 2.5Gb/s, Width x16, ASPM L0s L1, Port 0 Link: Latency L0s <64ns, L1 <1us Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch- Link: Speed 2.5Gb/s, Width x1 Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [100] Unknown (4098) Capabilities: [94c] Unknown (5445) Capabilities: [365] Unknown (13) 01:00.1 Audio device: ATI Technologies Inc Unknown device aa10 Subsystem: VISIONTEK Unknown device aa10 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin B routed to IRQ 67 Region 0: Memory at <ignored> (64-bit, non-prefetchable) Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Express Legacy Endpoint IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag+ Device: Latency L0s <4us, L1 unlimited Device: AtnBtn- AtnInd- PwrInd- Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed 2.5Gb/s, Width x16, ASPM L0s L1, Port 0 Link: Latency L0s <64ns, L1 <1us Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch- Link: Speed 2.5Gb/s, Width x1 Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [100] Unknown (4098) Capabilities: [aa1] Unknown (32768) - infos from dmesg: root@sequoia:/var/log# dmesg Linux version 2.6.25.7 (root@hcmlab-sw3) (gcc version 4.2.2) #5 Wed Jul 23 13:19:49 ICT 2008 AMCC PowerPC 440EPx Sequoia Platform Entering add_active_range(0, 0, 65535) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 65535 Normal 65535 -> 65535 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0 -> 65535 On node 0 totalpages: 65535 DMA zone: 511 pages used for memmap DMA zone: 0 pages reserved DMA zone: 65024 pages, LIFO batch:15 Normal zone: 0 pages used for memmap Movable zone: 0 pages used for memmap Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024 Kernel command line: root=/dev/nfs rw nfsroot=10.38.6.3:/opt/ubuntu-6.10 ip=10.38.6.141:10.38.6.3:10.38.4.1:255.255.252.0:sequoia:eth0:off panic=1 console=tty0 console=ttyS0,115200 PID hash table entries: 1024 (order: 10, 4096 bytes) Console: colour dummy device 80x25 console [tty0] enabled console [ttyS0] enabled Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 255872k available (2712k kernel code, 884k data, 156k init, 0k highmem) Calibrating delay loop... 989.18 BogoMIPS (lpj=1978368) Mount-cache hash table entries: 512 net_namespace: 440 bytes NET: Registered protocol family 16 PCI: Probing PCI hardware PCI: Cannot allocate resource region 1 of PCI bridge 1 PCI: Cannot allocate resource region 2 of PCI bridge 1 PCI: bridge 1 resource 2 moved to 8ff00000..8fffffff PCI: Cannot allocate resource region 0 of device 0000:01:00.0 PCI: Cannot allocate resource region 2 of device 0000:01:00.0 PCI: Cannot allocate resource region 0 of device 0000:01:00.1 PCI: Failed to allocate mem resource #0:10000000@90000000 for 0000:01:00.0 PCI: Failed to allocate mem resource #2:10000@0 for 0000:01:00.0 PCI: Failed to allocate mem resource #0:4000@0 for 0000:01:00.1 SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb NET: Registered protocol family 2 IP route cache hash table entries: 2048 (order: 1, 8192 bytes) TCP established hash table entries: 8192 (order: 4, 65536 bytes) TCP bind hash table entries: 8192 (order: 3, 32768 bytes) TCP: Hash tables configured (established 8192 bind 8192) TCP reno registered JFFS2 version 2.2. (NAND) Â© 2001-2006 Red Hat, Inc. io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) [drm] Initialized drm 1.1.0 20060810 Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled serial8250: ttyS0 at MMIO 0x0 (irq = 0) is a 16550A serial8250: ttyS1 at MMIO 0x0 (irq = 1) is a 16550A serial8250: ttyS2 at MMIO 0x0 (irq = 35) is a 16550A serial8250: ttyS3 at MMIO 0x0 (irq = 36) is a 16550A brd: module loaded PPC 4xx OCP EMAC driver, version 3.54 mal0: initialized, 2 TX channels, 2 RX channels rgmii0: input 0 in RGMII mode eth0: emac0, MAC 00:10:ec:00:ee:73 eth0: found Marvell 88E1111 Ethernet PHY (0x00) rgmii0: input 1 in RGMII mode eth1: emac1, MAC 00:00:00:00:00:00 eth1: found Marvell 88E1111 Ethernet PHY (0x01) Uniform Multi-Platform E-IDE driver ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx Driver 'sd' needs updating - please use bus_type methods physmap platform flash device: 04000000 at fc000000 physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank Amd/Fujitsu Extended Query Table at 0x0040 physmap-flash.0: CFI does not contain boot bank location. Assuming top. number of CFI chips: 1 cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness. RedBoot partition parsing not available Using physmap partition information Creating 5 MTD partitions on "physmap-flash.0": 0x00000000-0x00180000 : "kernel" 0x00180000-0x00400000 : "root" 0x00400000-0x03f60000 : "user" 0x03f60000-0x03fa0000 : "env" 0x03fa0000-0x04000000 : "u-boot" NDFC NAND Driver initialized. Chip-Rev: 0x00000110 NAND device: Manufacturer ID: 0x20, Chip ID: 0x75 (ST Micro NAND 32MiB 3,3V 8-bit) Scanning device for bad blocks Bad eraseblock 186 at 0x002e8000 Number of partitions 1 Creating 1 MTD partitions on "NAND 32MiB 3,3V 8-bit": 0x00000000-0x02000000 : "content" ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver ppc-soc-ohci ppc-soc-ohci.0: USB Host Controller ppc-soc-ohci ppc-soc-ohci.0: new USB bus registered, assigned bus number 1 ppc-soc-ohci ppc-soc-ohci.0: irq 21, io mem 0xe0000400 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected Initializing USB Mass Storage driver... usb 1-1: new low speed USB device using ppc-soc-ohci and address 2 usb 1-1: configuration #1 chosen from 1 choice usbcore: registered new interface driver usb-storage USB Mass Storage support registered. mice: PS/2 mouse device common for all mice i2c /dev entries driver IBM IIC driver v2.1 ibm-iic0: using standard (100 kHz) mode ibm-iic1: using standard (100 kHz) mode ad7414 0-0048: chip found, driver version 0.1 input: DELL DELL USB Keyboard as /class/input/input0 usbcore: registered new interface driver usbkbd drivers/hid/usbhid/usbkbd.c: :USB HID Boot Protocol keyboard driver TCP cubic registered NET: Registered protocol family 1 NET: Registered protocol family 17 RPC: Registered udp transport module. RPC: Registered tcp transport module. eth0: interrupt coalescing (RX:count=8 time=1000, TX:count=8 time=1000) eth0: link is down IP-Config: Complete: device=eth0, addr=10.38.6.141, mask=255.255.252.0, gw=10.38.4.1, host=sequoia, domain=, nis-domain=(none), bootserver=10.38.6.3, rootserver=10.38.6.3, rootpath= Looking up port of RPC 100003/2 on 10.38.6.3 eth0: link is up, 1000 FDX, pause enabled Looking up port of RPC 100005/1 on 10.38.6.3 VFS: Mounted root (nfs filesystem). Freeing unused kernel memory: 156k init Thank you and hope to contact you soon Tai Nguyen VDC Software Team -------------------------------------------------------- CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and contains information that is confidential and proprietary to Applied Micro Circuits Corporation or its subsidiaries. It is to be used solely for the purpose of furthering the parties' business relationship. All unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. -- To unsubscribe, e-mail: radeonhd+unsubscribe(a)opensuse.org For additional commands, e-mail: radeonhd+help(a)opensuse.org

3 6

Re: [radeonhd] GA-MA78G-DS3H (780G) - situation?
by Egbert Eich 09 Aug '08

09 Aug '08

Dexter Filmore writes: > Someone said it in May won't even work properly with fglrx. > Has anyone any experience with this board? > What about VGA signal quality? I've got the GA-MA78GM-S2H which is working great here. >From the connectors of both boards are identical. Hard to say how good the quality of the VGA output is, really. I've tested it mostly with panels and there (after going thru a DAC and an ADC) the result on the screen doesn't show the dynamics of DVI but it's impossible to see how edges are smeared out: the signal for a single pixel is either trivially mapped to a discrete pixel on the screen or is smeared out by the stretching electronics already. Cheers, Egbert. -- To unsubscribe, e-mail: radeonhd+unsubscribe(a)opensuse.org For additional commands, e-mail: radeonhd+help(a)opensuse.org

2 1

Re: [radeonhd] Non-DRI build broken by 2cc9378e ("DRI/2D: Fix build for --disable-dri.")
by Egbert Eich 06 Aug '08

06 Aug '08

Hans Ulrich Niedermann writes: > Hi, > > 2cc9378e contains changes like the following > > -#include "rhd_dri.h" > -#include "rhd_cp.h" > +#ifdef USE_DRI > +# include "rhd_dri.h" > +# include "rhd_cp.h" > +#else > +typedef CARD8 uint8_t; > +typedef CARD16 uint16_t; > +typedef CARD32 uint32_t; > +#endif > > without checking that uintNN_t are actually undefined. > > This makes a build after "configure --disable-dri" fail as > follows (on my Fedora 9 system), just like IRC user "rbmorse" > reported about his system: > > src/radeon_accel.c:67: error: conflicting types for 'uint32_t' > /usr/include/stdint.h:52: error: previous declaration of 'uint32_t' was here > > Egbert, for what kinds of systems were those typedefs required, > and could there be a different way to define uintNN_t for these > systems? Honestly I don't know. I've checked the header file which normally includes /usr/include/stdint.h. It does quite some voodoo to find out on which system which file is required. I wanted to stay away from this so I wrote up those simple typedefs. I don't know if there is a configure rule to test this and frankly I don't have the time to do any research on this. I personally would do a string replacement on all those types and replace them with well known X types. Cheers, Egbert. -- To unsubscribe, e-mail: radeonhd+unsubscribe(a)opensuse.org For additional commands, e-mail: radeonhd+help(a)opensuse.org

2 1

Primary screen black and cannot be reenabled
by Nico Schottelius 06 Aug '08

06 Aug '08

Hello! When I start xorg with radeonhd version 1.2.1, built from git branch master, commit c2139d8c, Chipset M54, both screens are working, but PANEL is in "wrong" (for me) solution: [15:39] denkbrett:~% xrandr Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 2800 x 2100 VGA_1 connected 1280x1024+0+0 376mm x 301mm 1280x1024 60.0*+ 75.0 59.9 1152x864 74.9 1024x768 75.1 60.0 800x600 75.0 60.3 640x480 75.0 60.0 720x400 70.1 PANEL connected 1280x1024+0+0 287mm x 215mm 1400x1050 60.0 + 2560x2048Scaled 60.5 2560x1600Scaled 60.5 2048x1536Scaled 60.5 1920x1200Scaled 60.4 1920x1080Scaled 60.5 1600x1200Scaled 60.4 1680x1050Scaled 60.3 1400x1050Scaled 60.3 1440x960Scaled 60.4 1280x1024Scaled 60.5* 1280x960Scaled 60.4 1280x854Scaled 60.4 1280x800 60.0 1280x768 60.0 1280x720Scaled 60.4 1152x768Scaled 60.3 1024x768 60.0 1024x768Scaled 60.4 800x600 60.3 800x600Scaled 60.3 768x576Scaled 60.4 854x480Scaled 59.8 720x480Scaled 59.8 640x480 59.9 640x480Scaled 60.1 320x240Scaled 57.6 320x200Scaled 55.7 When I do xrandr --output PANEL --auto both monitors get black for some seconds and then the only working screen is the external one. xrandr reports the following error: [15:43] denkbrett:~% xrandr --output PANEL --auto xrandr: Configure crtc 1 failed Using it with --verbose: [15:43] denkbrett:~% xrandr --verbose --output PANEL --auto screen 0: 1400x1050 411x308 mm 86.41dpi crtc 1: 1400x1050 60.0 +0+0 "PANEL" xrandr: Configure crtc 1 failed crtc 0: disable crtc 1: disable screen 0: revert crtc 0: revert crtc 1: revert [15:44] denkbrett:~% The output of xrandr after that call: [15:44] denkbrett:~% xrandr Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 2800 x 2100 VGA_1 connected 1280x1024+0+0 376mm x 301mm 1280x1024 60.0*+ 75.0 59.9 1152x864 74.9 1024x768 75.1 60.0 800x600 75.0 60.3 640x480 75.0 60.0 720x400 70.1 PANEL connected 1400x1050 60.0 + 2560x2048Scaled 60.5 2560x1600Scaled 60.5 2048x1536Scaled 60.5 1920x1200Scaled 60.4 1920x1080Scaled 60.5 1600x1200Scaled 60.4 1680x1050Scaled 60.3 1400x1050Scaled 60.3 1440x960Scaled 60.4 1280x1024Scaled 60.5 1280x960Scaled 60.4 1280x854Scaled 60.4 1280x800 60.0 1280x768 60.0 1280x720Scaled 60.4 1152x768Scaled 60.3 1024x768 60.0 1024x768Scaled 60.4 800x600 60.3 800x600Scaled 60.3 768x576Scaled 60.4 854x480Scaled 59.8 720x480Scaled 59.8 640x480 59.9 640x480Scaled 60.1 320x240Scaled 57.6 320x200Scaled 55.7 DVI-D_1 disconnected I am running X.Org X Server 1.4.0.90. Any hints on how to fix it? Sincerly, Nico -- Think about Free and Open Source Software (FOSS). http://nico.schottelius.org/documentations/foss/the-term-foss/ PGP: BFE4 C736 ABE5 406F 8F42 F7CF B8BE F92A 9885 188C

2 3

0x7942:0x1028:0x0204: ATI Radeon Xpress 1250 for Dell/Parker
by Rafi Rubin 03 Aug '08

03 Aug '08

I would most like to see XV and rotation support. At the moment the drm kernel module (from git) will not compile on my running kernel. So I assume I'll have to wait a bit longer before trying to get XV working. Is there anything I can do to try out or help with rotation? Rafi -- To unsubscribe, e-mail: radeonhd+unsubscribe(a)opensuse.org For additional commands, e-mail: radeonhd+help(a)opensuse.org

3 3

[Bug 14487] New: no DVI on Gigabyte GA-MA69GM-S2H
by bugzilla-daemon＠freedesktop.org 03 Aug '08

03 Aug '08

http://bugs.freedesktop.org/show_bug.cgi?id=14487 Summary: no DVI on Gigabyte GA-MA69GM-S2H Product: xorg Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/radeonhd AssignedTo: lverhaegen(a)suse.de ReportedBy: bunk(a)stusta.de QAContact: xorg-team(a)lists.x.org Created an attachment (id=14296) --> (http://bugs.freedesktop.org/attachment.cgi?id=14296) Xorg.0.log Analog output works fine with the onboard 690G, but DVI output isn't working. When starting X with the monitor connected through the DVI cable I'm _sometimes_ seeing something like a quarter of my X background picture fullscreen for half a second, but there's never any usable picture and the monitor tells me that it doesn't get any input. Tested with both the 1.1.0 package from Debian unstable and current -git. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. _______________________________________________ xorg-team mailing list xorg-team(a)lists.x.org http://lists.x.org/mailman/listinfo/xorg-team -- To unsubscribe, e-mail: radeonhd+unsubscribe(a)opensuse.org For additional commands, e-mail: radeonhd+help(a)opensuse.org

1 27