Announcement

Collapse
No announcement yet.

RandR 1.3 Arrives With Panning Support

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

  • RandR 1.3 Arrives With Panning Support

    Phoronix: RandR 1.3 Arrives With Panning Support

    RandR 1.3, the first major update to the X.Org Resize and Rotate extension since it picked up support for display hot-plugging and other goodies, has been finalized. RandR 1.3 has been in planning since last year, but over the past few weeks has really come together and is now ready for introduction in X Server 1.6. Back in January there was talk of GPU object support for RandR 1.3 and then in late October the RandR properties support started to come together...

    http://www.phoronix.com/vr.php?view=Njg4Mw

  • #2
    I'm not sure what the significance of this is.

    One way I can try asking for more info is: Will XRandR panning make Compiz's enhanced zoom plug-in obsolete, less useful, or improve it?

    Comment


    • #3
      I wish that the area visible in on all monitors would be the total area there is (the way windoze those it). Right know I often attach a 1280x1024 monitor to my 1280x800 laptop. Then, when I put a cd in the drive or any other media and the first left column on my destkop if full with icons the new icon is in the part of the screen that is not shown on any monitor...that's annoying.

      Comment


      • #4
        Originally posted by szczerb View Post
        I wish that the area visible in on all monitors would be the total area there is (the way windoze those it). Right know I often attach a 1280x1024 monitor to my 1280x800 laptop. Then, when I put a cd in the drive or any other media and the first left column on my destkop if full with icons the new icon is in the part of the screen that is not shown on any monitor...that's annoying.
        Are you talking about a clone that is scaled to the new monitors resolution?

        I reckon that would be great as well.

        Comment


        • #5
          Not really. I need two seperate screens. But with RandR 1.2 and xorg-server-1.5.2 you still can only have a rectangular virtual destop on which you place your screens. So if one of them has higher vertical resolution (which is my, and I thinke the usual, case) then you get some part of your desktop not displayed on any screen. Maximising and fullscreening fortunately works fine, so it's just the new icons that go missing.

          BTW cloning a 1280x800 with scaling to a 1280x1024 (or the other way around) would look pretty awfull.

          Comment


          • #6
            Originally posted by szczerb View Post
            Not really. I need two seperate screens. But with RandR 1.2 and xorg-server-1.5.2 you still can only have a rectangular virtual destop on which you place your screens. So if one of them has higher vertical resolution (which is my, and I thinke the usual, case) then you get some part of your desktop not displayed on any screen. Maximising and fullscreening fortunately works fine, so it's just the new icons that go missing.
            Windows actually works in a similar way - all your screens are part of a rectangular virtual desktop. (It's just that most Windows application are aware of this that need to be.) Your problem is that whatever desktop you're using isn't fully multihead-friendly, which isn't really an X problem at all.

            Comment


            • #7
              I had panning, ie virtual desktop with XFree 4.3.0..
              Sometimes I wonder if it really was worth it breaking everything and then bringing the same features slowly back.
              Is multicard yet even supported (again..)?

              Comment


              • #8
                It probably is worth it. If there were enough resources working on the X framework and drivers the new implementation would include all the features of the old before release, but that has never been the case AFAIK. The number of developers and the time they spend seems to have grown over the years, but so has the complexity and functionality of X. The argument is that what you gain by making the changes is more important to most users than what you lose... and I think that has been the case most of the time.

                The big deal with GPU Objects is that it adds the ability to address and control more than one card. Actually making multicard *work* will require more effort -- take a look at Ajax's "shatter" for more info. I am hearing conflicting views about how much work will be required though, so there may be an easier path to multicard support. That said, something like shatter (or something equivalent in Compiz itself) will be needed if you want to run Compiz on anything but the newest cards, since right now the total screen area (sum of all displays) is limited to the maximum texture size of the GPU's 3D engine and on a lot of GPUs that limit is 2048x2048 pixels.
                Last edited by bridgman; 11-29-2008, 10:09 AM.

                Comment


                • #9
                  Originally posted by makomk View Post
                  Windows actually works in a similar way - all your screens are part of a rectangular virtual desktop. (It's just that most Windows application are aware of this that need to be.) Your problem is that whatever desktop you're using isn't fully multihead-friendly, which isn't really an X problem at all.
                  That's good to know. I'm using gnome-2.22. 2.24 will be gentoo-stable soon and I hope that changes something. I'll try rebuilding it without xinerama support - maybe that will change this annoying behaviour.

                  BTW Another thing I knew is gnome's fault is that I can't set my laptop's LCD as primary display so when I plug something else, my toolbars go to that new screen (that's really annoying when I connect a 640x480 TV with VGA (DSUB))

                  Comment


                  • #10
                    The argument is that what you gain by making the changes is more important to most users than what you lose...
                    Is modularity that great from the user's standpoint?
                    Is a constantly breaking API that leaves users at the command line after an update that great?
                    Was having to edit XF86Config-4.conf really that bad on the end user?

                    It seems to me that most changes to X.org have happened because a developer decided to make them and not because it was better for the users.

                    Comment


                    • #11
                      It's certainly fair to say that most changes have happened because a developer thought it was better for the users, which may or may not turn out to be true.

                      What makes it complicated is that a lot of the changes you see are made not because *that* change is better for the users, but because the change is a pre-requisite for a *later* change which will be better for users.

                      DRI2 and memory management are a good example. They're a big pain in the butt for users and for distros, 'cause they just change a bunch of APIs and muck up builds without making anything visibly better.

                      But -- what both changes do is enable some other features (which have not been implemented yet) which users *do* definitely want -- flicker-free 3D under Compiz, higher levels of GL support, better performance, more reliable operation etc...

                      It would be nice if there was some kind of ongoing changelog for Xorg written from a user perspective. At minimum that would separate out the changes which are supposed to be better (so one can speak up if they don't seem to be an improvement) from changes which add pain in the short term but which enable a brighter future.

                      Or you could have a single dictator make all the decisions about what should be changed, which would probably give you a much cleaner roadmap and a more consistent vision of where X is going, but the open source community tends to be pretty intolerant of dictators unless they do most of the coding themselves.

                      Comment


                      • #12
                        Originally posted by bridgman View Post
                        But -- what both changes do is enable some other features (which have not been implemented yet) which users *do* definitely want -- flicker-free 3D under Compiz, higher levels of GL support, better performance, more reliable operation etc...

                        That's what is most frustrating about X.org, changes made for non-existent features. Sure its great that you'll be able to provide flicker-free wobbly windows sometime in the future, meanwhile those of us that just want to get some work done and require a stable display are stuck with something that doesn't seem to be an improvement over the past and in many cases has regressed as legacy nvidia blob users found out in the last Ubuntu release.

                        Sure progress is important, but changing things in /head (and therefore a stable release) for non-existent features is basically just being a dick to those people whose desktops were broken by those changes.

                        Comment


                        • #13
                          I guess I don't understand why anyone would pick up changes from head unless they were participating in development either as a developer or as a tester. Releases are for users; head is for ongoing development and for verifying specific bug fixes.

                          The most invasive changes (eg the current KMS and MM work) is typically done in a separate branch until the APIs stabilize. As far as I know anyone complaining about instability there is picking up the code from developers' private branches, or from F10 which also includes the very latest development code.

                          One thing I don't understand is your comment about "changing things in head (and therefore a stable release)". The tips (head) and stable releases are usually two different things.

                          Comment


                          • #14
                            Originally posted by bridgman View Post
                            One thing I don't understand is your comment about "changing things in head (and therefore a stable release)". The tips (head) and stable releases are usually two different things.
                            Stable releases come from head, what's difficult to understand about that? What's difficult to understand that changes for non-existent features shouldn't make a release under any circumstance?

                            Comment


                            • #15
                              AFAIK stable releases either come from head at specific *times* (usually after a bug-fixing frenzy) or from branches created to stabilize the code while work proceeds in master. The ddx drivers tend to take the first approach, mesa tends to take the second approach. I understand what you are saying, I just don't fully agree with it

                              Really invasive changes get pushed off to temporary branches (eg the KMS/GEM work being done now), but in cases where a few things need to come together in order it is not uncommon to put the individual pieces in when they are ready to allow broader testing.

                              I suspect we are talking about two different things here, which is why we are disagreeing. If you are saying "half-finished work should not be dropped into master where it can break things" I think everyone would agree. What I'm talking about, however, is a multi-stage project where base functionality needs to be added into one component and made broadly available so that other components can be modified to make use of the new functionality and tested offline before *those* changes are pushed to master.

                              It all depends on whether or not the new code can be kept cleanly isolated from existing functionality. Adding partial support for a new GPU is usually pretty safe to add, since the new code only runs when the new GPU is plugged in. Same for new APIs if you aren't taking out the old API - you can test the existing functionality pretty well before pushing any modifications to existing code required to support the new API.

                              Other projects require making high-risk changes to existing functionality, and in those cases working in a temporary branch to protect master is the right thing to do. Usually the right decisions are made up front, but I'm sure there are occasional bad calls.
                              Last edited by bridgman; 12-03-2008, 01:14 PM.

                              Comment

                              Working...
                              X