Yang Zhao wrote:

2009/10/31 Dave Witbrodt :

...

4. Not sure why only 256MB of 1GB of VRAM gets used.

It's only possible to map up to 256MB of VRAM for the CPU to access directly. There's nothing wrong, per se: the GPU is still able to access all of it.

Oh, the wording confused me: (II) RADEONHD(0): Using only 262144kB of the total 1048576kB. I would have understood better if the message read "Mapping" instead of "Using".

...

(II) RADEONHD(0): Using 3840x1920 Framebuffer with 3840 pitch (II) RADEONHD(0): FB: Allocated ScanoutBuffer at offset 0x00008000 (size = 0x01C20000) (**) RADEONHD(0): Display dimensions: (518, 324) mm (**) RADEONHD(0): DPI set to (188, 150) ... 6. The DPI 188,150 value is totally bogus. The 'xdpyinfo' utility reports 94 x 94 with X running.

Seems like it's calculating the DPI from total framebuffer size instead of actual display size. Should be a harmless cosmetic error.

OK, thanks.

...

7. I see that XVideo actually gets initialized, but XRandR and AIGLX fail toward the end of the process. Have I done something wrong? Something I can repair?

The RandR error is bogus: there is a line further up that says to ignore the randr failure message.

OK, rereading the log file I see the line you refer to.

AIGLX failure is expected without working 3D accel.

So, for RV770, is this because the in-kernel DRM does not yet support the experimental 3D acceleration for r700? I know that 'radeonhd' supports acceleration, and according to the "experimental_3D" wiki, http://www.x.org/wiki/radeonhd%3Aexperimental_3D the "R6xx/R7xx mesa code from 6xx-rewrite branch has been merged to master," so if I'm using Mesa 7.6 that piece of the puzzle should be OK as well, right? To play with 3D on my hardware, the wiki says "still need non-master drm from ~agd5f/drm r6xx-r7xx-3d branch." The instructions explain how to build DRM modules, but also how to rebuild Mesa. To get 3D on RV770, I would have to: - build DRM from the r6xx-r7xx-3d branch - skip the wiki instructions about rebuilding Mesa (since I already have Mesa 7.6) Does that sound right? Thanks again, Dave W. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Luca Tettamanti wrote:

On Sun, Nov 1, 2009 at 2:47 PM, Dave Witbrodt wrote:

...

So, for RV770, is this because the in-kernel DRM does not yet support the experimental 3D acceleration for r700?

I know that 'radeonhd' supports acceleration, and according to the "experimental_3D" wiki,

http://www.x.org/wiki/radeonhd%3Aexperimental_3D

the "R6xx/R7xx mesa code from 6xx-rewrite branch has been merged to master," so if I'm using Mesa 7.6 that piece of the puzzle should be OK as well, right?

To play with 3D on my hardware, the wiki says "still need non-master drm from ~agd5f/drm r6xx-r7xx-3d branch." The instructions explain how to build DRM modules, but also how to rebuild Mesa. To get 3D on RV770, I would have to:

- build DRM from the r6xx-r7xx-3d branch

I believe that the relevant stuff have been merged into libdrm master.

...

- skip the wiki instructions about rebuilding Mesa (since I already have Mesa 7.6)

Does that sound right?

Well no ;-) Debian libgl1-mesa-dri does not include r600 module (Debian kernel does not yet include DRM driver for r600), so you have to rebuild mesa. Also note that current git kernel (and 2.6.32) contains the needed DRM bits (more changes and fixes can be found in airlied's tree: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=summary, branch drm-next)

The fog is beginning to clear. Thanks, Luca. Now, to recap: 1. I have kernel 2.6.31 from git.kernel.org, but the DRM in that kernel cannot do 3D acceleration for RV770, so I have 2 choices: A. Build new kernel (2.3.32-rc*) or B. Build DRM using r6xx-r7xx-3d 2. Mesa 7.6 from Debian unstable (late September) is missing parts I need for acceleration on RV770, so I must rebuild Mesa from the experimental branch... even though the wiki says support for r600-r700 has been merged? Is that correct? (If not, I would rather avoid lots of unnecessary work!) Thanks, Dave W. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Alex Deucher wrote:

On Sun, Nov 1, 2009 at 11:54 AM, Dave Witbrodt wrote:

...

1. I have kernel 2.6.31 from git.kernel.org, but the DRM in that kernel cannot do 3D acceleration for RV770, so I have 2 choices:

A. Build new kernel (2.3.32-rc*) or B. Build DRM using r6xx-r7xx-3d

yes.

...

2. Mesa 7.6 from Debian unstable (late September) is missing parts I need for acceleration on RV770, so I must rebuild Mesa from the experimental branch... even though the wiki says support for r600-r700 has been merged?

Is that correct? (If not, I would rather avoid lots of unnecessary work!)

You need to build mesa from the 7.6 branch or master.

Thanks Alex. After further investigation of the Debianized sources, I found that the build rules for mesa-7.6 do not enable support for r600 by default. My currently-installed mesa-7.6 won't work. However, a quick glance at the 'configure' script reveals that the sources have the support, so it will be very easy for me to enable it on my architecture and produce nice DEBs. I also found that Debian has some packages called 'libdrm*'. If I had followed the wiki, the files corresponding to those packages would have been installed by the process of configuring, building, and installing the DRM sources. But my plan was to build a new 2.6.32-rc* kernel, not build the experimental DRM from scratch. That approach would give me the kernel module, but it will not update any of the files provided by those 'libdrm*' packages. Am I right to assume that I will need to rebuild the 'libdrm*' stuff with "--enable-radeon-experimental-api" enabled? (Even though I won't need the kernel module if the Debian build script produces one, I'll need new features provided by the other files?) So, I'll be having fun tonight this way: 1. Build and test 2.6.32-rc* for my desktop and 2 "server" machines. 2. Rebuild DEBs for mesa-7.6 after adjusting the changelog version and hacking the build rules to enable r600. 3. Rebuild DEBs for libdrm-2.4.14 after similar adjustments. (I see that 2.4.15 was released on October, but Debian hasn't picked it up yet... so I may also steal the Debian build scripts from 2.4.14 and try building that version instead.) If I'm wrong about step 3 (needing to rebuild 'libdrm') I hope someone will let me know. I don't get out of work until about 10 hours from now, so that's when the fun begins! Thanks, Dave W. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Alex Deucher wrote:

...

Am I right to assume that I will need to rebuild the 'libdrm*' stuff with "--enable-radeon-experimental-api" enabled? (Even though I won't need the kernel module if the Debian build script produces one, I'll need new features provided by the other files?)

you only need "--enable-radeon-experimental-api" if you want to use KMS.

OK, thanks for the save! KMS is my next step, but right now I'm working on acceleration in a non-KMS setup. I'll skip the rebuild of 'libdrm' until then.

...

2. Rebuild DEBs for mesa-7.6 after adjusting the changelog version and hacking the build rules to enable r600.

Make sure you get the latest 7.6 branch. The initial release of 7.6 did not work to well on r600. It was only properly fixed after 7.6 was released.

Ooh, another nice save! I'll use 'git' a post-7.6 mesa. Much thanks, Dave W. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Matthias Hopf wrote:

On Nov 01, 09 08:47:30 -0500, Dave Witbrodt wrote:

...

Oh, the wording confused me: (II) RADEONHD(0): Using only 262144kB of the total 1048576kB. I would have understood better if the message read "Mapping" instead of "Using".

Good point. Changing that, we got this comment too often :-)

Saw the commit of that change on the list before reading this. Thanks.

...

...

...

(II) RADEONHD(0): Using 3840x1920 Framebuffer with 3840 pitch (II) RADEONHD(0): FB: Allocated ScanoutBuffer at offset 0x00008000 (size = 0x01C20000) (**) RADEONHD(0): Display dimensions: (518, 324) mm (**) RADEONHD(0): DPI set to (188, 150) ...

* >>>> 6. The DPI 188,150 value is totally bogus. The 'xdpyinfo' utility reports

...

...

...

94 x 94 with X running.

...

...

Seems like it's calculating the DPI from total framebuffer size instead of actual display size. Should be a harmless cosmetic error. OK, thanks.

It not necessarily harmless - toolkits could choose weird font sizes because of this. This used to be an Xserver error, I wonder what is wrong now?

The server actually reports a DPI of 94x94, as I mentioned on the line marked with the asterisk above. I didn't bring it up to complain, only to point out that radeonhd is miscalculating somehow (even though X is not). Dave W. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Matthias Hopf wrote:

On Oct 31, 09 22:28:31 -0400, Dave Witbrodt wrote:

...

(II) RADEONHD(0): Power Management: Raw Ranges (II) RADEONHD(0): Minimum 250000 kHz / 250000 kHz / 0.892 V (II) RADEONHD(0): Maximum 768000 kHz / 1152000 kHz / 1.158 V (II) RADEONHD(0): Default 640000 kHz / 960000 kHz / 1.123 V (II) RADEONHD(0): PowerPlayInfo Revision 0401 (II) RADEONHD(0): Power Management: Validated Ranges (II) RADEONHD(0): Minimum 250000 kHz / 250000 kHz / 0.892 V (II) RADEONHD(0): Maximum 768000 kHz / 1152000 kHz / 65.281 V (II) RADEONHD(0): Default 640000 kHz / 960000 kHz / 1.123 V (II) RADEONHD(0): Power Management: Known Good Configurations (II) RADEONHD(0): 1 625000 kHz / 993000 kHz / 65.281 V (II) RADEONHD(0): 2 500000 kHz / 960000 kHz / 1.046 V (II) RADEONHD(0): 3 500000 kHz / 960000 kHz / 1.046 V (II) RADEONHD(0): 4 640000 kHz / 960000 kHz / 65.281 V (II) RADEONHD(0): 5 640000 kHz / 960000 kHz / 65.281 V (II) RADEONHD(0): 6 640000 kHz / 960000 kHz / 65.281 V (II) RADEONHD(0): 7 640000 kHz / 960000 kHz / 65.281 V (II) RADEONHD(0): 8 500000 kHz / 960000 kHz / 1.084 V (II) RADEONHD(0): 9 500000 kHz / 960000 kHz / 1.084 V

Uh-oh. The voltage levels look really broken. Can you post a BIOS here (you can get it with rhd_conntest -d [PCI-Id]) so I can verify what's happening here? Maybe also retry with git master, Egbert fixed an out-of-bounds access.

I've attached the requested BIOS. If, for some reason, the attachment doesn't work or gets blocked somewhere just let me know, and we can arrange another transfer method. I'm willing to rebuild radeonhd from git. My planned radeonhd experiments were delayed by the arrival of a box of parts, which took up my free time for a couple of days as I backed up data, rearranged some disks, and built a new machine ("crashdummy") out of a dying motherboard and one of the newly freed up hard drives. Just in time for me to become another statistic in the H1N1 pandemic! That was late last week. My brains are just coming back online yesterday and today. Should be able to test git version by Friday, though.

...

5. Those 65.281 V voltages in the Power Management section look scary. You folks aren't going to fry my new card, are you?! ;)

Luckily, you're safe, because of two things:

- Voltage setting is not implemented yet ;-)

- The AtomBIOS routines seem to validate the voltage against their maximum range

Good to know... as long as everything work the way you describe here! ;) Hope the BIOS helps, Dave W.

Matthias Hopf wrote:

On Nov 11, 09 13:59:40 -0500, Dave Witbrodt wrote:

...

...

Uh-oh. The voltage levels look really broken. Can you post a BIOS here (you can get it with rhd_conntest -d [PCI-Id]) so I can verify what's happening here? Maybe also retry with git master, Egbert fixed an out-of-bounds access. I've attached the requested BIOS. If, for some reason, the attachment doesn't work or gets blocked somewhere just let me know, and we can arrange another transfer method.

Worked out fine. The known good configurations table has a number of strange voltage entries (0xff01). I didn't validate the table entries yet, because I never saw wrong entries. Egbert fixed the possibility of broken table offsets (which he encountered), I just added the entry validation code to latest git, so please retest.

...

newly freed up hard drives. Just in time for me to become another statistic in the H1N1 pandemic!

:-] Take care, take your time. This is nothing pressing.

OK, I had to work on Thursday, but had Friday and Saturday off. Feeling much better now after the illness, I worked pretty hard on updating Mesa. I made it very hard on myself by requiring that I install everything using Debian's APT instead of raw 'make; make install' invocations, but it pays off when updates appear (or when a package begins behaving badly). The Debian build scripts for Mesa-7.6 produce about 5 packages I need, and 14 that I don't. I studied what Debian was doing to build all of that stuff for a long time, hoping to only enable building the few packages I needed. I finally figured out how it works, only to realize that it would have been WAY easier from the beginning just to let all 19 build in the first place, instead of blowing a whole Friday reinventing the wheel. (It wasn't a total waste, though: I now know a hell of a lot more about building DEBs than before!) In the end, I downloaded Mesa-7.7-devel-20091105, copied the 'debian' directory from Debian Mesa-7.6 sources, removed some of the patches that would not apply (and are not relevant to my hardware), and tweaked the 'debian/rules' script so that r600 support was added (and lots of other stuff was dropped). Had a few glitches forcing me to restart the build (luckily not from the beginning), and some new files from 7.7 ended up left out because I used package information from 7.6 to do the building... but I ended up with my DEBs! BTW, I was forced to build DEBs of 'libdrm' after all: the Mesa-7.7 'configure' script reported a dependency on a newer 'libdrm' (2.4.15) than Debian has right now. Also, as requested, I rebuilt 'radeonhd' using the git HEAD (and building DEBs, naturally), so we could see if the voltage tables looked better after Egbert's recent changes. But, most of all, I just wanted to see some working 2D/3D acceleration for a change! Results? Everything looks good! I'm attaching a full Xorg.0.log, but here are some highlights: [...] (==) RADEONHD(0): Depth 24, (--) framebuffer bpp 32 (**) RADEONHD(0): Selected EXA 2D acceleration. (II) RADEONHD(0): Card not in database: 0x9442:0x1458:0x21C7; using generic modesetting. [...] (II) RADEONHD(0): The detected amount of videoram exceeds the PCI BAR aperture. (II) RADEONHD(0): Mapping only 262144kB of the total 1048576kB, remaining memory is reserved for GPU. (--) RADEONHD(0): VideoRAM: 262144 kByte [...] (WW) RADEONHD(0): rhdAtomAllocateFbScratch: FW FB scratch area not located at the end of VRAM. Scratch End: 0x104fec VRAM End: 0x10000000 (II) RADEONHD(0): Cannot get VRAM scratch space. Allocating in main memory instead [...] (II) RADEONHD(0): Found libdri 5.4.0. drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: Searching for BusID pci:0000:01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: drmOpenMinor returns 8 drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 (II) RADEONHD(0): Found libdrm 1.3.0. (II) RADEONHD(0): Found radeon drm 1.31.0. [...] (II) RADEONHD(0): Current Chip Voltage: 1123 (II) RADEONHD(0): Power Management: used engine clock / memory clock / core (VDDC) voltage (0: ignore) (II) RADEONHD(0): Power Management: Raw Ranges (II) RADEONHD(0): Minimum 250000 kHz / 250000 kHz / 0.892 V (II) RADEONHD(0): Maximum 768000 kHz / 1152000 kHz / 1.158 V (II) RADEONHD(0): Default 640000 kHz / 960000 kHz / 1.123 V (II) RADEONHD(0): PowerPlayInfo Revision 0401 (II) RADEONHD(0): Power Management: Validated Ranges (II) RADEONHD(0): Minimum 250000 kHz / 250000 kHz / 0.892 V (II) RADEONHD(0): Maximum 768000 kHz / 1152000 kHz / 1.158 V (II) RADEONHD(0): Default 640000 kHz / 960000 kHz / 1.123 V (II) RADEONHD(0): Power Management: Known Good Configurations (II) RADEONHD(0): 1 625000 kHz / 993000 kHz / 0.000 V (II) RADEONHD(0): 2 500000 kHz / 960000 kHz / 1.046 V (II) RADEONHD(0): 3 500000 kHz / 960000 kHz / 1.046 V (II) RADEONHD(0): 4 640000 kHz / 960000 kHz / 0.000 V (II) RADEONHD(0): 5 640000 kHz / 960000 kHz / 0.000 V (II) RADEONHD(0): 6 640000 kHz / 960000 kHz / 0.000 V (II) RADEONHD(0): 7 640000 kHz / 960000 kHz / 0.000 V (II) RADEONHD(0): 8 500000 kHz / 960000 kHz / 1.084 V (II) RADEONHD(0): 9 500000 kHz / 960000 kHz / 1.084 V (II) RADEONHD(0): Power Management: Final Levels (II) RADEONHD(0): Off 250000 kHz / 250000 kHz / 0.892 V (II) RADEONHD(0): Idle 640000 kHz / 960000 kHz / 1.123 V (II) RADEONHD(0): Slow2D 640000 kHz / 960000 kHz / 1.123 V (II) RADEONHD(0): Fast2D 640000 kHz / 960000 kHz / 1.123 V (II) RADEONHD(0): Slow3D 640000 kHz / 960000 kHz / 1.123 V (II) RADEONHD(0): Fast3D 640000 kHz / 960000 kHz / 1.123 V (II) RADEONHD(0): Max3D 768000 kHz / 1152000 kHz / 1.158 V (II) RADEONHD(0): User 640000 kHz / 960000 kHz / 1.123 V [...] (II) RADEONHD(0): Using 3840x1920 Framebuffer with 3840 pitch (II) RADEONHD(0): FB: Allocated ScanoutBuffer at offset 0x00008000 (size = 0x01C20000) (**) RADEONHD(0): Display dimensions: (518, 324) mm (**) RADEONHD(0): DPI set to (188, 150) [...] (II) [drm] DRM interface version 1.3 (II) [drm] DRM open master succeeded. (II) RADEONHD(0): [drm] Using the DRM lock SAREA also for drawables. (II) RADEONHD(0): [drm] framebuffer handle = 0xd0000000 (II) RADEONHD(0): [drm] added 1 reserved context for kernel (II) RADEONHD(0): X context handle = 0x1 (II) RADEONHD(0): [drm] installed DRM signal handler (II) RADEONHD(0): [pci] 16384 kB allocated with handle 0x1142e900 [...] (II) RADEONHD(0): Direct rendering enabled (II) RADEONHD(0): Using DRM Command Processor (indirect) for acceleration. (II) EXA(0): Offscreen pixmap area of 26836992 bytes (II) EXA(0): Driver registered support for the following operations: (II) Solid (II) Copy (II) Composite (RENDER acceleration) (II) UploadToScreen (II) DownloadFromScreen [...] (II) AIGLX: Screen 0 is not DRI2 capable drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 9, (OK) drmOpenByBusid: Searching for BusID pci:0000:01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 9, (OK) drmOpenByBusid: drmOpenMinor returns 9 drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 (II) AIGLX: enabled GLX_MESA_copy_sub_buffer (II) AIGLX: enabled GLX_SGI_make_current_read (II) AIGLX: enabled GLX_texture_from_pixmap with driver support (II) AIGLX: Loaded and initialized /usr/lib/dri/r600_dri.so (II) GLX: Initialized DRI GL provider for screen 0 [...] I see where the bogus DPI calculation is coming from: radeonhd is using the virtual buffer size (3840x1920) instead of the screen size (1920x1200). Apart from corruption on the XDM login window (which occurs with and without acceleration), I have had no bugs or negative issues yet. I haven't tested it much -- windows can be slid with the mouse very rapidly without leaving long trails; DOSBox plays my favorite old game without sound glitches (graphics seem quicker, but haven't played with settings yet); prboom doesn't bog down so much -- but I'm already liking it. The visual aspects of my desktop machine haven't been this responsive since the proprietary NVidia driver went away (with the dead card this past summer). Just now, I tried 'glxgears'. Hmm... won't run: $ glxgears IRQ's not enabled, falling back to busy waits: 2 0 drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream. See dmesg for more info. $ dmesg [...] [ 8128.797480] [drm:r600_cs_packet_next_reloc_nomm] *ERROR* No packet3 for relocation for packet at 45. [ 8128.797490] [drm:r600_packet3_check] *ERROR* bad SET_CONTEXT_REG 0x28014 [ 8128.797496] [drm:r600_cs_legacy] *ERROR* Invalid command stream ! Not sure if this is brokenness in the code, or something I messed up when trying to produce my Mesa DEBs. (Some files ended up left behind; I had to hope they weren't essential.) Well, all I can say is Thanks to all of the developers! My next series of experiments will be with 'radeon', and then 'radeon + KMS'. Might try some of that tomorrow after work. Thanks again, Dave W. X.Org X Server 1.6.5 Release Date: 2009-10-11 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.30-2-amd64 x86_64 Debian Current Operating System: Linux desktop 2.6.32-rc7-0git091113.desktop.uvesafb #3 SMP PREEMPT Fri Nov 13 20:43:17 EST 2009 x86_64 Build Date: 13 October 2009 09:39:10AM xorg-server 2:1.6.5-1 (jcristau@debian.org) Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Sat Nov 14 20:22:38 2009 (==) Using config file: "/etc/X11/xorg.conf" (==) No Layout section. Using the first Screen section. (**) |-->Screen "Default Screen" (0) (**) | |-->Monitor "Acer P243WAid" (==) No device specified for screen "Default Screen". Using the first device section listed. (**) | |-->Device "Configured Video Device" (**) Option "AIGLX" "On" (==) Automatically adding devices (==) Automatically enabling devices (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. Entry deleted from font path. (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, built-ins (==) ModulePath set to "/usr/lib/xorg/modules" (**) Extension "Composite" is enabled (II) Cannot locate a core pointer device. (II) Cannot locate a core keyboard device. (II) The server relies on HAL to provide the list of input devices. If no devices become available, reconfigure HAL or disable AllowEmptyInput. (II) Loader magic: 0x3b40 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 5.0 X.Org XInput driver : 4.0 X.Org Server Extension : 2.0 (II) Loader running on linux (++) using VT number 7 (WW) xf86OpenConsole: setpgid failed: Operation not permitted (WW) xf86OpenConsole: setsid failed: Operation not permitted (--) PCI:*(0:1:0:0) 1002:9442:1458:21c7 ATI Technologies Inc RV770 [Radeon HD 4850] rev 0, Mem @ 0xd0000000/268435456, 0xfe8f0000/65536, I/O @ 0x0000a000/256, BIOS @ 0x????????/131072 (II) Open ACPI successful (/var/run/acpid.socket) (II) System resource ranges: [0] -1 0 0xffffffff - 0xffffffff (0x1) MX[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 0xffffffff - 0xffffffff (0x1) MX[B] [5] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [6] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [7] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [8] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [9] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [10] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [11] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [12] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [13] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [14] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [15] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [16] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [17] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [18] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [19] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [20] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [21] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [22] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [23] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [24] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [25] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [26] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [27] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [28] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [29] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [30] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [31] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [32] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [33] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [34] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [35] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] (II) LoadModule: "extmod" (II) Loading /usr/lib/xorg/modules/extensions//libextmod.so (II) Module extmod: vendor="X.Org Foundation" compiled for 1.6.5, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension SELinux (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "dbe" (II) Loading /usr/lib/xorg/modules/extensions//libdbe.so (II) Module dbe: vendor="X.Org Foundation" compiled for 1.6.5, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "glx" (II) Loading /usr/lib/xorg/modules/extensions//libglx.so (II) Module glx: vendor="X.Org Foundation" compiled for 1.6.5, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (**) AIGLX enabled (II) Loading extension GLX (II) LoadModule: "record" (II) Loading /usr/lib/xorg/modules/extensions//librecord.so (II) Module record: vendor="X.Org Foundation" compiled for 1.6.5, module version = 1.13.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension RECORD (II) LoadModule: "dri" (II) Loading /usr/lib/xorg/modules/extensions//libdri.so (II) Module dri: vendor="X.Org Foundation" compiled for 1.6.5, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension XFree86-DRI (II) LoadModule: "dri2" (II) Loading /usr/lib/xorg/modules/extensions//libdri2.so (II) Module dri2: vendor="X.Org Foundation" compiled for 1.6.5, module version = 1.1.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DRI2 (II) LoadModule: "radeonhd" (II) Loading /usr/lib/xorg/modules/drivers//radeonhd_drv.so (II) Module radeonhd: vendor="AMD GPG" compiled for 1.6.5, module version = 1.3.0 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 5.0 (II) RADEONHD: X driver for the following AMD GPG (ATI) graphics devices: RV505 : Radeon X1550, X1550 64bit. RV515 : Radeon X1300, X1550, X1600; FireGL V3300, V3350. RV516 : Radeon X1300, X1550, X1550 64-bit, X1600; FireMV 2250. R520 : Radeon X1800; FireGL V5300, V7200, V7300, V7350. RV530 : Radeon X1300 XT, X1600, X1600 Pro, X1650; FireGL V3400, V5200. RV535 : Radeon X1300, X1650. RV550 : Radeon X2300 HD. RV560 : Radeon X1650. RV570 : Radeon X1950, X1950 GT; FireGL V7400. R580 : Radeon X1900, X1950; AMD Stream Processor. R600 : Radeon HD 2900 GT/Pro/XT; FireGL V7600/V8600/V8650. RV610 : Radeon HD 2350, HD 2400 Pro/XT, HD 2400 Pro AGP; FireGL V4000. RV620 : Radeon HD 3450, HD 3470. RV630 : Radeon HD 2600 LE/Pro/XT, HD 2600 Pro/XT AGP; Gemini RV630; FireGL V3600/V5600. RV635 : Radeon HD 3650, HD 3670. RV670 : Radeon HD 3690, 3850, HD 3870, FireGL V7700, FireStream 9170. R680 : Radeon HD 3870 X2. M52 : Mobility Radeon X1300. M54 : Mobility Radeon X1400; M54-GL. M56 : Mobility Radeon X1600; Mobility FireGL V5200. M58 : Mobility Radeon X1800, X1800 XT; Mobility FireGL V7100, V7200. M62 : Mobility Radeon X1350. M64 : Mobility Radeon X1450, X2300. M66 : Mobility Radeon X1700, X1700 XT; FireGL V5250. M68 : Mobility Radeon X1900. M71 : Mobility Radeon HD 2300. M72 : Mobility Radeon HD 2400; Radeon E2400. M74 : Mobility Radeon HD 2400 XT. M76 : Mobility Radeon HD 2600; (Gemini ATI) Mobility Radeon HD 2600 XT. M82 : Mobility Radeon HD 3400. M86 : Mobility Radeon HD 3650, HD 3670, Mobility FireGL V5700. M88 : Mobility Radeon HD 3850, HD 3850 X2, HD 3870, HD3870 X2. RS600 : Radeon Xpress 1200, Xpress 1250. RS690 : Radeon X1200, X1250, X1270. RS740 : RS740, RS740M. RS780 : Radeon HD 3100/3200/3300 Series. R700 : Radeon R700. RV710 : Radeon HD4570, HD4350. RV730 : Radeon HD4670, HD4650. RV740 : Radeon HD4770. EXPERIMENTAL AND UNTESTED. RV770 : Radeon HD 4800 Series; Everest, K2, Denali ATI FirePro. RV790 : Radeon HD 4890. M92 : Mobility Radeon HD4330, HD4530, HD4570. EXPERIMENTAL. M93 : Mobility Radeon M93. EXPERIMENTAL AND UNTESTED. M96 : Mobility Radeon HD4600. M97 : Mobility Radeon HD4860. EXPERIMENTAL AND UNTESTED. M98 : Mobility Radeon HD4850, HD4870. (II) RADEONHD: version 1.3.0, built from non-git sources (II) Primary Device is: PCI 01@00:00:0 (II) resource ranges after xf86ClaimFixedResources() call: [0] -1 0 0xffffffff - 0xffffffff (0x1) MX[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 0xffffffff - 0xffffffff (0x1) MX[B] [5] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [6] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [7] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [8] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [9] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [10] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [11] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [12] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [13] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [14] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [15] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [16] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [17] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [18] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [19] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [20] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [21] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [22] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [23] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [24] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [25] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [26] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [27] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [28] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [29] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [30] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [31] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [32] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [33] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [34] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [35] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] (II) resource ranges after probing: [0] -1 0 0xffffffff - 0xffffffff (0x1) MX[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 0xffffffff - 0xffffffff (0x1) MX[B] [5] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [6] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [7] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [8] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [9] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [10] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [11] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [12] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [13] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [14] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [15] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [16] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [17] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [18] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [19] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [20] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [21] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [22] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [23] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [24] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] [25] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] [26] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] [27] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [28] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [29] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [30] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [31] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [32] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [33] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [34] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [35] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [36] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [37] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [38] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [39] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] [40] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] (==) RADEONHD(0): Depth 24, (--) framebuffer bpp 32 (**) RADEONHD(0): Selected EXA 2D acceleration. (II) RADEONHD(0): Card not in database: 0x9442:0x1458:0x21C7; using generic modesetting. If - and only if - your card does not work or does not work optimally please contact radeonhd@opensuse.org to help rectify this. Use the subject: 0x9442:0x1458:0x21C7: <name of board> and *please* describe the problems you are seeing in your message. (--) RADEONHD(0): Detected an RV770 on an unidentified card (II) RADEONHD(0): Mapped IO @ 0xfe8f0000 to 0x7f0c0e9ba000 (size 0x00010000) (II) RADEONHD(0): PCIE Card Detected (II) RADEONHD(0): Getting BIOS copy from legacy VBIOS location (II) RADEONHD(0): ATOM BIOS Rom: SubsystemVendorID: 0x1458 SubsystemID: 0x21c7 IOBaseAddress: 0xa000 Filename: R485MCAI.F4 BIOS Bootup Message: GV-R485MC-1GI/F4 (II) RADEONHD(0): Analog TV Default Mode: 1 (II) RADEONHD(0): Found default TV Mode NTSC (II) RADEONHD(0): The detected amount of videoram exceeds the PCI BAR aperture. (II) RADEONHD(0): Mapping only 262144kB of the total 1048576kB, remaining memory is reserved for GPU. (--) RADEONHD(0): VideoRAM: 262144 kByte (II) RADEONHD(0): Framebuffer space used by Firmware (kb): 20 (II) RADEONHD(0): Start of VRAM area used by Firmware: 0xfffec (II) RADEONHD(0): AtomBIOS requests 20kB of VRAM scratch space (II) RADEONHD(0): AtomBIOS VRAM scratch base: 0xfffec (WW) RADEONHD(0): rhdAtomAllocateFbScratch: FW FB scratch area not located at the end of VRAM. Scratch End: 0x104fec VRAM End: 0x10000000 (II) RADEONHD(0): Cannot get VRAM scratch space. Allocating in main memory instead (II) RADEONHD(0): Default Engine Clock: 640000 (II) RADEONHD(0): Default Memory Clock: 960000 (II) RADEONHD(0): Maximum Pixel ClockPLL Frequency Output: 1200000 (II) RADEONHD(0): Minimum Pixel ClockPLL Frequency Output: 0 (II) RADEONHD(0): Maximum Pixel ClockPLL Frequency Input: 16000 (II) RADEONHD(0): Minimum Pixel ClockPLL Frequency Input: 6000 (II) RADEONHD(0): Maximum Pixel Clock: 400000 (II) RADEONHD(0): Reference Clock: 100000 (II) RADEONHD(0): Found libdri 5.4.0. drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: Searching for BusID pci:0000:01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: drmOpenMinor returns 8 drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 (II) RADEONHD(0): Found libdrm 1.3.0. (II) RADEONHD(0): Found radeon drm 1.31.0. (II) Loading sub module "i2c" (II) LoadModule: "i2c" (II) Module "i2c" already built-in (II) RADEONHD(0): Reference Clock: 100000 (II) RADEONHD(0): GPIO_I2C_Clk_Mask: 0x1f90 (II) RADEONHD(0): GPIO_I2C_Clk_Mask_Shift: 0x0 (II) RADEONHD(0): GPIO_I2C_Data_Mask: 0x1f90 (II) RADEONHD(0): GPIO_I2C_Data_Mask_Shift: 0x8 (II) RADEONHD(0): I2C bus "RHD I2C line 0" initialized. (II) RADEONHD(0): GPIO_I2C_Clk_Mask: 0x1f94 (II) RADEONHD(0): GPIO_I2C_Clk_Mask_Shift: 0x0 (II) RADEONHD(0): GPIO_I2C_Data_Mask: 0x1f94 (II) RADEONHD(0): GPIO_I2C_Data_Mask_Shift: 0x8 (II) RADEONHD(0): I2C bus "RHD I2C line 1" initialized. (II) RADEONHD(0): GPIO_I2C_Clk_Mask: 0x1f98 (II) RADEONHD(0): GPIO_I2C_Clk_Mask_Shift: 0x0 (II) RADEONHD(0): GPIO_I2C_Data_Mask: 0x1f98 (II) RADEONHD(0): GPIO_I2C_Data_Mask_Shift: 0x8 (II) RADEONHD(0): I2C bus "RHD I2C line 2" initialized. (II) RADEONHD(0): GPIO_I2C_Clk_Mask: 0x1f88 (II) RADEONHD(0): GPIO_I2C_Clk_Mask_Shift: 0x0 (II) RADEONHD(0): GPIO_I2C_Data_Mask: 0x1f88 (II) RADEONHD(0): GPIO_I2C_Data_Mask_Shift: 0x8 (II) RADEONHD(0): I2C bus "RHD I2C line 3" initialized. (II) Loading sub module "ddc" (II) LoadModule: "ddc" (II) Module "ddc" already built-in (II) RADEONHD(0): Detected VGA mode. (**) RADEONHD(0): Using AtomBIOS for Crtcs (**) RADEONHD(0): Using AtomBIOS for PLLs (II) RADEONHD(0): Minimum Pixel ClockPLL Frequency Output: 0 (II) RADEONHD(0): Maximum Pixel ClockPLL Frequency Output: 1200000 (II) RADEONHD(0): Maximum Pixel Clock: 400000 (II) RADEONHD(0): Reference Clock: 100000 (II) RADEONHD(0): rhdAtomSetPixelClockVersion returned version 3 for index 0xc (II) RADEONHD(0): rhdAtomSetPixelClockVersion returned version 3 for index 0xc (II) RADEONHD(0): FB: Allocated Cursor Image at offset 0x00000000 (size = 0x00004000) (II) RADEONHD(0): FB: Allocated Cursor Image at offset 0x00004000 (size = 0x00004000) (II) RADEONHD(0): FirmwareInfo Revision 0104 (II) RADEONHD(0): Unused attribute: ul3DAccelerationEngineClock 0 (II) RADEONHD(0): Unused attribute: ulDriverTargetEngineClock 0 (II) RADEONHD(0): Unused attribute: ulDriverTargetMemoryClock 0 (II) RADEONHD(0): Unused attribute: ucASICMaxTemperature 0 (II) RADEONHD(0): Scary bits: Estimated MinEngineClock 250000 kHz (II) RADEONHD(0): Scary bits: Estimated MinMemoryClock 250000 kHz (II) RADEONHD(0): Default Engine Clock: 640000 (II) RADEONHD(0): Default Memory Clock: 960000 (II) RADEONHD(0): Current Engine Clock: 637500 (II) RADEONHD(0): Current Memory Clock: 959370 (II) RADEONHD(0): Current Chip Voltage: 1123 (II) RADEONHD(0): Power Management: used engine clock / memory clock / core (VDDC) voltage (0: ignore) (II) RADEONHD(0): Power Management: Raw Ranges (II) RADEONHD(0): Minimum 250000 kHz / 250000 kHz / 0.892 V (II) RADEONHD(0): Maximum 768000 kHz / 1152000 kHz / 1.158 V (II) RADEONHD(0): Default 640000 kHz / 960000 kHz / 1.123 V (II) RADEONHD(0): PowerPlayInfo Revision 0401 (II) RADEONHD(0): Power Management: Validated Ranges (II) RADEONHD(0): Minimum 250000 kHz / 250000 kHz / 0.892 V (II) RADEONHD(0): Maximum 768000 kHz / 1152000 kHz / 1.158 V (II) RADEONHD(0): Default 640000 kHz / 960000 kHz / 1.123 V (II) RADEONHD(0): Power Management: Known Good Configurations (II) RADEONHD(0): 1 625000 kHz / 993000 kHz / 0.000 V (II) RADEONHD(0): 2 500000 kHz / 960000 kHz / 1.046 V (II) RADEONHD(0): 3 500000 kHz / 960000 kHz / 1.046 V (II) RADEONHD(0): 4 640000 kHz / 960000 kHz / 0.000 V (II) RADEONHD(0): 5 640000 kHz / 960000 kHz / 0.000 V (II) RADEONHD(0): 6 640000 kHz / 960000 kHz / 0.000 V (II) RADEONHD(0): 7 640000 kHz / 960000 kHz / 0.000 V (II) RADEONHD(0): 8 500000 kHz / 960000 kHz / 1.084 V (II) RADEONHD(0): 9 500000 kHz / 960000 kHz / 1.084 V (II) RADEONHD(0): Power Management: Final Levels (II) RADEONHD(0): Off 250000 kHz / 250000 kHz / 0.892 V (II) RADEONHD(0): Idle 640000 kHz / 960000 kHz / 1.123 V (II) RADEONHD(0): Slow2D 640000 kHz / 960000 kHz / 1.123 V (II) RADEONHD(0): Fast2D 640000 kHz / 960000 kHz / 1.123 V (II) RADEONHD(0): Slow3D 640000 kHz / 960000 kHz / 1.123 V (II) RADEONHD(0): Fast3D 640000 kHz / 960000 kHz / 1.123 V (II) RADEONHD(0): Max3D 768000 kHz / 1152000 kHz / 1.158 V (II) RADEONHD(0): User 640000 kHz / 960000 kHz / 1.123 V (II) RADEONHD(0): Connector[0] {RHD_CONNECTOR_DVI_SINGLE, "HDMI_TYPE_A DFP1", RHD_DDC_2, RHD_HPD_0, { RHD_OUTPUT_UNIPHYA, RHD_OUTPUT_NONE } } (II) RADEONHD(0): Connector[1] {RHD_CONNECTOR_VGA, "VGA CRT2", RHD_DDC_0, RHD_HPD_NONE, { RHD_OUTPUT_DACB, RHD_OUTPUT_NONE } } (II) RADEONHD(0): Connector[2] {RHD_CONNECTOR_DVI, "DUAL_LINK_DVI_I CRT1 DFP2", RHD_DDC_3, RHD_HPD_1, { RHD_OUTPUT_KLDSKP_LVTMA, RHD_OUTPUT_DACA } } (**) RADEONHD(0): Using AtomBIOS for Outputs (II) RADEONHD(0): rhdAtomSelectCrtcSourceVersion returned version 2 for index 0x2a (--) RADEONHD(0): Attaching Output AtomOutputUniphyA to Connector DVI-D 1 (**) RADEONHD(0): Using AtomBIOS for Outputs (II) RADEONHD(0): rhdAtomSelectCrtcSourceVersion returned version 2 for index 0x2a (--) RADEONHD(0): Attaching Output AtomOutputDACB to Connector VGA 1 (**) RADEONHD(0): Using AtomBIOS for Outputs (II) RADEONHD(0): rhdAtomSelectCrtcSourceVersion returned version 2 for index 0x2a (--) RADEONHD(0): Attaching Output AtomOutputKldskpLvtma to Connector DVI-I 2 (**) RADEONHD(0): Using AtomBIOS for Outputs (II) RADEONHD(0): rhdAtomSelectCrtcSourceVersion returned version 2 for index 0x2a (--) RADEONHD(0): Attaching Output AtomOutputDACA to Connector DVI-I 2 (II) RADEONHD(0): RandR: Adding RRoutput DVI-D_1 for Output AtomOutputUniphyA (II) RADEONHD(0): RandR: Adding RRoutput VGA_1 for Output AtomOutputDACB (II) RADEONHD(0): RandR: Adding RRoutput DVI-I_2/digital for Output AtomOutputKldskpLvtma (II) RADEONHD(0): RandR: Adding RRoutput DVI-I_2/analog for Output AtomOutputDACA (II) RADEONHD(0): Output DVI-D_1 using monitor section Acer P243WAid (II) RADEONHD(0): Output DVI-D_1 has no monitor section (II) RADEONHD(0): Output VGA_1 has no monitor section (II) RADEONHD(0): Output DVI-I_2/digital has no monitor section (II) RADEONHD(0): Output DVI-I_2/analog has no monitor section (**) RADEONHD(0): Option "ModeDebug" "true" (II) RADEONHD(0): EDID for output DVI-D_1 (II) RADEONHD(0): Calling DAC_LoadDetection (II) RADEONHD(0): DAC_LoadDetection Successful (II) RADEONHD(0): AtomOutputDACB: Sensed Output: VGA (II) RADEONHD(0): Setting AtomOutputDACB to incoherent (II) RADEONHD(0): I2C device "RHD I2C line 0:E-EDID segment register" registered at address 0x60. (II) RADEONHD(0): I2C device "RHD I2C line 0:ddc2" registered at address 0xA0. (II) RADEONHD(0): EDID data for Acer P243W (II) RADEONHD(0): Manufacturer: ACR Model: adaf Serial#: 2199916607 (II) RADEONHD(0): Year: 2008 Week: 32 (II) RADEONHD(0): EDID Version: 1.3 (II) RADEONHD(0): Analog Display Input, Input Voltage Level: 0.700/0.700 V (II) RADEONHD(0): Sync: Separate (II) RADEONHD(0): Max Image Size [cm]: horiz.: 52 vert.: 32 (II) RADEONHD(0): Gamma: 2.20 (II) RADEONHD(0): No DPMS capabilities specified; RGB/Color Display (II) RADEONHD(0): Default color space is primary color space (II) RADEONHD(0): First detailed timing is preferred mode (II) RADEONHD(0): redX: 0.661 redY: 0.328 greenX: 0.217 greenY: 0.677 (II) RADEONHD(0): blueX: 0.146 blueY: 0.075 whiteX: 0.313 whiteY: 0.329 (II) RADEONHD(0): Supported established timings: (II) RADEONHD(0): 720x400@70Hz (II) RADEONHD(0): 640x480@60Hz (II) RADEONHD(0): 640x480@67Hz (II) RADEONHD(0): 640x480@72Hz (II) RADEONHD(0): 640x480@75Hz (II) RADEONHD(0): 800x600@56Hz (II) RADEONHD(0): 800x600@60Hz (II) RADEONHD(0): 800x600@72Hz (II) RADEONHD(0): 800x600@75Hz (II) RADEONHD(0): 1024x768@60Hz (II) RADEONHD(0): 1024x768@70Hz (II) RADEONHD(0): 1024x768@75Hz (II) RADEONHD(0): 1280x1024@75Hz (II) RADEONHD(0): Manufacturer's mask: 0 (II) RADEONHD(0): Supported standard timings: (II) RADEONHD(0): #0: hsize: 1440 vsize 900 refresh: 60 vid: 149 (II) RADEONHD(0): #1: hsize: 1440 vsize 900 refresh: 75 vid: 3989 (II) RADEONHD(0): #2: hsize: 1280 vsize 800 refresh: 60 vid: 129 (II) RADEONHD(0): #3: hsize: 1280 vsize 800 refresh: 75 vid: 3969 (II) RADEONHD(0): #4: hsize: 1280 vsize 720 refresh: 60 vid: 49281 (II) RADEONHD(0): #5: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEONHD(0): #6: hsize: 1600 vsize 1200 refresh: 60 vid: 16553 (II) RADEONHD(0): Supported detailed timing: (II) RADEONHD(0): clock: 154.0 MHz Image Size: 518 x 324 mm (II) RADEONHD(0): h_active: 1920 h_sync: 1968 h_sync_end 2000 h_blank_end 2080 h_border: 0 (II) RADEONHD(0): v_active: 1200 v_sync: 1203 v_sync_end 1209 v_blanking: 1235 v_border: 0 (II) RADEONHD(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 94 kHz, PixClock max 170 MHz (II) RADEONHD(0): Monitor name: Acer P243W (II) RADEONHD(0): Serial No: LAF040114321 (II) RADEONHD(0): EDID (in hex): (II) RADEONHD(0): 00ffffffffffff000472afad3f102083 (II) RADEONHD(0): 20120103683420780e4995a95437ad25 (II) RADEONHD(0): 135054bfcf009500950f8100810f81c0 (II) RADEONHD(0): 8180a9400101283c80a070b023403020 (II) RADEONHD(0): 360006442100001a000000fd00384b1e (II) RADEONHD(0): 5e11000a202020202020000000fc0041 (II) RADEONHD(0): 6365722050323433570a2020000000ff (II) RADEONHD(0): 004c41463034303131343332310a0084 (II) RADEONHD(0): EDID for output VGA_1 (II) RADEONHD(0): Manufacturer: ACR Model: adaf Serial#: 2199916607 (II) RADEONHD(0): Year: 2008 Week: 32 (II) RADEONHD(0): EDID Version: 1.3 (II) RADEONHD(0): Analog Display Input, Input Voltage Level: 0.700/0.700 V (II) RADEONHD(0): Sync: Separate (II) RADEONHD(0): Max Image Size [cm]: horiz.: 52 vert.: 32 (II) RADEONHD(0): Gamma: 2.20 (II) RADEONHD(0): No DPMS capabilities specified; RGB/Color Display (II) RADEONHD(0): Default color space is primary color space (II) RADEONHD(0): First detailed timing is preferred mode (II) RADEONHD(0): redX: 0.661 redY: 0.328 greenX: 0.217 greenY: 0.677 (II) RADEONHD(0): blueX: 0.146 blueY: 0.075 whiteX: 0.313 whiteY: 0.329 (II) RADEONHD(0): Supported established timings: (II) RADEONHD(0): 720x400@70Hz (II) RADEONHD(0): 640x480@60Hz (II) RADEONHD(0): 640x480@67Hz (II) RADEONHD(0): 640x480@72Hz (II) RADEONHD(0): 640x480@75Hz (II) RADEONHD(0): 800x600@56Hz (II) RADEONHD(0): 800x600@60Hz (II) RADEONHD(0): 800x600@72Hz (II) RADEONHD(0): 800x600@75Hz (II) RADEONHD(0): 1024x768@60Hz (II) RADEONHD(0): 1024x768@70Hz (II) RADEONHD(0): 1024x768@75Hz (II) RADEONHD(0): 1280x1024@75Hz (II) RADEONHD(0): Manufacturer's mask: 0 (II) RADEONHD(0): Supported standard timings: (II) RADEONHD(0): #0: hsize: 1440 vsize 900 refresh: 60 vid: 149 (II) RADEONHD(0): #1: hsize: 1440 vsize 900 refresh: 75 vid: 3989 (II) RADEONHD(0): #2: hsize: 1280 vsize 800 refresh: 60 vid: 129 (II) RADEONHD(0): #3: hsize: 1280 vsize 800 refresh: 75 vid: 3969 (II) RADEONHD(0): #4: hsize: 1280 vsize 720 refresh: 60 vid: 49281 (II) RADEONHD(0): #5: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEONHD(0): #6: hsize: 1600 vsize 1200 refresh: 60 vid: 16553 (II) RADEONHD(0): Supported detailed timing: (II) RADEONHD(0): clock: 154.0 MHz Image Size: 518 x 324 mm (II) RADEONHD(0): h_active: 1920 h_sync: 1968 h_sync_end 2000 h_blank_end 2080 h_border: 0 (II) RADEONHD(0): v_active: 1200 v_sync: 1203 v_sync_end 1209 v_blanking: 1235 v_border: 0 (II) RADEONHD(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 94 kHz, PixClock max 170 MHz (II) RADEONHD(0): Monitor name: Acer P243W (II) RADEONHD(0): Serial No: LAF040114321 (II) RADEONHD(0): EDID (in hex): (II) RADEONHD(0): 00ffffffffffff000472afad3f102083 (II) RADEONHD(0): 20120103683420780e4995a95437ad25 (II) RADEONHD(0): 135054bfcf009500950f8100810f81c0 (II) RADEONHD(0): 8180a9400101283c80a070b023403020 (II) RADEONHD(0): 360006442100001a000000fd00384b1e (II) RADEONHD(0): 5e11000a202020202020000000fc0041 (II) RADEONHD(0): 6365722050323433570a2020000000ff (II) RADEONHD(0): 004c41463034303131343332310a0084 (II) RADEONHD(0): Printing probed modes for output VGA_1 (II) RADEONHD(0): Modeline "1920x1200"x60.0 154.00 1920 1968 2000 2080 1200 1203 1209 1235 +hsync -vsync (74.0 kHz) (II) RADEONHD(0): Modeline "1600x1200"x59.9 161.00 1600 1709 1880 2160 1200 1203 1207 1245 -hsync +vsync (74.5 kHz) (II) RADEONHD(0): Modeline "1280x1024"x75.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz) (II) RADEONHD(0): Modeline "1280x1024"x59.9 109.00 1280 1361 1496 1712 1024 1027 1034 1063 -hsync +vsync (63.7 kHz) (II) RADEONHD(0): Modeline "1440x900"x74.9 136.75 1440 1535 1689 1938 900 903 909 942 -hsync +vsync (70.6 kHz) (II) RADEONHD(0): Modeline "1440x900"x60.0 107.00 1440 1524 1675 1910 900 903 909 934 -hsync +vsync (56.0 kHz) (II) RADEONHD(0): Modeline "1280x800"x74.8 107.25 1280 1360 1495 1710 800 803 809 838 -hsync +vsync (62.7 kHz) (II) RADEONHD(0): Modeline "1280x800"x59.9 83.75 1280 1348 1481 1682 800 803 809 831 -hsync +vsync (49.8 kHz) (II) RADEONHD(0): Modeline "1280x720"x59.9 74.75 1280 1342 1474 1668 720 723 728 748 -hsync +vsync (44.8 kHz) (II) RADEONHD(0): Modeline "1024x768"x75.1 78.80 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.1 kHz) (II) RADEONHD(0): Modeline "1024x768"x70.1 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz) (II) RADEONHD(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) RADEONHD(0): Modeline "800x600"x72.2 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz) (II) RADEONHD(0): Modeline "800x600"x75.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) (II) RADEONHD(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) RADEONHD(0): Modeline "800x600"x56.2 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (II) RADEONHD(0): Modeline "640x480"x75.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (II) RADEONHD(0): Modeline "640x480"x72.8 31.50 640 664 704 832 480 489 491 520 -hsync -vsync (37.9 kHz) (II) RADEONHD(0): Modeline "640x480"x66.7 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz) (II) RADEONHD(0): Modeline "640x480"x60.0 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) RADEONHD(0): Modeline "720x400"x70.1 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) (II) RADEONHD(0): EDID for output DVI-I_2/digital (II) RADEONHD(0): EDID for output DVI-I_2/analog (II) RADEONHD(0): Output DVI-D_1 disconnected (II) RADEONHD(0): Output VGA_1 connected (II) RADEONHD(0): Output DVI-I_2/digital disconnected (II) RADEONHD(0): Output DVI-I_2/analog disconnected (II) RADEONHD(0): Using user preference for initial modes (II) RADEONHD(0): Output VGA_1 using initial mode 1920x1200 (II) RADEONHD(0): RandR 1.2 support enabled (==) RADEONHD(0): RGB weight 888 (==) RADEONHD(0): Default visual is TrueColor (==) RADEONHD(0): Using gamma correction (1.0, 1.0, 1.0) (II) RADEONHD(0): Using 3840x1920 Framebuffer with 3840 pitch (II) RADEONHD(0): FB: Allocated ScanoutBuffer at offset 0x00008000 (size = 0x01C20000) (**) RADEONHD(0): Display dimensions: (518, 324) mm (**) RADEONHD(0): DPI set to (188, 150) (II) Loading sub module "fb" (II) LoadModule: "fb" (II) Loading /usr/lib/xorg/modules//libfb.so (II) Module fb: vendor="X.Org Foundation" compiled for 1.6.5, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.4 (II) Loading sub module "ramdac" (II) LoadModule: "ramdac" (II) Module "ramdac" already built-in (II) Loading sub module "exa" (II) LoadModule: "exa" (II) Loading /usr/lib/xorg/modules//libexa.so (II) Module exa: vendor="X.Org Foundation" compiled for 1.6.5, module version = 2.4.0 ABI class: X.Org Video Driver, version 5.0 (II) RADEONHD(0): FB: Allocated Offscreen Buffer at offset 0x01C28000 (size = 0x01998000) (II) RADEONHD(0): FB: Allocated DRI Back Buffer at offset 0x035C0000 (size = 0x01C20000) (II) RADEONHD(0): FB: Allocated DRI Depth Buffer at offset 0x051E0000 (size = 0x01C20000) (II) RADEONHD(0): FB: Allocated GART table at offset 0x0FFF0000 (size = 0x00010000, end of FB) (II) RADEONHD(0): FB: Allocated DRI Textures at offset 0x06E00000 (size = 0x09000000) (II) RADEONHD(0): Using 16 MB GART aperture (II) RADEONHD(0): Using 2 MB for the ring buffer (II) RADEONHD(0): Using 2 MB for vertex/indirect buffers (II) RADEONHD(0): Using 12 MB for GART textures (--) Depth 24 pixmap format is 32 bpp (II) do I need RAC? No, I don't. (II) resource ranges after preInit: [0] -1 0 0xffffffff - 0xffffffff (0x1) MX[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 0xffffffff - 0xffffffff (0x1) MX[B] [5] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [6] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [7] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [8] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [9] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [10] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [11] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [12] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [13] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [14] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [15] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [16] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [17] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [18] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [19] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [20] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [21] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [22] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [23] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [24] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] [25] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] [26] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] [27] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [28] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [29] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [30] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [31] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [32] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [33] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [34] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [35] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [36] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [37] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [38] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [39] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] [40] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] (II) RADEONHD(0): Mapped IO @ 0xfe8f0000 to 0x7f0c0e9ba000 (size 0x00010000) (II) RADEONHD(0): Mapped FB @ 0xd0000000 to 0x7f0bfa818000 (size 0x10000000) (II) RADEONHD(0): Attempting to enable power management (II) RADEONHD(0): Current Engine Clock: 637500 (II) RADEONHD(0): Current Memory Clock: 959370 (II) RADEONHD(0): Current Chip Voltage: 1123 (II) RADEONHD(0): Calling EnableCRTC (II) RADEONHD(0): EnableCRTC Successful (II) RADEONHD(0): Calling EnableCRTCMemReq (II) RADEONHD(0): EnableCRTCMemReq Successful (II) RADEONHD(0): Calling EnableCRTC (II) RADEONHD(0): EnableCRTC Successful (II) RADEONHD(0): Calling EnableCRTCMemReq (II) RADEONHD(0): EnableCRTCMemReq Successful drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: Searching for BusID pci:0000:01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: drmOpenMinor returns 8 drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 (II) [drm] DRM interface version 1.3 (II) [drm] DRM open master succeeded. (II) RADEONHD(0): [drm] Using the DRM lock SAREA also for drawables. (II) RADEONHD(0): [drm] framebuffer handle = 0xd0000000 (II) RADEONHD(0): [drm] added 1 reserved context for kernel (II) RADEONHD(0): X context handle = 0x1 (II) RADEONHD(0): [drm] installed DRM signal handler (II) RADEONHD(0): [pci] 16384 kB allocated with handle 0x1142e900 (II) RADEONHD(0): [pci] ring handle = 0x2b800000 (II) RADEONHD(0): [pci] Ring mapped at 0x7f0bfa617000 (II) RADEONHD(0): [pci] Ring contents 0x00000000 (II) RADEONHD(0): [pci] ring read ptr handle = 0x1b7ff000 (II) RADEONHD(0): [pci] Ring read ptr mapped at 0x7f0c0e9de000 (II) RADEONHD(0): [pci] Ring read ptr contents 0x00000000 (II) RADEONHD(0): [pci] vertex/indirect buffers handle = 0x2b801000 (II) RADEONHD(0): [pci] Vertex/indirect buffers mapped at 0x7f0bfa417000 (II) RADEONHD(0): [pci] Vertex/indirect buffers contents 0x00000000 (II) RADEONHD(0): [pci] GART texture map handle = 0x2b802000 (II) RADEONHD(0): [pci] GART Texture map mapped at 0x7f0bf9857000 (II) RADEONHD(0): [drm] register handle = 0x2fff8000 (II) RADEONHD(0): [dri] Visual configs initialized (II) RADEONHD(0): Attempting to set Engine Clock to 640000 (II) RADEONHD(0): Current Engine Clock: 639060 (II) RADEONHD(0): Current Memory Clock: 959370 (II) RADEONHD(0): Current Chip Voltage: 1123 (II) RADEONHD(0): [DRI] installation complete (II) RADEONHD(0): [drm] Added 32 65536 byte vertex/indirect buffers (II) RADEONHD(0): [drm] Mapped 32 vertex/indirect buffers (II) RADEONHD(0): [drm] dma control initialized, using IRQ 18 (II) RADEONHD(0): [drm] Initialized kernel GART heap manager, 12320768 (II) RADEONHD(0): Direct rendering enabled (II) RADEONHD(0): Using DRM Command Processor (indirect) for acceleration. (II) EXA(0): Offscreen pixmap area of 26836992 bytes (II) EXA(0): Driver registered support for the following operations: (II) Solid (II) Copy (II) Composite (RENDER acceleration) (II) UploadToScreen (II) DownloadFromScreen (==) RADEONHD(0): Backing store disabled (==) RADEONHD(0): Silken mouse enabled (II) RADEONHD(0): RandR 1.2 enabled, ignore the following RandR disabled message. (II) RADEONHD(0): Calling BlankCRTC (II) RADEONHD(0): BlankCRTC Successful (II) RADEONHD(0): Calling BlankCRTC (II) RADEONHD(0): BlankCRTC Successful (II) RADEONHD(0): Calling BlankCRTC (II) RADEONHD(0): BlankCRTC Successful (II) RADEONHD(0): Calling BlankCRTC (II) RADEONHD(0): BlankCRTC Successful (II) RADEONHD(0): Calling BlankCRTC (II) RADEONHD(0): BlankCRTC Successful (II) RADEONHD(0): Calling BlankCRTC (II) RADEONHD(0): BlankCRTC Successful (II) RADEONHD(0): Calling DAC2OutputControl (II) RADEONHD(0): DAC2OutputControl Successful (II) RADEONHD(0): Calling DACBEncoderControl (II) RADEONHD(0): DACBEncoderControl Successful (II) RADEONHD(0): Calling DAC1OutputControl (II) RADEONHD(0): DAC1OutputControl Successful (II) RADEONHD(0): Calling DACAEncoderControl (II) RADEONHD(0): DACAEncoderControl Successful (II) RADEONHD(0): Calling EnableCRTC (II) RADEONHD(0): EnableCRTC Successful (II) RADEONHD(0): Calling EnableCRTCMemReq (II) RADEONHD(0): EnableCRTCMemReq Successful (II) RADEONHD(0): Calling EnableCRTC (II) RADEONHD(0): EnableCRTC Successful (II) RADEONHD(0): Calling EnableCRTCMemReq (II) RADEONHD(0): EnableCRTCMemReq Successful (II) RADEONHD(0): Calling DAC2OutputControl (II) RADEONHD(0): DAC2OutputControl Successful (II) RADEONHD(0): Calling EnableCRTC (II) RADEONHD(0): EnableCRTC Successful (II) RADEONHD(0): Calling EnableCRTCMemReq (II) RADEONHD(0): EnableCRTCMemReq Successful (II) RADEONHD(0): On Crtc 0 Setting 60.0 Hz Mode: Modeline "1920x1200" 154.00 1920 1968 2000 2080 1200 1203 1209 1235 +hsync -vsync (II) RADEONHD(0): Calling SetCRTC_Timing (II) RADEONHD(0): SetCRTC_Timing Successful (II) RADEONHD(0): CallingSetCRTC_OverScan (II) RADEONHD(0): Set CRTC_OverScan Successful (II) RADEONHD(0): Calling EnableScaler (II) RADEONHD(0): EnableScaler Successful (II) RADEONHD(0): Calling SetPixelClock (II) RADEONHD(0): SetPixelClock Successful (II) RADEONHD(0): Calling SelectCRTCSource (II) RADEONHD(0): SelectCRTCSource Successful (II) RADEONHD(0): Calling EnableCRTCMemReq (II) RADEONHD(0): EnableCRTCMemReq Successful (II) RADEONHD(0): Calling EnableCRTC (II) RADEONHD(0): EnableCRTC Successful (II) RADEONHD(0): Calling DACBEncoderControl (II) RADEONHD(0): DACBEncoderControl Successful (II) RADEONHD(0): Calling DAC2OutputControl (II) RADEONHD(0): DAC2OutputControl Successful (II) RADEONHD(0): Calling DAC1OutputControl (II) RADEONHD(0): DAC1OutputControl Successful (II) RADEONHD(0): Calling DACAEncoderControl (II) RADEONHD(0): DACAEncoderControl Successful (II) RADEONHD(0): Calling EnableCRTC (II) RADEONHD(0): EnableCRTC Successful (II) RADEONHD(0): Calling EnableCRTCMemReq (II) RADEONHD(0): EnableCRTCMemReq Successful (II) RADEONHD(0): RHDAudioSetSupported: config 0x60040 codec 0x1 (**) Option "dpms" (**) RADEONHD(0): DPMS enabled (II) RADEONHD(0): Xv: Textured Video initialised. (--) RandR disabled (II) Initializing built-in extension Generic Event Extension (II) Initializing built-in extension SHAPE (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension BIG-REQUESTS (II) Initializing built-in extension SYNC (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension XC-MISC (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFIXES (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (II) Initializing built-in extension COMPOSITE (II) Initializing built-in extension DAMAGE SELinux: Disabled on system, not enabling in X server (II) AIGLX: Screen 0 is not DRI2 capable drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 9, (OK) drmOpenByBusid: Searching for BusID pci:0000:01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 9, (OK) drmOpenByBusid: drmOpenMinor returns 9 drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 (II) AIGLX: enabled GLX_MESA_copy_sub_buffer (II) AIGLX: enabled GLX_SGI_make_current_read (II) AIGLX: enabled GLX_texture_from_pixmap with driver support (II) AIGLX: Loaded and initialized /usr/lib/dri/r600_dri.so (II) GLX: Initialized DRI GL provider for screen 0 (II) RADEONHD(0): Setting screen physical size to 518 x 324 (II) RADEONHD(0): Calling BlankCRTC (II) RADEONHD(0): BlankCRTC Successful (II) RADEONHD(0): Calling BlankCRTC (II) RADEONHD(0): BlankCRTC Successful (II) config/hal: Adding input device AT Translated Set 2 keyboard (II) LoadModule: "evdev" (II) Loading /usr/lib/xorg/modules/input//evdev_drv.so (II) Module evdev: vendor="X.Org Foundation" compiled for 1.6.3, module version = 2.2.5 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 4.0 (**) AT Translated Set 2 keyboard: always reports core events (**) AT Translated Set 2 keyboard: Device: "/dev/input/event2" (II) AT Translated Set 2 keyboard: Found keys (II) AT Translated Set 2 keyboard: Configuring as keyboard (II) XINPUT: Adding extended input device "AT Translated Set 2 keyboard" (type: KEYBOARD) (**) Option "xkb_rules" "evdev" (**) Option "xkb_model" "pc104" (**) Option "xkb_layout" "us" (**) Option "xkb_options" "lv3:ralt_switch" (II) config/hal: Adding input device Power Button (**) Power Button: always reports core events (**) Power Button: Device: "/dev/input/event0" (II) Power Button: Found keys (II) Power Button: Configuring as keyboard (II) XINPUT: Adding extended input device "Power Button" (type: KEYBOARD) (**) Option "xkb_rules" "evdev" (**) Option "xkb_model" "pc104" (**) Option "xkb_layout" "us" (**) Option "xkb_options" "lv3:ralt_switch" (II) config/hal: Adding input device Power Button (**) Power Button: always reports core events (**) Power Button: Device: "/dev/input/event1" (II) Power Button: Found keys (II) Power Button: Configuring as keyboard (II) XINPUT: Adding extended input device "Power Button" (type: KEYBOARD) (**) Option "xkb_rules" "evdev" (**) Option "xkb_model" "pc104" (**) Option "xkb_layout" "us" (**) Option "xkb_options" "lv3:ralt_switch" (II) config/hal: Adding input device ImExPS/2 Generic Explorer Mouse (**) ImExPS/2 Generic Explorer Mouse: always reports core events (**) ImExPS/2 Generic Explorer Mouse: Device: "/dev/input/event3" (II) ImExPS/2 Generic Explorer Mouse: Found 9 mouse buttons (II) ImExPS/2 Generic Explorer Mouse: Found x and y relative axes (II) ImExPS/2 Generic Explorer Mouse: Found scroll wheel(s) (II) ImExPS/2 Generic Explorer Mouse: Configuring as mouse (**) ImExPS/2 Generic Explorer Mouse: YAxisMapping: buttons 4 and 5 (**) ImExPS/2 Generic Explorer Mouse: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 (II) XINPUT: Adding extended input device "ImExPS/2 Generic Explorer Mouse" (type: MOUSE) (**) ImExPS/2 Generic Explorer Mouse: (accel) keeping acceleration scheme 1 (**) ImExPS/2 Generic Explorer Mouse: (accel) filter chain progression: 2.00 (**) ImExPS/2 Generic Explorer Mouse: (accel) filter stage 0: 20.00 ms (**) ImExPS/2 Generic Explorer Mouse: (accel) set acceleration profile 0 (II) ImExPS/2 Generic Explorer Mouse: initialized for relative axes.

Alex Deucher wrote:

...

$ glxgears IRQ's not enabled, falling back to busy waits: 2 0 drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream. See dmesg for more info.

$ dmesg [...] [ 8128.797480] [drm:r600_cs_packet_next_reloc_nomm] *ERROR* No packet3 for relocation for packet at 45. [ 8128.797490] [drm:r600_packet3_check] *ERROR* bad SET_CONTEXT_REG 0x28014 [ 8128.797496] [drm:r600_cs_legacy] *ERROR* Invalid command stream !

Update mesa. The proper fix is in the 7.6 branch and master. That register isn't used yet in mesa and requires a reloc when it eventually will be used.

Hmm, thanks for the info. Looks like commit #37676b39... is the fix? I'm going to investigate how to get my Debian build scripts to capture all of Mesa's files. Once I figure that out -- or give up trying -- I will rebuild Mesa and check 'glxgears' out again. Thanks, Dave W. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Alex Deucher wrote:

On Sun, Nov 15, 2009 at 9:42 PM, Dave Witbrodt wrote:

...

Alex Deucher wrote:

...

...

$ glxgears IRQ's not enabled, falling back to busy waits: 2 0 drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream. See dmesg for more info.

$ dmesg [...] [ 8128.797480] [drm:r600_cs_packet_next_reloc_nomm] *ERROR* No packet3 for relocation for packet at 45. [ 8128.797490] [drm:r600_packet3_check] *ERROR* bad SET_CONTEXT_REG 0x28014 [ 8128.797496] [drm:r600_cs_legacy] *ERROR* Invalid command stream ! Update mesa. The proper fix is in the 7.6 branch and master. That register isn't used yet in mesa and requires a reloc when it eventually will be used. Hmm, thanks for the info. Looks like commit #37676b39... is the fix?

Yes.

OK, I cloned the mesa git repository yesterday, but postponed a rebuild of Mesa until I could look carefully at the warnings from the Debian build scripts. After carefully inspecting the output (which report that some files "installed" to the temporary build directory ended up not being packaged) I discovered that nothing was wrong in this regard: I saved an earlier log of a build of Debian's official mesa-7.6, and the same warnings about missed files appear there. So I updated the Debian changelog to reflect the nonofficial build, and made some new DEBs. Everything that worked before still works... and 'glxgears' now runs OK. Woohoo! I still get the IRQ warning (seen above) when I run 'glxgears': IRQ's not enabled, falling back to busy waits: 2 0 Same happens with 'glxinfo': $ glxinfo |head IRQ's not enabled, falling back to busy waits: 2 0 [...] Not sure if that's anything to be worried about, but other than that I have no issues to report. (Oh, yeah, the XDM login screen looks funny. Nothing else has glitches like that, though.) Well, I've already built kernel 2.6.32-rc7 to support r600 DRI, so it won't be too hard to modify the config to try KMS. My next series of experiments will be to switch from 'radeonhd' to 'radeon', get a working config in 'xorg.conf', and then try for KMS. I'm so sick of UVESAFB and the heavy-handed mode switching that goes on when I switch back and forth between X and VTs! Thanks again, Dave W. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

...

I still get the IRQ warning (seen above) when I run 'glxgears':

IRQ's not enabled, falling back to busy waits: 2 0

Same happens with 'glxinfo':

$ glxinfo |head IRQ's not enabled, falling back to busy waits: 2 0 [...]

This is expected for now as the drm lacks irq support for r6xx+ hardware. The code is written, just pending IP review for release.

Excellent! Thanks, DW -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

On Tue, Nov 17, 2009 at 12:55 AM, Dave Witbrodt wrote:

...

Apart from corruption on the XDM login window (which occurs with and without acceleration), I have had no bugs or negative issues yet.  I haven't tested it much -- windows can be slid with the mouse very rapidly without leaving long trails; DOSBox plays my favorite old game without sound glitches (graphics seem quicker, but haven't played with settings yet); prboom doesn't bog down so much -- but I'm already liking it.  The visual aspects of my desktop machine haven't been this responsive since the proprietary NVidia driver went away (with the dead card this past summer).

I need to make a slight correction here.  Before my GeForce 7950GT died, I was running the 'nvidia' proprietary driver.  Two of the applications I mentioned above, 'prboom' and 'dosbox', could be configured to use OpenGL -- and with 'nvidia' that produced the most satisfying visual results and peformance.

When the GeForce died, I replaced it with a Radeon X1650Pro I had lying around.  After about a month, replaced that with my current card, a Radeon HD 4850.

With the X1650Pro, I had switched to 'radeonhd'.  Both of those apps would not run while configured to use OpenGL, so I reconfigured them to default output options.  I forgot that I had disabled OpenGL with those programs.

Just now, as an experiment, I reconfigured both apps to use OpenGL. What a trip!  They are both totally unusable:  'prboom' looks like it was designed by someone tripping on acid, with the walls (and enemies) a colorful mess and random-colored dots; 'dosbox' just gives me a motionless field of randomly-colored dots.  Nothing can really be done with 'dosbox' under the circumstances, but you can sort of "play" 'prboom':  the enemies appear as moving rectangles of colored dots, as do their shots.  It's sort of like the third Matrix movie, when Neo had his eyes burned out but could still "see" -- just less orangish, and more greens, blues, and reds!  ;)

I take it OpenGL support is not there yet?

GL works fine for most apps. You might try a newer version of mesa as the 3d drivers are part of mesa. If that doesn't help, file a bug: https://bugs.freedesktop.org Alex -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

On Sun, Nov 22, 2009 at 8:47 PM, Dave Witbrodt wrote:

Alex Deucher wrote:

...

On Tue, Nov 17, 2009 at 12:55 AM, Dave Witbrodt wrote:

...

...

Apart from corruption on the XDM login window (which occurs with and without acceleration), I have had no bugs or negative issues yet.  I haven't tested it much -- windows can be slid with the mouse very rapidly without leaving long trails; DOSBox plays my favorite old game without sound glitches (graphics seem quicker, but haven't played with settings yet); prboom doesn't bog down so much -- but I'm already liking it.  The visual aspects of my desktop machine haven't been this responsive since the proprietary NVidia driver went away (with the dead card this past summer).

I need to make a slight correction here.  Before my GeForce 7950GT died, I was running the 'nvidia' proprietary driver.  Two of the applications I mentioned above, 'prboom' and 'dosbox', could be configured to use OpenGL -- and with 'nvidia' that produced the most satisfying visual results and peformance.

When the GeForce died, I replaced it with a Radeon X1650Pro I had lying around.  After about a month, replaced that with my current card, a Radeon HD 4850.

With the X1650Pro, I had switched to 'radeonhd'.  Both of those apps would not run while configured to use OpenGL, so I reconfigured them to default output options.  I forgot that I had disabled OpenGL with those programs.

Just now, as an experiment, I reconfigured both apps to use OpenGL. What a trip!  They are both totally unusable:  'prboom' looks like it was designed by someone tripping on acid, with the walls (and enemies) a colorful mess and random-colored dots; 'dosbox' just gives me a motionless field of randomly-colored dots.  Nothing can really be done with 'dosbox' under the circumstances, but you can sort of "play" 'prboom':  the enemies appear as moving rectangles of colored dots, as do their shots.  It's sort of like the third Matrix movie, when Neo had his eyes burned out but could still "see" -- just less orangish, and more greens, blues, and reds!  ;)

I take it OpenGL support is not there yet?

GL works fine for most apps.  You might try a newer version of mesa as the 3d drivers are part of mesa.  If that doesn't help, file a bug: https://bugs.freedesktop.org

Well, I had just finished building DEBs of Mesa from git, up to date as of Nov. 15, so that I could get r600 DRI and 2D/3D support with radeonhd!  ;)

I even had a problem with RV770 registers not being supported, and you pointed me to a fix you had just committed to the git repo:

...

...

Hmm, thanks for the info.  Looks like commit #37676b39... is the fix?

Yes.

Alex

Anyway, I would like to report a bug on Mesa about OpenGL support not quite working on my Radeon HD 4850.  I have read the "FreeDesktop Bugzilla User's Guide" and have created an account there.  Before I report a bug, can you give me some advice?

1.  The OpenGL corruption looks different on "radeon" versus "radeonhd".  Should I provide screenshots of applications with OpenGL disabled (no corruption) and OpenGL enabled (with corruption)?  If so, should I provide screenshots of corruption with both "radeon" and "radeonhd" (since it appears somewhat different)?

Sure.

2.  I have made some fullscreen screenshots already, but my desktop is 1920x1200 and the resulting files were rather large:  between 600KB and 3.5MB.  Is there a rule about not posting attachments that are too large, or a limit on the size of attachments?

Not sure what the limits are off hand, but if you could just crop an area to show the corruption that would be fine.

3.  Should I make an effort to identify bugs that might be related, or should I leave that to the developers?  (I have already looked around, and haven't seen anything particularly similar to my problems, but my search was far from exhaustive.)

That's fine. We'll mark the bug as a duplicate if it ends up actually being one. Alex -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

On Nov 23, 09 11:37:57 -0500, Dave Witbrodt wrote:

Since sending you this message, I discovered that running those apps with OpenGL enabled spams dmesg/kern.log with errors like this:

[drm:r600_cp_dispatch_texture] *ERROR* Invalid destination offset

Some Googling revealed that you have fixed this in xf86-video-ati in October (commit 5f84636...). My Debian Sid version of "radeon" is 6.12.3 from early September. I cloned the git repository of xf86-video-ati, and reading 'git log' I see that recent commits are starting to depend on X server 1.7+, but I currently am running 1.6.5. Therefore, before filing the

The xserver version should be pretty much irrelevant, but you should use the latest drivers for your tests. Matthias -- Matthias Hopf __ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

On Mon, Nov 23, 2009 at 8:58 PM, Dave Witbrodt wrote:

Matthias Hopf wrote:

...

On Nov 23, 09 11:37:57 -0500, Dave Witbrodt wrote:

...

Since sending you this message, I discovered that running those apps with OpenGL enabled spams dmesg/kern.log with errors like this:

   [drm:r600_cp_dispatch_texture] *ERROR* Invalid destination offset

Some Googling revealed that you have fixed this in xf86-video-ati in October (commit 5f84636...).  My Debian Sid version of "radeon" is 6.12.3 from early September.  I cloned the git repository of xf86-video-ati, and reading 'git log' I see that recent commits are starting to depend on X server 1.7+, but I currently am running 1.6.5. Therefore, before filing the

The xserver version should be pretty much irrelevant, but you should use the latest drivers for your tests.

I was looking at 'git log' for xf86-video-ati (not radeonhd) after I cloned the repo, and saw 2 commits that led me to believe that after early October it was depending on X server 1.7:

   9d59656...    9460ea8...

Granted, these are KMS-related -- but I am about to experiment with KMS, as soon as I can get all of the dependencies lined up.  Possibly I misunderstood the implication of those commits?

Neither xf86-video-ati nor xf86-video-radeonhd require xserver 1.7.x. xf86-video-ati KMS support requires xserver 1.6.x, but you can build against older xservers, you just won't get KMS. Alex -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Dave Witbrodt wrote:

...

...

Anyway, I would like to report a bug on Mesa about OpenGL support not quite working on my Radeon HD 4850. I have read the "FreeDesktop Bugzilla User's Guide" and have created an account there. Before I report a bug, can you give me some advice?

1. The OpenGL corruption looks different on "radeon" versus "radeonhd". Should I provide screenshots of applications with OpenGL disabled (no corruption) and OpenGL enabled (with corruption)? If so, should I provide screenshots of corruption with both "radeon" and "radeonhd" (since it appears somewhat different)?

Sure.

...

2. I have made some fullscreen screenshots already, but my desktop is 1920x1200 and the resulting files were rather large: between 600KB and 3.5MB. Is there a rule about not posting attachments that are too large, or a limit on the size of attachments?

Not sure what the limits are off hand, but if you could just crop an area to show the corruption that would be fine.

...

3. Should I make an effort to identify bugs that might be related, or should I leave that to the developers? (I have already looked around, and haven't seen anything particularly similar to my problems, but my search was far from exhaustive.)

That's fine. We'll mark the bug as a duplicate if it ends up actually being one.

OK, I have to work right now, but when I get home I'll get to work on this. I know about the Intel guide on how to file a good bug report on freedesktop.org, so I'll collect the info recommended there before making the report.

Since sending you this message, I discovered that running those apps with OpenGL enabled spams dmesg/kern.log with errors like this:

[drm:r600_cp_dispatch_texture] *ERROR* Invalid destination offset

Some Googling revealed that you have fixed this in xf86-video-ati in October (commit 5f84636...). My Debian Sid version of "radeon" is 6.12.3 from early September. I cloned the git repository of xf86-video-ati, and reading 'git log' I see that recent commits are starting to depend on X server 1.7+, but I currently am running 1.6.5. Therefore, before filing the report, I want to bump my X server up and build the latest "radeon" to see what affect your bugfix has. If I'm still having a problem, then I head over to freedesktop.org for a new bug report.

Heh, never mind the bug report! Sometime between the release of radeon v6.12.3 and Nov. 23 the cause of my OpenGL corruption was fixed -- most likely the commit to which I referred above. First, I decided to upgrade to X server 1.7.0 from Debian's experimental distribution. Some ABI dependencies imposed by Debian's packaging team prevented me from using any DDX drivers provided before (with 1.6.5), so I had to install a nearly complete suite of development packages so I could build new DEBs for "radeon" and "radeonhd" that would not conflict with the 1.7.0 server. After building the two DDX drivers, I upgraded to Xorg 7.5 (with the 1.7.0 server). Restarting X, using "radeon" (not "radeonhd") gave me an almost perfect Xorg.0.log, encouraging results from 'xdpyinfo' and 'xvinfo', and my OpenGL test apps ('prboom' and 'dosbox') work better with OpenGL enabled than they do with it disabled! Thanks to Alex for the fix (commit 5f84636... in xf86-video-ati)! It's late, and I have to work tomorrow, but tomorrow night I will try "radeonhd" on X server 1.7.0. I expect that the OpenGL corruption will still happen with "radeonhd," unless someone has already ported the fix from "radeon". Next stop: kernel modesetting! Thanks again to all of the xf86-video-{ati,radeonhd} developers, Dave W. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Matthias Hopf wrote:

On Nov 24, 09 01:47:13 -0500, Dave Witbrodt wrote:

...

...

Since sending you this message, I discovered that running those apps with OpenGL enabled spams dmesg/kern.log with errors like this:

[drm:r600_cp_dispatch_texture] *ERROR* Invalid destination offset

Some Googling revealed that you have fixed this in xf86-video-ati in October (commit 5f84636...). My Debian Sid version of "radeon" is 6.12.3

radeonhd shouldn't be affected from that, as we never stored more than the mapped memory in any structure.

...

It's late, and I have to work tomorrow, but tomorrow night I will try "radeonhd" on X server 1.7.0. I expect that the OpenGL corruption will still happen with "radeonhd," unless someone has already ported the fix from "radeon".

If you still see corruptions, it must be a different source from what I read in the code.

Matthias

OK, I'm home from work and I don't have to go back until Monday! First thing I tried when I got home was to copy my working "radeonhd" config to xorg.conf, restart X, and run the apps I'm using to test OpenGL. With OpenGL enabled, 'prboom' runs perfectly with "radeon" but has *massive* screen corruption with "radeonhd" (along with spamming dmesg and kern.log with [drm:r600_cp_dispatch_texture] *ERROR* Invalid destination offset This was the same behavior I experienced with "radeon" 6.12.3, and the same log-spam error messages are described in a bug from October on the fdo bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=24301 I should point out that the corruption shown in the PNG images attached to that bug report are quite mild compared to what I get. However, I guessed that the difference had more to do with how the applications were written -- the extent to which their code hits the bug. (I have some very large, 1920x1200, screenshots if anyone wants to see them; I can easily crop them -- as recommended by Alex Deucher if I had created my own bugzilla report -- to save bandwidth, since they range from 600KB to 4.5MB in their current form.) I assumed that the fix provided by Alex for #24301 (commit 5f84636...) was the commit that caused "radeon" to work correctly with OpenGL for me. However, I do not know that for a fact... and could only determine which commit, or combination of commits, fixed "radeon" for me by doing a 'git bisect' between 6.12.3 and commit 3a1a8b7 on Nov. 23. To be honest, I had planned to move on to KMS once I had prepared a working config for "radeon". As with my previous efforts to build upstream versions of radeonhd, libdrm, and mesa, I want to get to KMS by building DEBs -- and this has been difficult for me since I am not a developer or package maintainer. These days off for the holiday in the US were my big chance to align the entrails and try out KMS. However, if it will help the "radeonhd" team, I am willing to bisect "radeon" to identify the exact commit(s) that give me working OpenGL on my RV770 card. Matthias: above you assert that "radeonhd shouldn't be affected from that" -- and maybe it *shouldn't* be -- but I can tell you that it *is* on my hardware, and I have logs full of those error messages even though I am running "radeonhd" instead of "radeon" at the moment. How would you like me to proceed? Shall I: - file a bug report on radeonhd? - bisect "radeon" until we know the specific commit? - test patches from radeonhd developers? I am willing to do any or all of these things, and anything else anyone can think of, to help make radeonhd better. Just let me know. With much appreciation for your efforts, Dave W. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Matthias Hopf wrote:

On Nov 24, 09 19:53:04 -0500, Dave Witbrodt wrote:

...

...

...

...

[drm:r600_cp_dispatch_texture] *ERROR* Invalid destination offset Some Googling revealed that you have fixed this in xf86-video-ati in October (commit 5f84636...). My Debian Sid version of "radeon" is 6.12.3

radeonhd shouldn't be affected from that, as we never stored more than the mapped memory in any structure. First thing I tried when I got home was to copy my working "radeonhd" config to xorg.conf, restart X, and run the apps I'm using to test OpenGL. With OpenGL enabled, 'prboom' runs perfectly with "radeon" but has *massive* screen corruption with "radeonhd" (along with spamming dmesg and kern.log with

[drm:r600_cp_dispatch_texture] *ERROR* Invalid destination offset

Ok, then we have some regression, maybe due to the ioctl rework in DRM. We haven't touched the drm code in radeonhd since then, heck, I didn't even have the time to *ever* test r6xx 3D support :-(((

But I very much believe that it is NOT the memory size issue that has been fixed in radeon in commit 5f84636, just it has the same effect.

Thanks for testing!

Let me know if there is more that I can do.

...

I assumed that the fix provided by Alex for #24301 (commit 5f84636...) was the commit that caused "radeon" to work correctly with OpenGL for me. However, I do not know that for a fact... and could only determine which commit, or combination of commits, fixed "radeon" for me by doing a 'git bisect' between 6.12.3 and commit 3a1a8b7 on Nov. 23.

This might help, but not necessarily. So I don't want to ask you to do this, given that I won't have time to look into this in the short term. I'll come back to you if we still need it.

OK... I offered! ....

...

running "radeonhd" instead of "radeon" at the moment. How would you like me to proceed? Shall I:

- file a bug report on radeonhd?

A bug report would be appreciated - so the issue is documented. Probably mostly copy-and-paste from the mails. Could be there is already a bug for this issue, but I consider your tests the best so far. Please document all driver versions (git commit ids or released versions) you tested.

http://bugs.freedesktop.org/show_bug.cgi?id=25309 My apologies on the size of the 4 attached screenshots. My screenshot app had made PNG files, which were 600KB - 4.5 MB in size. I had never used imagemagick 'convert' before, and was quite satisfied when the first 3 images became smaller than 1 MB after conversion to JPG. But Bugzilla rejected my 4th screenshot: no non-patch attachments larger than 1 MB allowed, and the JPG was 1.010 MB. After a quick reading of the documentation for 'convert', I discovered the "-quality" option. Using "-quality 60" made the 4th screenshot 1/10 the size in bytes of the original PNG. By then I had already attached the first 3 shots! (They could be made much smaller, without seriously impacting image quality.) Upon request, I can resubmit those first 3 images... now that I have read a little about 'convert'. HTH, Dave W. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

...

...

...

...

"Dave" == Dave Witbrodt writes:

...

Apart from corruption on the XDM login window (which occurs with and without acceleration), I have had no bugs or negative issues yet. I haven't tested it much -- windows can be slid with the mouse very rapidly without leaving long trails; DOSBox plays my favorite old game without sound glitches (graphics seem quicker, but haven't played with settings yet); prboom doesn't bog down so much -- but I'm already liking it. The visual aspects of my desktop machine haven't been this responsive since the proprietary NVidia driver went away (with the dead card this past summer).

Dave> I need to make a slight correction here. Before my GeForce Dave> 7950GT died, I was running the 'nvidia' proprietary driver. Two Dave> of the applications I mentioned above, 'prboom' and 'dosbox', Dave> could be configured to use OpenGL -- and with 'nvidia' that Dave> produced the most satisfying visual results and peformance. Dave> When the GeForce died, I replaced it with a Radeon X1650Pro I Dave> had lying around. After about a month, replaced that with my Dave> current card, a Radeon HD 4850. I think I've got the same card in my system now, though PCIe based. Could you share your notes and build scripts with the rest of us so we can build and test .debs more easily? I'm running Ubuntu 9.10, but happy to break my system to get better performance. Oh wait, I've got an X1250, R500 card. In any case, your notes (either emailed or put into the wiki) would be a great help! Also, when I lock my display, and kid seven year old switches users so he can play Super Mario Chronicles, the performance is terrible. Is this because user switching doesn't allow sharing of the Hardware for video acceleration? I seem to remember something about this, but Ican't find it in my old emails currently. Thanks, John -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

...

...

...

...

"Alex" == Alex Deucher writes:

Alex> On Tue, Nov 17, 2009 at 3:27 PM, John Stoffel wrote:

...

...

...

...

...

> "Dave" == Dave Witbrodt writes:

...

Also, when I lock my display, and kid seven year old switches users so he can play Super Mario Chronicles, the performance is terrible.  Is this because user switching doesn't allow sharing of the Hardware for video acceleration?  I seem to remember something about this, but Ican't find it in my old emails currently.

Alex> DRI1 only supports one accelerated instance. KMS/DRI2 supports Alex> multiple accelerated sessions. So if I go with 2.6.32-rcN I should be all set? Or do I need to upgrade MESA, libdrm, etc as well? Any ubuntu repositories with pre-built debs for x86_64 available? I'd be happy to test, I just don't have time for git/build/install cycle right now. John -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

...

...

...

...

"Alex" == Alex Deucher writes:

Alex> On Wed, Nov 18, 2009 at 4:16 PM, John Stoffel wrote:

...

...

...

...

...

> "Alex" == Alex Deucher writes:

Alex> On Tue, Nov 17, 2009 at 3:27 PM, John Stoffel wrote:

...

...

...

...

...

>>> "Dave" == Dave Witbrodt writes:

...

...

Also, when I lock my display, and kid seven year old switches users so he can play Super Mario Chronicles, the performance is terrible.  Is this because user switching doesn't allow sharing of the Hardware for video acceleration?  I seem to remember something about this, but Ican't find it in my old emails currently.

Alex> DRI1 only supports one accelerated instance.  KMS/DRI2 supports Alex> multiple accelerated sessions.

...

So if I go with 2.6.32-rcN I should be all set?  Or do I need to upgrade MESA, libdrm, etc as well?

Alex> You need xf86-video-ati and mesa with kms support and Alex> libdrm_radeon. I believe karmic has this already. if not, it's Alex> available via ppa. radeonhd doesn't support kms at the moment. This is what I've got currently installed:

dpkg-query -l | grep radeon ii libdrm-radeon1 2.4.14-1ubuntu1 Userspace interface to radeon-specific kernel rendering services ii xserver-xorg-video-radeon 1:6.12.99+git20090929.7968e1fb-0ubuntu1 X.Org X server -- ATI Radeon display driver ii xserver-xorg-video-radeon-dbg 1:6.12.99+git20090929.7968e1fb-0ubuntu1 X.Org X server -- ATI Radeon display driver (debugging symbols)

So I suspect I need to get ppa setup so I can get newer versions. Also, there's no xf86- on Ubuntu, are you sure you don't mean the xserver-xorg-driver-radeon like I have above? *grin* Thanks, John -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

...

...

...

...

"Alex" == Alex Deucher writes:

Alex> On Wed, Nov 18, 2009 at 4:35 PM, John Stoffel wrote:

...

...

...

...

...

> "Alex" == Alex Deucher writes:

Alex> On Wed, Nov 18, 2009 at 4:16 PM, John Stoffel wrote:

...

...

...

...

...

>>> "Alex" == Alex Deucher writes:

Alex> On Tue, Nov 17, 2009 at 3:27 PM, John Stoffel wrote:

...

...

...

>>>>> "Dave" == Dave Witbrodt writes:

...

Also, when I lock my display, and kid seven year old switches users so he can play Super Mario Chronicles, the performance is terrible.  Is this because user switching doesn't allow sharing of the Hardware for video acceleration?  I seem to remember something about this, but Ican't find it in my old emails currently.

Alex> DRI1 only supports one accelerated instance.  KMS/DRI2 supports Alex> multiple accelerated sessions.

...

So if I go with 2.6.32-rcN I should be all set?  Or do I need to upgrade MESA, libdrm, etc as well?

Alex> You need xf86-video-ati and mesa with kms support and Alex> libdrm_radeon.  I believe karmic has this already.  if not, it's Alex> available via ppa.  radeonhd doesn't support kms at the moment.

...

This is what I've got currently installed:

  > dpkg-query -l | grep radeon   ii  libdrm-radeon1                              2.4.14-1ubuntu1   Userspace interface to radeon-specific kernel rendering services   ii  xserver-xorg-video-radeon   1:6.12.99+git20090929.7968e1fb-0ubuntu1    X.Org X server -- ATI   Radeon display driver   ii  xserver-xorg-video-radeon-dbg   1:6.12.99+git20090929.7968e1fb-0ubuntu1    X.Org X server -- ATI   Radeon display driver (debugging symbols)

So I suspect I need to get ppa setup so I can get newer versions. Also, there's no xf86- on Ubuntu, are you sure you don't mean the xserver-xorg-driver-radeon like I have above?  *grin*

Alex> The actual driver is called xf86-video-ati, but each distro Alex> packages it differently. The ones you have should work. You'll Alex> need an updated kernel and mesa for r6xx/r7xx 3D however. My video card is an R500: > dmesg | grep '\[drm\]' [ 17.431279] [drm] Initialized drm 1.1.0 20060810 [ 17.594650] [drm] radeon defaulting to userspace modesetting. [ 17.604268] [drm] Initialized radeon 1.31.0 20080528 for 0000:03:00.0 on minor 0 [ 17.908555] [drm] Setting GART location based on new memory map [ 17.908995] [drm] Loading R500 Microcode [ 17.968299] [drm] Num pipes: 1 [ 17.968307] [drm] writeback test succeeded in 1 usecs [219424.146341] [drm] Num pipes: 1 [440400.500365] [drm] Num pipes: 1 I've got 2.6.32-rc4 running right now with KMS enabled, along with the modules: radeon 575832 2 ttm 42492 1 radeon drm_kms_helper 27692 1 radeon drm 183464 5 radeon,ttm,drm_kms_helper fb 40175 2 radeon,drm_kms_helper i2c_algo_bit 5456 1 radeon cfbcopyarea 3345 1 radeon cfbimgblt 2493 1 radeon cfbfillrect 3837 1 radeon But I suspect I need to update userspace to something much newer/bleeding edge. Anyone got the PPA URL handy? Otherwise I'll poke at it later tonight at home and see what I can find. Oh wait, it looks like I might have it already: > cat /etc/apt/sources.list.d/xorg-edgers deb http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu karmic main deb-src http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu karmic main But I get those are wrong and not working right now. Ugh. Thanks for all your help Alex! John -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org