Announcement

Collapse
No announcement yet.

Artifacts on Radeon 4850 with oss ati driver

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Can a mod or somebody move this to the appropriate forum?

    I have a bit of an update as well. I installed Arch Linux, and it gave me the same problem as I was getting on Gentoo. So I installed Fedora instead because the LiveCD worked for me. After installing it, I was greeted with the same problem again.

    After logging on, I opened up the Display preferences, and actually setting up my resolution properly fixed the artifacts. 1280x1024 on the left screen, 1680x1050 on the right. I believe Gentoo and Arch were doing 1280x1024 on both screens. Might have had something to do with Mirroring?

    On Gentoo, I did not have my resolutions set up properly in xorg.conf, and I didn't have that set up in Arch either. Maybe somebody can give me a hand with Xinerama in xorg.conf?
    Last edited by pvtcupcakes; 08 July 2009, 08:10 PM.

    Comment


    • #12
      Good catch. The artifacts you were getting didn't match anything I had seen before from a driver issue but I had no idea what the real problem might be.
      Test signature

      Comment


      • #13
        Okay, I unplugged my second monitor and restarted Gentoo and it works fine now.

        I think this is definately an issue with the ati driver and mirroring two screens of different resolutions. I'm not sure why it happens.

        Bridgman, do you think your or somebody else in the Radeon team could test this out? I've had the issue on three different distros, so it seems to be repeatable. Happens on ati git, and 6.12.2. Linux 2.6.29 through 2.6.31-rc2, and several versions of other packages.

        Comment


        • #14
          Just to be clear, the issue here is that both monitors come up at 1280x1024 when you were expecting the second screen to come up at 1680x1050 ?

          I imagine what you are seeing is expected behavior when booting with two screens but no Virtual line in xorg.conf. I think you need a Virtual line in xorg.conf if you want the two monitors to come up side-by-side without having to play with resolution settings.

          There's a pretty good guide on modern X configuration at :

          http://wiki.debian.org/XStrikeForce/HowToRandR12

          The key point is that the "Modes" mechanism you're using in xorg.conf has been more or less replaced with a new set of options, and those are what I expect the radeon driver uses.
          Test signature

          Comment


          • #15
            Originally posted by bridgman View Post
            Just to be clear, the issue here is that both monitors come up at 1280x1024 when you were expecting the second screen to come up at 1680x1050 ?

            I imagine what you are seeing is expected behavior when booting with two screens but no Virtual line in xorg.conf. I think you need a Virtual line in xorg.conf if you want the two monitors to come up side-by-side without having to play with resolution settings.

            There's a pretty good guide on modern X configuration at :

            http://wiki.debian.org/XStrikeForce/HowToRandR12

            The key point is that the "Modes" mechanism you're using in xorg.conf has been more or less replaced with a new set of options, and those are what I expect the radeon driver uses.
            Thanks, I'll take a look at this.

            But with Arch, I didn't mess with the Screen Section in xorg.conf. I let xorg 1.6 auto-generate it. All I did was Modules, Device and DRI.
            And I didn't touch the xorg.conf in Fedora at all, that behavior was default.

            I still think it's a bug in the driver, but Xorg doesn't try to avoid it when auto-generating xorg.conf, which causes problems for Fedora.

            Comment


            • #16
              AFAIK the autogenerated Xorg is enough to make your screens light up, not to be optimal.

              My understanding is that the move to KMS (with the ability to on-the-fly reallocate the frame buffer) has the potential to make all this easier. That's where most of the dev attention is focused these days.
              Test signature

              Comment


              • #17
                Originally posted by bridgman View Post
                AFAIK the autogenerated Xorg is enough to make your screens light up, not to be optimal.

                My understanding is that the move to KMS (with the ability to on-the-fly reallocate the frame buffer) has the potential to make all this easier. That's where most of the dev attention is focused these days.
                The xorg tutorial you linked to worked well. Thanks again.

                And too bad my 4850 won't be supported by KMS in 2.6.31. I'm crossing my fingers on 2.6.32. I've got KMS on my laptop running an Intel chip and it's nice just for the fast VT-switching.

                Comment

                Working...
                X