Announcement

Collapse
No announcement yet.

It Looks Like X.Org 7.5 Will Be Released Late

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

  • #41
    As a Debian Experimental user with the latest xorg-edgers packages from Ubuntu installed, I must say that as of a couple days ago, X is now perfect. Two years ago it was pathetic: I could not play Torcs even at the lowest resolution with a Core2Duo and a G33 chipset, with a frame rate slower than 1 fps.
    Two days ago not only could I play it perfectly smoothly at 1280*1024, but for the first time (thanks to this smoothness) I won the Alpine race at the amateur level on my keyboard.
    Now that I am a champion, it is obvious X is a champion too!

    Comment


    • #42
      The Intel driver has gotten orders of magnitude better. My g45 is faster in linux than windows with opengl (nexuiz). Just some stability problems to work out, and maybe gallium will help even more.

      Comment


      • #43
        Originally posted by DebianAroundParis View Post
        As a Debian Experimental user with the latest xorg-edgers packages from Ubuntu installed, I must say that as of a couple days ago, X is now perfect.!
        I dream that in a couple of years you could well use Debian stable and *still* have basic functionality with open drivers for your card which would at that point mean working and relatively fast 2D/3D accel. ^^ I'd suspect it would probably decrease the demand for pushing new X.org versions out a bit that average user actually gets what they need even with older versions of the components. You may call me a dreamer but hey, is it a crime? :3

        Comment


        • #44
          Originally posted by nanonyme View Post
          I dream that in a couple of years you could well use Debian stable and *still* have basic functionality with open drivers for your card which would at that point mean working and relatively fast 2D/3D accel. ^^ I'd suspect it would probably decrease the demand for pushing new X.org versions out a bit that average user actually gets what they need even with older versions of the components. You may call me a dreamer but hey, is it a crime? :3
          If you have a 5 year old GPU, since debian stable doesn't backport pci ids or anything like, you won't get any suppor for newer gpus unless that sorta stuff takes place.

          Like RHEL5.4 supports newer GPUs out of the box for 2D way better, but that stuff doesn't come for free.

          Comment


          • #45
            Originally posted by airlied View Post
            If you have a 5 year old GPU, since debian stable doesn't backport pci ids or anything like, you won't get any suppor for newer gpus unless that sorta stuff takes place.

            Like RHEL5.4 supports newer GPUs out of the box for 2D way better, but that stuff doesn't come for free.
            You know, in your case it's a bit hard to say how much of the observations considering RHEL and its competitor distros are objective and how much are not. That pci id thing is a problem though admittebly.
            I was mostly pondering about the up-coming infra though, like that on radeon side r6xx/r7xx 3D gets done, KMS+ttm gets done. I mean, support's not going to just magically vanish anywhere and sooner or later (we might be talking of years again) even Debian stable should have working OpenGL rendering.
            I'd personally prefer pci id listings to get somehow versioned separately so distros could integrate pci id's for new GPU's faster (as they are unlikely to break existing functionality) without actually updating the driver to a newer version where possible. (since changes in other parts of the driver might cause more breakages) Something more dynamic in the area would be imo neat.
            Edit: I realize the idea means distros get left without chip-specific fixes that are put in arbitrary git versions but it's meant as more of a compromise than a real win-win scenario anyway.
            Last edited by nanonyme; 17 July 2009, 09:23 PM.

            Comment


            • #46
              Originally posted by nanonyme View Post
              You know, in your case it's a bit hard to say how much of the observations considering RHEL and its competitor distros are objective and how much are not. That pci id thing is a problem though admittebly.
              I was mostly pondering about the up-coming infra though, like that on radeon side r6xx/r7xx 3D gets done, KMS+ttm gets done. I mean, support's not going to just magically vanish anywhere and sooner or later (we might be talking of years again) even Debian stable should have working OpenGL rendering.
              I'd personally prefer pci id listings to get somehow versioned separately so distros could integrate pci id's for new GPU's faster (as they are unlikely to break existing functionality) without actually updating the driver to a newer version where possible. (since changes in other parts of the driver might cause more breakages) Something more dynamic in the area would be imo neat.
              Edit: I realize the idea means distros get left without chip-specific fixes that are put in arbitrary git versions but it's meant as more of a compromise than a real win-win scenario anyway.

              well I'd expect SLES and the RHEL clones would also provide that support.

              But the problem with Debian stable is the point it forks at is fine unless you need to use hw later than date, thats the decision Debian maintainers make, but it means I don't think you'll ever want to run Debian stable anywhere near a GPU that is modern when Debian stable is released. Yes your 2 year old GPU will continue to work, the GPU that comes out 3-4 months before Debian stable probably will never work.

              Backporting pci-ids blindly isn't an answer, otherwise everyone would do it. I also can think of very few GPUs where that would actually have provided a useful experience, at least from the Intel/AMD side.

              Dave.

              Comment


              • #47
                Originally posted by t.s. View Post
                You're bluffing, right? 1, 2, 3, 4, 5, 6, 7, 8, 9, 10.. Ten Companies, and more..
                hm.. IF ONLY each companies providing 3 manpower, then X.org have about 30 devs, + other developers.

                Btw, how much the minimum number of devs do X.org have so that X.org can have a constant and not-late release?
                It's not a matter of numbers. You can have an infinite number of developers and still not meet schedule, or have only 2 people and meet it on the date every time. It's a matter of priorities of those people involved. If you have different priorities you'd like to see achieved, then get more involved.

                Comment

                Working...
                X