xrandr --scale restricts area in which mouse moves

Reported by josvanr on 2011-10-28
This bug affects 33 people
Affects Status Importance Assigned to Milestone
X.Org X server
xorg-server (Ubuntu)

Bug Description

SRU Request:

A bug in the version of xorg-server in precise prevents users from scaling screen resolution. When attempting to do so, as was possible in Natty and earlier, and which is possible in Quantal+, the mouse pointer remains locked inside the old resolution. This prevents users of small screens such as netbooks from scaling to a greater screen resolution.

[Test Case]
- On a netbook with intel chipset, such as a Dell Mini 9 or 10, scale the display by using the following command:

xrandr --output LVDS1 --panning 1280x750 --scale 1.25x1.25

See if the mouse moves correctly to all screen extremities, and is not confined by a transparent border at 1024x600

[Regression Potential]
This is fixed with a patch backported from the xorg-server version in Quantal. In theory it should just affect screen which are scaled and panned, which is uncommon. If so, the patch can be backed out.

Original Bug Description:
in kubuntu (and ubuntu) 11.04 i used to enlarge my laptop screen like so

xrandr --output LVDS1 --scale 1.2x1.2

this worked fine: the desktop scaled to larger size correctly .
 After upgrading to 11.10, in kde the desktop still resizes
correctly, but the movement of the mouse is restricted to an area equal to
the screen size *before* issuing the scaling command. .. Ie let's say
the mode is 1366x768 and I do xrandr --output LVDS1 --scale 1.2x1.2 the
screen size changes to 1640x922 but the mouse moves in an area the size of
1366x768 in the top left of the screen and then 'hits a wall' preventing
it to move. I also tried ubuntu 11.10 with gnome: here the screen also
resizes, but I have the same issue with the mouse, and the extended area
of the desktop is black...

Some time ago there was a similar issue, which was resolved later. Now it seems
to be back...

jos@samsungsucks:~$ lsb_release -rd
Description: Ubuntu 11.10
Release: 11.10

jos@samsungsucks:~$ xrandr --version
xrandr program version 1.3.5
Server reports RandR version 1.3

Filing this bug to facilitate the fix entering the pipeline

CRTC bound checking was introduced to make sure windows do not slide into hidden areas, when multiple screens map to the framebuffer. It seems to be interfering with Panning.

Panning does not work. The screen should pan when the mouse is moved outside the visible area on the screen, when the visible part of the screen on the CRTC is part of a larger configured framebuffer screen.

Use the following to configure panning
  xrandr --fb 1600x1200 --output LVDS --mode 1280x800 --panning 1600x1200
Use the following to restore
  xrandr --fb 1280x800 --output LVDS --mode 1280x800 --panning 1280x800
Move the mouse to the CRTC edge and expect to see screen to pan, but pan does not happen, because the mouse is constrained to remain in the CRTC bounds.

Use case:
laptops have small screens.
Configure panning to use a larger screen on the small DISPLAY.
Use remote desktop such as VNC, using vino, or module vnc, and access the desktop more comfortably on a larger workstation screen.

Downstream bug.

A patch has been proposed, but seems not to be moving.
> Rui Matos 2011-07-02 08:10:36 EDT
> This a bug in the X server. I've submitted a patch upstream[1] but it's still
> waiting review.
> [1] http://lists.x.org/archives/xorg-devel/2011-June/023715.html

Linux sirius.localdomain 2.6.40-4.fc15.x86_64 #1 SMP Fri Jul 29 18:46:53 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
01:00.0 VGA compatible controller: ATI Technologies Inc Mobility Radeon HD 3400 Series
radeon driver.

panning on xrandr works momentarily, then freezes the system.
xrandr 3.5 and earlier, Slackware 3.1 and later (Slackware 3.0 and earlier use
xorg.conf and panning works without xrandr.)

still present in xorg-x11-server-Xorg-1.10.4-1.fc15.x86_64

Mouse shouldn't move into area outside the monitors

somehow seems like a possible cause of this.

My particular use case is when using my Netbook (native res. 1024x600) with an external projector (native res. 1024x768) with the displays set up as clones.

I want to be able to move the mouse into the area below/above the Netbook screen and have it pan to give access to the area which is only visible on the projector screen. Currently moving the mouse to the bottom edge of the screen doesn't pan, so if, eg. while typing my edit cursor has moved into the bottom 168 pixels of the projector screen I end up typing blind on the Netbook and having to look over my shoulder at the screen behind me.

(In reply to comment #0)
> A patch has been proposed, but seems not to be moving.
> > Rui Matos 2011-07-02 08:10:36 EDT
> >
> > This a bug in the X server. I've submitted a patch upstream[1] but it's still
> > waiting review.
> >
> > [1] http://lists.x.org/archives/xorg-devel/2011-June/023715.html

Yeah, I later submitted another patch which also fixes this issue in a different way:


There's no action on either of them though.

RandR panning is a really niche and unloved feature which I can understand as it makes the X server more complex than it could be. The panning functionality really belongs in a client application like a compositor.

(Reply to comment #5)
> Yeah, I later submitted another patch which also fixes this issue in a
> different way:
> http://patchwork.freedesktop.org/patch/6488/
> There's no action on either of them though.
> RandR panning is a really niche and unloved feature which I can understand as
> it makes the X server more complex than it could be. The panning functionality
> really belongs in a client application like a compositor.

I tried the patch and it works with panning, but not for scaling.
Ex. xrandr --output LVDS1 --scale 1.5x1.5

With scaling, the mouse is still confined to the native resolution's bounds.

I like the much more the approach in the above, as it tries to harness whatever the benefits claimed by adherents of mouse-bound check, may be.

I noticed the comment 'v2: Since crtc_bounds() is called a lot ...' means that the crtc_bounds() is called several times perhaps by mouse bound check code.
and speculate if that the reason for the alternate approach of disabling bound checking if panning is configured ?
am seeing code on

I was wondering if the compute once, query many paradigm can be employed here.
as the crtc bounds change only when some event changes the screen size.
so crtc_bounds() may return a pre-computed bound per CRTC
and maybe a crtc_bounds_compute() is invoked to recompute only when the pre-computation has become stale.

Also, I just wish to point out, while its nice to fix panning and scaling together, it is not necessary. The use cases for those needing scaling fixed may be different, and can be incrementally fixed with another patch and bug report.

please ignore, if I don't make sense, as I'm just a just user, not developer.

Marking as a regression in 1.11.

Can someone please share if you've got a patch that fixes the scaling too? Thnx.

*** Bug 40063 has been marked as a duplicate of this bug. ***

Reverting the patch mentioned in Bug 40063 fixes it with both panning and scaling. It's a temporary fix for those of using netbooks.

How to build:
* yumdownloader --source xorg-x11-server-Xorg
* rpm -ivh xorg-x11-server-Xorg*rpm
* unzip and revert patch in the xorg .tar.bz2 and re-package it again
* go to $HOME/rpmbuild/SPECS directory and run rpmbuild -bb xorg-x11-server.spec
* re-install the fixed package: yum --nogpgcheck reinstall $HOME/rpmbuild/RPMS/*/xorg-x11-server-Xorg-1.11.1-1.fc16.x86_64.rpm

It looks like I have this problem here too (jcristau pointed me at this bug report), though with a different symptom.

I have two monitors – one 1920×1080 and one 1280×1024, set up so that I have a wide desktop area, the wider viewport at (0,0) and the narrower one at (1920,0). Trying to move to the workspace below the current one via the smaller monitor (using xfwm4's workspace switching via pointer position) fails.

However, if I move its viewport such that the two are disjoint, all works as expected.

(That said, I do agree that constraining the pointer in this way is not a bad thing.)

josvanr (josvanr) on 2011-10-28
description: updated
josvanr (josvanr) on 2011-10-29
description: updated
description: updated
affects: ubuntu → xorg (Ubuntu)
bugbot (bugbot) on 2011-10-30
tags: added: kubuntu
Ryan Sutton (oldmansutton) wrote :

This also happens in the Unity/Gnome desktop

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in xorg (Ubuntu):
status: New → Confirmed
dsvilko (dsvilko) wrote :

I would also very much like this resolved. It would make the 800x480 resolution on my asus eee much more usable.
I believe this is the upstream bug report:
The problem can be solved by reverting the patch from:
Is anyone willing to build a patched xorg?

Bryce Harrington (bryce) on 2011-11-18
Changed in xorg (Ubuntu):
importance: Undecided → Low
affects: xorg (Ubuntu) → xorg-server (Ubuntu)
Changed in xorg-server (Ubuntu):
status: Confirmed → Triaged
Ryan Sutton (oldmansutton) wrote :

I'll build one, if somebody could tell me how. I haven't had to undo a patch before, and am leery about breaking it and being hosed. I have bad luck with compiling core stuff lol ;)

Bryce Harrington (bryce) wrote :

I've reproduced this on Precise under Unity on an Intel laptop's external monitor (lvds turned off).

tags: added: precise
removed: kubuntu
Bryce Harrington (bryce) wrote :

The patch on 40063 simply reverts the cursor constraint feature -- not what we want for fixing the issue.

Three other patches have been proposed:

However, these are for fixing panning rather than scaling. However these look like they're more on the right track of solving the underlying problem, perhaps something similar could be crafted to handle scaling better.

Wolf (wolf-beckmanns-nest) wrote :

For me it is a showstopper to!!

So please if someone has a temporary solution, pleas tell.

Perhaps it is possible to install an older version of Xorg or of some packages? And if it is possible, how to do this?

Since I updated my EeePC I can't use it for something else than Surfing!

Changed in xorg-server:
importance: Unknown → High
status: Unknown → Confirmed

I'm having the exact same problem too. If anyone has some step by step instructions on how to downgrade xorg using Ubuntu 11.10 I'd be greatly appreciative.

Id also like that. I downloaded the xorg sources in kubuntu 11.10 (package xorg-server-1.10.4). The patch seems to be in there I think in the file debian/patches/219_fedora-pointer-barriers.diff . I tried to reverse it but haven't succeeded yet. I'm not an expert in this... Any Help?....

Created attachment 56408
Reverts commit 56c90e29f04727c903bd0f084d23bf44eb1a0a11, applies cleanly to xorg-server 1.11.4

The commit referenced by Bug 40063 no longer reverses cleanly against xorg-server version 1.11.4. Attached is an updated patch that should work.

Bryce Harrington (bryce) on 2012-02-08
tags: added: kubuntu
summary: - xrandr --scale 1.2x1.2 restricts area in which mouse moves
+ xrandr --scale restricts area in which mouse moves

Is there any motion on getting this fixed in a current release? Panning is extremely useful to lots of laptop users. I see it listed as a blocker for 1.12, yet a fix doesn't seem to have made it into 1.12.

Please send your patch to xorg-devel for discussion.

I use xrandr for scaling to make a small netbook screen able to display apps that don't fit in 1024x600 and noticed this regression over the last year in 1.11. I finally decided to look closer since 1.12 didn't seem to fix the issue and came across this report.

I looked at the revert commit to get idea of area that could possibly be fixed and it seems like crtc_bounds() is probably a function that should be returning a value related to panning/scaling.

I traced were xrandr output is querying the panning/scaling values it displays and looks like comes from ProcRRGetCrtcInfo() and that function makes use of RRCrtcGetScanoutSize() to scaling width/height to correct size. Panning uses rrGetPanning().

To test the idea, I modified crtc_bounds to handle scaling case by adding ProcRRGetCrtcInfo() call. It does seem to work and I've not noticed a negative in limitted testing.

I patched a source RPM so I can't offer a real patch right now but here is my modified version of function to get an idea:

static void
crtc_bounds(RRCrtcPtr crtc, int *left, int *right, int *top, int *bottom)
    int width, height;
    RRCrtcGetScanoutSize (crtc, &width, &height);

    *left = crtc->x;
    *top = crtc->y;

    switch (crtc->rotation) {
    case RR_Rotate_0:
    case RR_Rotate_180:
       *right = crtc->x + width;
       *bottom = crtc->y + height;
    case RR_Rotate_90:
    case RR_Rotate_270:
       *right = crtc->x + height;
       *bottom = crtc->y + width;

I reviewed the other patchwork patches just now. Patch 6209 in Comment 7 addresses panning part of issue in crtc_bounds() using same logic from ProcRRGetCrtcInfo().

If you combine my modification from Comment 17 with the patch 6209 then you'll get solution for both scaling and panning.

Not sure its the right solution and it seems a little excessive to compute each X/Y movement... but I hope it helps move us along to final solution.

Chris, could you put together the combined patch you mentioned and send it to xorg-devel for review? Thanks.

Created attachment 59557
Sample fix for panning/scaling

Attached patch has been posted to mailing list for discussion but no replies so far. Posting here so it doesn't get lost.

This combines fix for panning from another patch and adds scaling fix as well.

Just confirming that Chris Bagwell's scaling approach (above) worked for me using 1.12.0 (from Fedora 17 source rpm) and having had this issue for some time. Previously, I'd been downgrading, as I've found this an important feature for netbook usability. Thanks Chris!

Marc Deslauriers (mdeslaur) wrote :

I just tested Chris Bagwell's patch in comment #20 of the upstream bug, and it solved my issue on my Dell Mini 9.

Ryan Sutton (oldmansutton) wrote :

Could you provide instructions on where to download the correct source, and possibly what flags and whatnot you compiled the patched version with? I tried to apply one of the regression patches a month or two back, and while I patched and built successfully, my complete version had completely killed any mouse and keyboard input and I had to reinstall linux when I was done. I would rather not have to start over from scratch again. I'm familiar with how to apply the patch and whatnot to the source, but would definitely appreciate some more detail. Or even better, a .deb package built for 32bit x86? ;)

Marc Deslauriers (mdeslaur) wrote :

I've uploaded a patched test version for Precise into my PPA here: https://launchpad.net/~mdeslaur/+archive/testing

Ryan Sutton (oldmansutton) wrote :

HAHAHAHA! It works, oh gods it works! Thank you both Chris and Marc! My first reboot I had to manually restart lightdm, but that's a small price to pay to actually SEE my whole desktop at > 1024x600 all at once without pointless panning, especially if I happen to load up a game that uses the screen edges for scrolling, and needs to be 1024x768. Oh HAPPY DAYS! I think the one problem I had with lightdm not loading all the way the first time is more to do with me being on Oneiric, and having to do some impromptu hacky pulling down of libx11 and libc6 from Precise, but again, even if I end up having to reload lightdm manually every time I reboot (time will tell), it's a small price to pay for scaling to work correctly again. Thank you so much!

Ryan Sutton (oldmansutton) wrote :

Ok, my hacky changes to Oneiric killed it, so I reinstalled to Precise, and then applied your built fix. Works beautifully in the environment is was built for. I think the patch is golden.

Christian Rank (c-rank) wrote :

Just did
   apt-add-repository ppa:mdeslaur/testing
on my xubuntu 12.04 installation. Now after scaling with xrandr the mouse can be moved again over the whole screen. Thanks a lot for this patch.
I propose it should go into the final 12.04 distribution.

josvanr (josvanr) wrote :

For me this bug is also a show stopper. Can I do anyting to vote for this or something?

Would also like to confirm that Chris Bagwell's patch works for me. I'm using 1.11.4 from Debian Sid and the patch didn't apply cleanly (whitespace issue and started at 297 instead of 282), but after I fixed that it works like a charm. Been missing this feature for a while :) Thanks Crhis!

Ryan Reich (ryan-reich) wrote :

I just found this bug -- I've been waiting for this issue to be fixed for several years. Chris Bagwell's patch works for me as well; incredible!

I did:

sudo apt-add-repository ppa:mdeslaur/testing
sudo apt-get update
sudo apt-get upgrade

0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Precise Pangolin final. Is not downloading anything here.

Where is my error?

Will give this patch a try on Xubuntu 12.04 when I have a chance. Currently, am using Mint 9 Xfce on my Lenovo S10 netbook, as the version of xrandr does not have this problem on that distro. Would love to upgrade though...

Church (church4regsvc) wrote :

Can someone post some steps how to build in proper way patched xserver(? or xrandr?) on ubuntu LTS 12.04? Seems i have been bitten by it as well.
BTW, it didn't bother me much before, when scaling worked properly, but is it intended behaviour, that if one sets real resolution After scale usage, it never covers whole screen? Tried to get by with temporary setting lower res, but all i get - still scaled output, but now with blacked out sides.

Wolf (wolf-beckmanns-nest) wrote :

I just tried Christian Rank (c-rank) updates on an ubuntu 12.04 LTS and it works.
Great job!

Christian Rank (c-rank) wrote :

Thanks, but all credit goes to Chris Bagwell (chris-cnpbagwell) who created this patch and Marc Deslauriers (mdeslaur) who made the ppa.

I had the same error but fixed it by running

sudo apt-get dist-upgrade

I'm no expert, but it appears that my problem was that this patch is dependent on the linux kernel 3.2.0-24-generic.

I hope this helps!

bugbot (bugbot) on 2012-05-31
tags: added: oneiric

For the record, openSUSE Factory (devel) is currently @ 1.12.2, where panning for me is working OK with radeon/rv200, but not with nouveau or intel drivers.

FWIW: I don't try to use randr directly to set up panning. I do it either through xorg.conf or xorg.conf.d/50-monitor.conf because I'm usually controlling DPI via DisplaySize, limiting VertRefresh to 60 or 75, turning DPMS & DDC off, and turning DefaultModes on. It would be nice if TargetRefreshRate ever worked.

I don't use small displays either. Mostly I use CRTs as described on http://lists.x.org/archives/xorg-devel/2012-June/031652.html

Tried Chris's patch on an Acer netbook (Intel video), Debian Wheezy, and it fixed panning (xrandr) for gnome3 and xfce4. Thanks!

In previous comment for for Wheezy, the debian xorg-server source package was version: 2:

I was also able to test the patch on Ubuntu Precise, source package version: 2:1.11.4-0ubuntu10.3. On the same Acer netbook (Intel video), it fixed xrandr panning with Unity 3D.

ps. The patch file did not apply (with patch program) to the Ubuntu source version. I applied the patch manually, with a text editor.

https://bugzilla.novell.com/show_bug.cgi?id=771521 explains how panning works for me using Radeon but not Intel or Nouveau.

Chris' patch applied nicely against 1.12.3 and solved the issue here.

I applied Mr. Bagwell's patch to Fedora 17 after receiving some guidance from Mr. Weir. I thank all who have posted for their contribution in resolving this long term regression.

My specific steps were...

1. Obtain the source: yumdownloader --source xorg-x11-server-common.i686

2. Extract the RPM to a subdirectory structure (in my case, ~/source/xorg-x11-server-x.xx.x-y.fc17.src)

3. Extract the xorg-server-x.xx.x.tar.bz2 file (contained in the directory created in step 2) to source subdirectories of that directory (in my case ~/source/xorg-x11-server-x.xx.x-y.fc.src/xorg-server-x.x.xx) created in step 2.

4. Modify the rrcrtc.c source code in the randr subdirectory (~/source/xorg-x11-server-x.xx.x-y.fc.src/xorg-server-x.x.xx/randr) as Chris states. I had to apply the patch manually, however it's very straightforward.

The following steps were issued from within the xorg-server-x.xx.x subdirectory created in step 3 above and presume you have all required development tools installed.

5. Command: ./configure --prefix=/usr.

6. Command: make

7. Command: sudo make install

I performed these steps on version 1.12.2-2 as well as on 1.12.2-4 and after testing each patch, I reinstalled (yum reinstall xorg-x11-server-common.i386) standard code to verify repeatability. In each case, scanning/panning was enabled following application of the patch.

I am running this on an Acer Aspire AOD257 which has (of course) an integrated trackpad. One issue I have noticed is that after application of the patch, the trackpad scrolling functions are disabled. That is to say, the trackpad continues to function as a "mouse", but the "finger drag along the right side of the trackpad" no longer functions. Under touchpad-system settings (KDE desktop), the touchpad information indicates "device not found". I cannot explain the relationship between this function and the patch, but will do more testing -- has anyone else on a netbook noticed this condition?

tags: added: ubuntu

Thanks Chris for your patch "Sample fix for panning/scaling".

openSUSE Linux users can test Xorg server (package xorg-x11-server) with this patch included. openSUSE users find the temporary and experimental openSUSE repository here:


I find the old panning feature very useful. With an old "ATI Radeon Mobility 9200" graphics card, I can extent the 1024x768 desktop until 4096x4096. With an more recent "ATI Radeon HD 3450" I can extend until 8192x8192.

Unfortunately the support for panning within the KDE desktop poor. I miss special maximize and fullscreen functions for big virtual screen.

My xrandr setting for testing (3072x768 virtual desktop on a 1024x768 Laptop (LVDS) screen):

xrandr --output LVDS --panning 3072x768

I have no problems with touchpad and external mouse.

(In reply to comment #31)
> http://download.opensuse.org/repositories/home:/bjoernv:/branches:/openSUSE:/
> 12.2:/Update/standard/

As indicated in downstream https://bugzilla.novell.com/show_bug.cgi?id=771521 these work for me with Intel 865G and NVidia G84.

Calichon (aguilars) wrote :

Thanks Chris and Marc, for the patch and ppa. I just tried the fix in Quantal Quetzal (12.10) 32 bits. My netbook is a Benq Joybook Lite U101C, 1024x600, Intel Atom N270 1.6 GHz, graphics card Intel 945.

I even installed Ubuntu Tweak, and activated the events that are triggered in the screen corners (show windows, show desktop, show workspaces). The first time, the behavior was weird, but that time I used the NEWREZ script. The second time I used xrandr on terminal and all it's working good, what am I saying?, it's working awesome. Good work

OzK (tipsgnulinux) wrote :

Bug affects Oneiric, Precise and now Quantal. I do not remember Natty.
Canonincal needs to patch xorg once and for all. It's a simple solution and we are more than 1 year and 3 dists (Oneiric, Precise and Quantal) suffering this bug.

ppa:mdeslaur/testing has no xorg for Quantal.

josvanr (josvanr) wrote :

HEAR HEAR ! I was still using natty in which works fine more or less Now updated to 12.04 *#*#@@#&@#

Its back!!

I do for external monitor (rotated 90 deg) on laptop

xrandr --output VGA1 --auto --rotate left --right-of LVDS1 --gamma 1:1:1

and scale:

xrandr --output VGA1 --scale 1.7x1.7

NOW:... the mouse will only move in the upper half of the external monitor........ nice..........

josvanr (josvanr) wrote :

I just tried to use the ppa:mdeslaur/testing on ubuntu 12.04 (dont know if it changes the behaviour for external monitor problem)

jos@bugix:~$ sudo apt-add-repository ppa:mdeslaur/testing

but: ??

jos@bugix:~$ sudo apt-get install --reinstall xserver-xorg-core
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reinstallation of xserver-xorg-core is not possible, it cannot be downloaded.
The following packages were automatically installed and are no longer required:
  linux-headers-3.2.0-23 epiphany-data libmikmod2 linux-headers-3.2.0-23-generic-pae libsdl-mixer1.2
Use 'apt-get autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

jos@bugix:~$ sudo apt-get dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

josvanr (josvanr) wrote :


for anyone struggeling with this problem, the above conains a patch. Haven't tested it for external monitor though....

works for HP envy 17 2100ed, Radeon HD6850M, thnx!

josvanr (josvanr) wrote :

(the suse patch, that is)

Marc Deslauriers (mdeslaur) wrote :

This was fixed in quantal with the following commit:

The only thing is you need to specify the panning resolution when using the scale parameter. For example, instead of using the following to scale a 1024x600 netbook screen:

xrandr --output LVDS1 --scale 1.25x1.25

you need to use:

xrandr --output LVDS1 --panning 1280x750 --scale 1.25x1.25

Changed in xorg-server (Ubuntu Quantal):
status: New → Fix Released
Changed in xorg-server (Ubuntu Raring):
status: Triaged → Fix Released
Changed in xorg-server (Ubuntu Precise):
status: New → Triaged
importance: Undecided → Low
Marc Deslauriers (mdeslaur) wrote :

Here's a debdiff with a backport to SRU. I'll upload it once the current package in precise-proposed gets verified.

Has this fallen off the radar? I'd like to update my system, but I can't lose this functionality.

Oscar Campbell (7-oscar) wrote :

Thank heavens and hells. Marc Deslauriers (mdeslaur) solution #62 worked perfectly here: My 1600x900 now displays as full-hd with:
xrandr --output LVDS1 --panning 1920x1080 --scale 1.2x1.2

I use this to get the scaling right for real-world measurements vs screen-distances in a specific app.


I wonder, why the maximum panning size is so driver dependent.

My ATI Radeon HD 3450 had a maximum panning size of 8192x8192 with the open source "radeon" and "radeonhd" drivers. With AMD's ATI Catalyst 13.1 Legacy driver I only have a maximum of 1920x1920. The monitor's native size is Full-HD (1920x1080) and it's connected via Dual-Link-DVI.

$ xrandr -q
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 1920 x 1920
DFP1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 510mm x 287mm panning 1920x1080+0+0
   1920x1080 60.0*+
   1776x1000 60.0 +
   1680x1050 60.0

One possible answer to my own question is, that AMD's ATI Catalyst driver disables the Xorg RandR extension and enables it's own RandR extention:

from /var/log/Xorg.0.log:
[ 68.714] (II) fglrx(0): RandR 1.2 support is enabled!
[ 68.714] (II) fglrx(0): RandR 1.2 rotation support is enabled!
[ 69.541] (II) fglrx(0): Disabling in-server RandR and enabling in-driver RandR 1.2.
[ 69.975] (--) RandR disabled
[ 69.975] (II) Initializing built-in extension RANDR
[ 92.101] (II) fglrx(0): Restoring Recent Mode via PCS is not supported in RANDR 1.2 capable environments

Any idea, how to change this configuration?

Marc Deslauriers (mdeslaur) wrote :

Package with backported fix uploaded to precise-proposed for processing by the SRU team.

description: updated
Calichon (aguilars) wrote :

Thanks for the newrez fix. It's working nice in my Precise 12.04 x64 ;)

Hello josvanr, or anyone else affected,

Accepted xorg-server into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/xorg-server/2:1.11.4-0ubuntu10.12 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in xorg-server (Ubuntu Precise):
status: Triaged → Fix Committed
tags: added: verification-needed
Wolf (wolf-beckmanns-nest) wrote :

I just installed the Binary-Packages:
xdmx, xdmx-tools, xnest, xserver-xephyr, xserver-xfbdev, xserver-xorg-core, xserver-xorg-dev and xvfb

All in the Version 2:1.11.4-0ubuntu10.12

Just checked with Synaptic the Version.

Even afer a restart the bug still exists.

So the verification faild.

I have an 32Bit Ubuntu.

Interesting is, that the Patch from #35 that worked for me is also not working anymore !!

tags: added: verification-failed
removed: verification-needed
Marc Deslauriers (mdeslaur) wrote :

I just tested the xorg-server package in -proposed on my mini 9, and it works as intended.

@Wolf: what command did you run to scale your screen?

tags: added: verification-done
removed: verification-failed
Marc Deslauriers (mdeslaur) wrote :

I changed the tag from verification-failed to verification-done for now, as I've tested it successfully, and because comment #71 seems to indicate that the previous fix no longer works either.

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xorg-server - 2:1.11.4-0ubuntu10.12

xorg-server (2:1.11.4-0ubuntu10.12) precise-proposed; urgency=low

  * debian/patches/238-xrandr-fix-panning.patch: disable CRTC cursor
    confinement when panning is enabled. (LP: #883319)
 -- Marc Deslauriers <email address hidden> Tue, 12 Feb 2013 16:45:02 -0500

Changed in xorg-server (Ubuntu Precise):
status: Fix Committed → Fix Released

If it hasn't happened already, the supply of supported distros that feature working panning should be exhausted soon. Is there anything non-programmers can do to facilitate a programmer fixing this?

Has anyone bugged keithp to review the proposed patch? I'm pretty sure he could do so quickly, and suggest an alternate if needed.

(In reply to comment #37)
> Has anyone bugged keithp to review the proposed patch? I'm pretty sure he
> could do so quickly, and suggest an alternate if needed.

If you'll tell me who keithp is, I'll bug him.

(In reply to comment #38)
> If you'll tell me who keithp is, I'll bug him.

Maintainer of the xorg-server.

He mostly reviews fixes sent to xorg-devel, not those stuck in bugzilla though.

I have this bug when I use xrandr to resize the output to the VGA monitor, and then turn off the LVD using xrandr --output LVDS1 --off. The mouse becomes confined to the left side of the monitor as soon I turn off the LVD.

I have version 2:1.11.4-0ubuntu10.13 of xorg-server, where this problem is supposed to be fixed for the LVD, but evidently it is not fixed for the VGA.

Strange --- this bug is marked as fixed but I can reproduce it all the time on my LVD. xserver-xorg 1:7.7+1ubuntu6 (apt-get update tell me it's recent). Am I doing something wrong?

lars (lars-augensen) wrote :

Still happening for me on a Eee 901. Does other software need to be aware of a change in xrandr?

It seems clear that at least analog hardware users who require panning and want or need to stick to FOSS solutions need to stick to out of support Xorg versions and/or out of support drivers, and/or ancient gfxchip technology (e.g. MGA), and/or cheap (and usually slow) hardware (e.g. # XGI Technology Inc. (eXtreme Graphics Innovation) Z7/Z9 (XG20 core), a slug at 24 bit, tolerable at 16 bit as long as not extending the desktop virtually as panning was made to do). It looks like users of supported FOSS software versions and modern competent gfxchips are out of options other than acquiring (digital?) displays big enough, or acquiring additional (digital?) video ports and (digital?) displays, to cover their otherwise virtual needs.

Created attachment 94929
randr: Account for panning and transforms when constraining the cursor

Created attachment 96204
Xorg.0.log from 92915G host gx280

http://download.opensuse.org/repositories/home:/tobijk:/X11:/XOrg/openSUSE_Factory/i586/ ostensibly has the attachment 94929 patch applied, which I installed on nv11, rv250 and i915G systems running X.Org X Server

# rpm -q --changelog xorg-x11-server | head -n8
* Fri Mar 21 2014 tobias.johannes.klausmann@...
- Add patch u_randr_account_for_panning_and_transform_when_creating_cursor.patch
  (BNC#771521), (FDO#39949)

I could not detect any difference before or after installing the xorg-x11-server version 7.6_1.15.99.901.8-393.1 that includes the patch, plus its dependencies. IOW, pointer could not reach right or bottom screen edges before or after installing with any of the ati, intel or nouveau drivers.

Ati and nouveau test logs are available on request.

Comment 43 applies to use of xorg.conf in attempting to produce desired X configuration, e.g. xorg.conf for Intel gfx containing:

Section "Device"
    Identifier "Default Device"
 Option "monitor-VGA1" "Default Monitor"

Section "Monitor"
    Identifier "Default Monitor"
 Option "DPMS" "off"
 DisplaySize 405 253 # 120 DPI @ 1920x1200 & virtual
 Option "PreferredMode" "1440x900"
 Option "Panning" "1920x1200"

Section "Screen"
    Identifier "Default Screen"
 Device "Default Device"
 Monitor "Default Monitor"

produces expected results for server 1.9.3, but not for server 1.16.0RC1. Functional panning matching that produced by the above xorg.conf can be at least mostly achieved in i915 via xrandr as follows:

xrandr --dpi 120 --fb 1920x1200 --output VGA1 --mode 1440x900 --panning 1920x1200
xrandr --fbmm 405x253 --fb 1920x1200 --output VGA1 --mode 1440x900 --panning 1920x1200

A remaining problem therefore exists that did not exist prior to the server changes made that made this bug report necessary in the first place, that xorg.conf no longer does what xrandr can, as xorg.conf used to be able to do. This is new with the 96204 patch, as with the 56408 patch and server 1.12.3, xorg.conf gets the job done as expected.

Created attachment 96397
Xorg.0.log from i915 host gx280 having used xrandr to produce panning from 94929 patch

This seems to be unusually verbose for the brief time X was running, with few apps opened.

Via xrandr, 94929 patch also tested working apparently OK for:
ATI rv380 VGA & DVI ports 1680x1050 on 1280x1024
Intel G41 VGA & HDMI ports 1680x1050 on 1280x1024
Nouveau G84 DVI port 1680x1050 on 1280x1024. with & without DVI-to-VGA adapter
Nouveau G84 DVI port 2048x1152 & 2560x1600 & 3840x2160 on 1440x900 with DVI-to-VGA adapter

With the g84 on 1080 HDTV, apparently scaling, which I never tried before, is working too:
$ xrandr --output DVI-I-1 --scale 1.2x1.2
(Assorted X data collected via script):
# grep PRETTY /etc/os-release
PRETTY_NAME="openSUSE 13.2 Milestone 0 (Harlequin) (x86_64)"
# head -n16 /var/log/Xorg.0.log (beta warning stripped)
[ 31.305]
X.Org X Server (1.16.0 RC 1)
Release Date: 2014-02-24
[ 31.305] X Protocol Version 11, Revision 0
[ 31.305] Build Operating System: openSUSE SUSE LINUX
[ 31.305] Current Operating System: Linux big41 3.14.0-rc7-1-desktop #1 SMP PREEMPT Thu Mar 20 12:43:03 UTC 2014 (89fa272) x86_64
[ 31.305] Kernel command line: root=LABEL=os132h50 ipv6.disable=1 net.ifnames=0 noresume splash=verbose vga=791 video=1024x768@60
# grep Output /var/log/Xorg.0.log | egrep -v 'disconnected|no monitor'
[ 31.653] (II) NOUVEAU(0): Output DVI-I-1 connected
[ 31.653] (II) NOUVEAU(0): Output DVI-I-1 using initial mode 1920x1080
# grep -v ^\# /etc/X11/xorg.conf.d/50-monitor.conf | grep DisplaySize
grep: /etc/X11/xorg.conf.d/50-monitor.conf: no such file or directory
# grep -v ^\# /etc/X11/xorg.conf | grep DisplaySize
grep: /etc/X11/xorg.conf: no such file or directory
# grep -v ^\# /etc/X11/xorg.conf.d/50-monitor.conf | grep PreferredMode
grep: /etc/X11/xorg.conf.d/50-monitor.conf: no such file or directory
# grep -v ^\# /etc/X11/xorg.conf | grep PreferredMode
# xrdb -query | grep dpi
grep: /etc/X11/xorg.conf: no such file or directory
# xdpyinfo | egrep 'dime|ution'
  dimensions: 2304x1296 pixels (608x342 millimeters)
  resolution: 96x96 dots per inch
# xrandr | head
Screen 0: minimum 320 x 200, current 2304 x 1296, maximum 8192 x 8192
DVI-I-1 connected 2304x1296+0+0 (normal left inverted right x axis y axis) 698mm x 393mm
   1920x1080 60.0*+ 60.0 59.9 24.0 24.0
   1920x1080i 60.1 60.0
   1280x720 60.0 59.9
   1024x768 75.1 70.1 60.0
DVI-I-2 disconnected (normal left inverted right x axis y axis)

For well over a week I've been first testing the success of panning for various combinations of gfxcard, monitor and fb size in servers prior to the changes resulting in this bug report and then same for installations to which I've updated using the 94929 patch applied by Tobias Klausmann in the openSUSE build-service. Initially the only recording I did of my testing I reported here. After while I began recording in the form of screenshots accompanied by the Xorg.#.log associated with each one. These are available for perusal at http://fm.no-ip.com/SS/Xorg/ . Among them is one instance of a scaling test, 1.2x1.2 applied to a 1440x900 screen. The largest fb size I tested was 3840x2400. The newest gfxchip used was a Intel 4000 series (G41). Others used are nv11, G84, rv200, rv250, rv380, i865G, i915G & i945G. The highest resolution used was 1920x1080. Total "success" pairs there currently is 31, of which 14 are pre-bug and 17 are server 1.16rc1. KDE3 & KDE4 dominate the DEs represented. A few are IceWM and Lxde.

The only outright failure so far was on i945G and 1.16rc1 on both openSUSE 13.1 & 13.2, but after another system/xorg updates round those inexplicable failures apparently solved themselves.

Among the overwhelming number of "successes" are many instances of various forms of painting and mouse pointer trouble among the configurations with the largest panning areas that always goes away if panning is disabled. However, such problems are common to both old servers and DEs as well as current ones. The painting problems don't show up in any of the screenshots. Except for the comment 44 reported failure of xorg.conf* to produce expected results, WRT to bounds and sizes at least, the 94929 patch seems to be doing what it needs to do.

(In reply to comment #42)
> Created attachment 94929 [details] [review]
> randr: Account for panning and transforms when constraining the cursor

Chris, any plans to send this patch to the xorg-devel list, i.e. to get this upstream or is that just a proof of concept?

Changed in xorg-server:
status: Confirmed → Incomplete

As the summary is currently written, this bug is INVALID. Panning works at least as far back as 1.13.2-1.21.1.i586 in openSUSE 12.3 (i865G,rv200), in addition to current 1.15.x and 1.16rc1 servers in Fedora, Mageia, and openSUSE, but only when xrandr is used to configure it. Configuration via /etc/X11/xorg.con* files and syntax that worked in older servers such as 1.10.4 is what is broken for ATI, Intel and NVidia.

I haven't tested scaling except briefly, and successfully, via xrandr only, in e.g. 1.16rc1.

Panning works via xrandr (only; not via xorg.con*) also in Kubuntu 12.04's server 1.11.4, while scaling does fail by having the mouse cursor bound within the screen mode's size.

Since panning at least can work via xrandr, I've forked the failure of xorg.con* to provide equivalent panning function of xrandr without arbitrary mouse constraint to bug 77321

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.