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...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #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; 29 November 2008, 11:09 AM.
                Test signature

                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

                    Working...
                    X