Panning in a virtual monitor is not possible after upgrade to Ubuntu 11.10
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
X.Org X server |
Fix Released
|
High
|
|||
xorg-server (Ubuntu) |
Triaged
|
Low
|
Chris Halse Rogers | ||
Precise |
Won't Fix
|
Low
|
Chris Halse Rogers |
Bug Description
When I go for a virtual monitor by issuing command "xrandr --output LVDS1 --fb 1600x1200 --panning 1600x1200" on a monitor working at resolution 1024x768 (as I did before upgrading from Ubuntu 11.04 to Ubuntu 11.10), the WM bars on top and left side of the screen (in Unity) look like extending to the new area, but I cannot move the pointer to the new extra area and so I cannot pan. As far as I understood by reading around, this *could* be a bug in package "xorg-server" rather than in "xrandr" and *could* be related to the boundaries set for cursor position.
ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: xorg 1:7.6+7ubuntu7
ProcVersionSign
Uname: Linux 3.0.0-12-generic i686
.tmp.unity.
ApportVersion: 1.23-0ubuntu3
Architecture: i386
CompizPlugins: [core,bailer,
CompositorRunning: compiz
Date: Mon Oct 24 20:40:14 2011
DistUpgraded: Log time: 2011-10-22 12:17:44.515205
DistroCodename: oneiric
DistroVariant: ubuntu
DkmsStatus:
dahdi, 2.4.1+dfsg-
dahdi, 2.4.1+dfsg-
dahdi, 2.4.1+dfsg-
ExtraDebuggingI
GraphicsCard:
Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller [8086:2592] (rev 03) (prog-if 00 [VGA controller])
Subsystem: Dell Device [1028:0182]
Subsystem: Dell Device [1028:0182]
MachineType: Dell Inc. Latitude D610
PccardctlIdent:
Socket 0:
no product info available
PccardctlStatus:
Socket 0:
3.3V 32-bit PC Card
ProcEnviron:
SHELL=/bin/bash
PATH=(custom, no user)
LANG=it_IT.UTF-8
LANGUAGE=
ProcKernelCmdLine: root=UUID=
SourcePackage: xorg
Symptom: display
UpgradeStatus: Upgraded to oneiric on 2011-10-22 (2 days ago)
dmi.bios.date: 03/02/2005
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A03
dmi.board.name: 0D4571
dmi.board.vendor: Dell Inc.
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.
dmi.product.name: Latitude D610
dmi.sys.vendor: Dell Inc.
version.compiz: compiz 1:0.9.6+
version.libdrm2: libdrm2 2.4.26-1ubuntu1
version.
version.
version.
version.
version.
version.
version.
version.
In freedesktop.org Bugzilla #39949, Hgkamath (hgkamath) wrote : | #12 |
In freedesktop.org Bugzilla #39949, Wnm-sales (wnm-sales) wrote : | #13 |
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.)
In freedesktop.org Bugzilla #39949, Hgkamath (hgkamath) wrote : | #14 |
still present in xorg-x11-
In freedesktop.org Bugzilla #39949, Hgkamath (hgkamath) wrote : | #15 |
https:/
Mouse shouldn't move into area outside the monitors
somehow seems like a possible cause of this.
In freedesktop.org Bugzilla #39949, B-miles (b-miles) wrote : | #16 |
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 freedesktop.org Bugzilla #39949, Rui Matos (tiagomatos) wrote : | #17 |
(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://
Yeah, I later submitted another patch which also fixes this issue in a different way:
http://
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.
In freedesktop.org Bugzilla #39949, Paul Alesius (paul-unnservice) wrote : | #18 |
(Reply to comment #5)
> Yeah, I later submitted another patch which also fixes this issue in a
> different way:
>
> http://
>
> 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.
In freedesktop.org Bugzilla #39949, Hgkamath (hgkamath) wrote : | #19 |
http://
http://
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
http://
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_
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.
In freedesktop.org Bugzilla #39949, Julien Cristau (jcristau) wrote : | #20 |
Marking as a regression in 1.11.
In freedesktop.org Bugzilla #39949, Paul Alesius (paul-unnservice) wrote : | #21 |
Can someone please share if you've got a patch that fixes the scaling too? Thnx.
In freedesktop.org Bugzilla #39949, Paul Alesius (paul-unnservice) wrote : | #22 |
*** Bug 40063 has been marked as a duplicate of this bug. ***
In freedesktop.org Bugzilla #39949, Paul Alesius (paul-unnservice) wrote : | #23 |
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-
* rpm -ivh xorg-x11-
* unzip and revert patch in the xorg .tar.bz2 and re-package it again
* go to $HOME/rpmbuild/
* re-install the fixed package: yum --nogpgcheck reinstall $HOME/rpmbuild/
In freedesktop.org Bugzilla #39949, Darren Salt (dsalt) wrote : | #24 |
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.)
Ernesto Torresin (ewk) wrote : | #1 |
- BootDmesg.txt Edit (70.1 KiB, text/plain; charset="utf-8")
- BootLog.gz Edit (918 bytes, application/x-gzip)
- Dependencies.txt Edit (5.0 KiB, text/plain; charset="utf-8")
- DpkgLog.txt Edit (2.1 MiB, text/plain; charset="utf-8")
- GconfCompiz.txt Edit (37.1 KiB, text/plain; charset="utf-8")
- Lspci.txt Edit (11.5 KiB, text/plain; charset="utf-8")
- Lsusb.txt Edit (642 bytes, text/plain; charset="utf-8")
- MonitorsUser.xml.txt Edit (2.8 KiB, text/plain; charset="utf-8")
- ProcCpuinfo.txt Edit (541 bytes, text/plain; charset="utf-8")
- ProcInterrupts.txt Edit (1.1 KiB, text/plain; charset="utf-8")
- ProcModules.txt Edit (3.7 KiB, text/plain; charset="utf-8")
- UdevDb.txt Edit (127.1 KiB, text/plain; charset="utf-8")
- UdevLog.txt Edit (276.3 KiB, text/plain; charset="utf-8")
- UnitySupportTest.txt Edit (598 bytes, text/plain; charset="utf-8")
- XorgLog.txt Edit (33.7 KiB, text/plain; charset="utf-8")
- XorgLogOld.txt Edit (33.1 KiB, text/plain; charset="utf-8")
- Xrandr.txt Edit (3.5 KiB, text/plain; charset="utf-8")
- peripherals.txt Edit (1.5 KiB, text/plain; charset="utf-8")
- xdpyinfo.txt Edit (9.7 KiB, text/plain; charset="utf-8")
- xinput.txt Edit (838 bytes, text/plain; charset="utf-8")
Ernesto Torresin (ewk) wrote : | #2 |
Colin Law (colin-law) wrote : | #3 |
This may well be the same issue and has some discussion of the cause.
https:/
Launchpad Janitor (janitor) wrote : | #4 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in xorg-server (Ubuntu): | |
status: | New → Confirmed |
Jonathan Greenblatt (jon-50e) wrote : | #5 |
This may be duplicate but I am not sure it is assigned to the correct package so I am not marking it as duplicate: https:/
Ernesto Torresin (ewk) wrote : | #6 |
Hello Jonathan! the bug reports look the same, but they are filed against different packages, namely one more general and one more specific. Does anybody NOT using the intel driver get the same bug?
Ernesto Torresin (ewk) wrote : | #7 |
In the ubuntu-users mailing list somebody suggested that this may be "a bug in the X server itself, caused by a fix to
https:/
I don't know the internals of the xlib randr extension, but if the suggestion above is correct, how could a bug concerning a "dual monitor setup" affect panning on a single monitor? Is panning achieved by emulating a "dual monitor setup" on the same screen?
Jonathan Greenblatt (jon-50e) wrote : | #8 |
The bug affecting dual monitors was to keep things from going off the edge of the screen of the smaller monitor. In fixing that bug the signal to pan in xorg was disabled due to the fact the mouse does not go off the screen to signal the need to scroll.
Some apps will not work on small screens given they have buttons that go off the bottom of the screen.
For now I have found a workaround for small monitors. I have been experimenting with FVWM and the EdgeScroll feature. This feature may take less video memory given I believe it does rely on the frame buffer so the virtual screen can be as big as you want (if I understand how frame buffers work?). It seems some expertise is needed to incorporate the panels/look and feel from other desktops but something is necessary to use apps where buttons go off the bottom of the screen. A little experimenting I am finding lxpanel works great with EdgeScroll enabled make sure lxpanel is set to StaysOnTop.
Sangala (sangala) wrote : | #9 |
For somebody a solution exists: https:/
Bryce Harrington (bryce) wrote : | #10 |
Reproduced on Ubuntu precise under Unity using an Intel gfx laptop with external monitor and LVDS turned off.
This is upstream bug https:/
http://
http://
http://
tags: |
added: precise removed: compiz-0.9 needs-reassignment |
Changed in xorg-server (Ubuntu): | |
importance: | Undecided → Low |
status: | Confirmed → Triaged |
Bryce Harrington (bryce) wrote : | #11 |
The issue is indeed a fault in the new cursor constraint logic that is in xorg-server.
Changed in xorg-server: | |
importance: | Unknown → High |
status: | Unknown → Confirmed |
Zack Evans (zevans23) wrote : | #25 |
Looks like the regression was introduced when trying to fix a problem with the mouse going into space outside of the display, when you have two displays of different sizes joined together. Here's the bug I think Bryce referred to, and it looks like that broke panning.
https:/
As Bryce says there are three proposed patches (!), so the best thing we can do is try and get upstream to prioritise it. Sounds like some of the patches only fixing panning or only fix scaling.
I just moved another bug from compiz to xorg - actually I now think it's just a dupe of this one, I will go and mark it.
Bryce - if one of them fixes both problems and looks fairly simple is there any chance of a cherry-pick?
Bryce Harrington (bryce) wrote : | #26 |
Zack - if you mean an SRU, once we have a viable patch we can look into that. Anyone had a chance to test the patches?
In freedesktop.org Bugzilla #39949, Alan-hollis (alan-hollis) wrote : | #27 |
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.
Ernesto Torresin (ewk) wrote : | #28 |
Personally, I don't like downgrading, and I cannot help you with that.
However, since and I miss a virtual monitor not because of the small size of my monitor, but because I often have plenty of terminal windows open, I found a satisfactory workaround with a better use of my desktops.
I installed the compizconfig-
In freedesktop.org Bugzilla #39949, Ernesto Torresin (ewk) wrote : | #29 |
I sent a comment about this on https:/
Ernesto Torresin
In freedesktop.org Bugzilla #39949, Deciare (deciare) wrote : | #30 |
Created attachment 56408
Reverts commit 56c90e29f04727c
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) wrote : | #31 |
Chris, this is more in your bailiwick, you might take a look when you get some time.
Changed in xorg-server (Ubuntu Precise): | |
assignee: | nobody → Chris Halse Rogers (raof) |
In freedesktop.org Bugzilla #39949, Leeman (me-mooluv) wrote : | #33 |
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.
In freedesktop.org Bugzilla #39949, Jeremy Sequoia (jeremyhu) wrote : | #34 |
Please send your patch to xorg-devel for discussion.
In freedesktop.org Bugzilla #39949, Chris Bagwell (chris-cnpbagwell) wrote : | #35 |
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 RRCrtcGetScanou
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(
{
int width, height;
RRCrtcGetSc
*left = crtc->x;
*top = crtc->y;
switch (crtc->rotation) {
case RR_Rotate_0:
case RR_Rotate_180:
default:
*right = crtc->x + width;
*bottom = crtc->y + height;
return;
case RR_Rotate_90:
case RR_Rotate_270:
*right = crtc->x + height;
*bottom = crtc->y + width;
return;
}
}
In freedesktop.org Bugzilla #39949, Chris Bagwell (chris-cnpbagwell) wrote : | #36 |
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 ProcRRGetCrtcIn
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.
In freedesktop.org Bugzilla #39949, Jeremy Sequoia (jeremyhu) wrote : | #37 |
Chris, could you put together the combined patch you mentioned and send it to xorg-devel for review? Thanks.
Glitch (jghaanstra) wrote : | #32 |
It would be nice if someone could explain how to test the patches as mentioned before. I would like to help (and fix this issue in the process) but I need some guidance.
In freedesktop.org Bugzilla #39949, Chris Bagwell (chris-cnpbagwell) wrote : | #38 |
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.
In freedesktop.org Bugzilla #39949, Pweir (pweir) wrote : | #39 |
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!
In freedesktop.org Bugzilla #39949, Erwin Junge (erwin-junge) wrote : | #40 |
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!
Sebas Ramone (punk84z) wrote : | #41 |
Working patch ?? .. Please help me, I don´t have an idea how to apply the patch, really need this fix ... but i´m lost :(
In freedesktop.org Bugzilla #39949, Michal C (campaigner444) wrote : | #42 |
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...
In freedesktop.org Bugzilla #39949, Felix Miata (mrmazda) wrote : | #43 |
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.
In freedesktop.org Bugzilla #39949, Felix Miata (mrmazda) wrote : | #44 |
FWIW: I don't try to use randr directly to set up panning. I do it either through xorg.conf or xorg.conf.
I don't use small displays either. Mostly I use CRTs as described on http://
In freedesktop.org Bugzilla #39949, gweg (gweg) wrote : | #46 |
In previous comment for for Wheezy, the debian xorg-server source package was version: 2:1.12.1.902-1
I was also able to test the patch on Ubuntu Precise, source package version: 2:1.11.
ps. The patch file did not apply (with patch program) to the Ubuntu source version. I applied the patch manually, with a text editor.
In freedesktop.org Bugzilla #39949, gweg (gweg) wrote : | #45 |
Tried Chris's patch on an Acer netbook (Intel video), Debian Wheezy, and it fixed panning (xrandr) for gnome3 and xfce4. Thanks!
In freedesktop.org Bugzilla #39949, Felix Miata (mrmazda) wrote : | #47 |
https:/
In freedesktop.org Bugzilla #39949, Leho Kraav (lkraav) wrote : | #48 |
Chris' patch applied nicely against 1.12.3 and solved the issue here.
In freedesktop.org Bugzilla #39949, Trailfodder (trailfodder) wrote : | #49 |
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-
2. Extract the RPM to a subdirectory structure (in my case, ~/source/
3. Extract the xorg-server-
4. Modify the rrcrtc.c source code in the randr subdirectory (~/source/
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-
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?
In freedesktop.org Bugzilla #39949, Bjoern Voigt (bjoern) wrote : | #50 |
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:
http://
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 freedesktop.org Bugzilla #39949, Felix Miata (mrmazda) wrote : | #51 |
(In reply to comment #31)
> http://
> 12.2:/Update/
As indicated in downstream https:/
In freedesktop.org Bugzilla #39949, Leeman (me-mooluv) wrote : | #52 |
Has this fallen off the radar? I'd like to update my system, but I can't lose this functionality.
In freedesktop.org Bugzilla #39949, Bjoern Voigt (bjoern) wrote : | #53 |
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
[...]
In freedesktop.org Bugzilla #39949, Bjoern Voigt (bjoern) wrote : | #54 |
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/
[...]
[ 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?
In freedesktop.org Bugzilla #39949, Felix Miata (mrmazda) wrote : | #55 |
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?
tags: | removed: regression-update |
In freedesktop.org Bugzilla #39949, X-po8 (x-po8) wrote : | #56 |
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 freedesktop.org Bugzilla #39949, Andrew Haley (aph-redhat) wrote : | #57 |
(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 freedesktop.org Bugzilla #39949, Alan Coopersmith (alan-coopersmith) wrote : | #58 |
(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.
http://
Jonathan Greenblatt (jon-50e) wrote : | #59 |
This defect is now fixed in Ubuntu 12.04.2 LTS running on a Acer Aspire One model ZG5.
Alex Sytnik (the-smerch) wrote : | #60 |
Jonathan, can you report your kernel version and xorg stack version, please?
Because in Ubuntu 12.04.3 LTS I'm having the issue right now.
Jonathan Greenblatt (jon-50e) wrote : | #61 |
Not sure the command for the xorg stack version, send me the command if this is not the right one:
$ uname -a
Linux rockdove-j 3.2.0-54-generic #82-Ubuntu SMP Tue Sep 10 20:09:12 UTC 2013 i686 i686 i386 GNU/Linux
$ lsb_release -a
LSB Version: core-2.
Distributor ID: Ubuntu
Description: Ubuntu 12.04.3 LTS
Release: 12.04
Codename: precise
$ Xorg -version
X.Org X Server 1.11.3
Release Date: 2011-12-16
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.42-37-generic i686 Ubuntu
Current Operating System: Linux rockdove-j 3.2.0-54-generic #82-Ubuntu SMP Tue Sep 10 20:09:12 UTC 2013 i686
Kernel command line: BOOT_IMAGE=
Build Date: 11 April 2013 01:04:30PM
xorg-server 2:1.11.
Current version of pixman: 0.24.4
Before reporting problems, check http://
to make sure that you have the latest version.
In freedesktop.org Bugzilla #39949, Jim Cline (jcline-physics) wrote : | #62 |
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.
In freedesktop.org Bugzilla #39949, Felix Miata (mrmazda) wrote : | #63 |
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.
In freedesktop.org Bugzilla #39949, Chris Wilson (ickle) wrote : | #64 |
Created attachment 94929
randr: Account for panning and transforms when constraining the cursor
In freedesktop.org Bugzilla #39949, Felix Miata (mrmazda) wrote : | #65 |
Created attachment 96204
Xorg.0.log from 92915G host gx280
http://
# rpm -q --changelog xorg-x11-server | head -n8
* Fri Mar 21 2014 tobias.
- Add patch u_randr_
(patch230)
(BNC#771521), (FDO#39949)
I could not detect any difference before or after installing the xorg-x11-server version 7.6_1.15.
Ati and nouveau test logs are available on request.
In freedesktop.org Bugzilla #39949, Felix Miata (mrmazda) wrote : | #66 |
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"
EndSection
Section "Monitor"
Identifier "Default Monitor"
Option "DPMS" "off"
DisplaySize 405 253 # 120 DPI @ 1920x1200 & virtual
Option "PreferredMode" "1440x900"
Option "Panning" "1920x1200"
EndSection
Section "Screen"
Identifier "Default Screen"
Device "Default Device"
Monitor "Default Monitor"
EndSection
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
or
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.
In freedesktop.org Bugzilla #39949, Felix Miata (mrmazda) wrote : | #67 |
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.
In freedesktop.org Bugzilla #39949, Felix Miata (mrmazda) wrote : | #68 |
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
In freedesktop.org Bugzilla #39949, Felix Miata (mrmazda) wrote : | #69 |
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_
# head -n16 /var/log/Xorg.0.log (beta warning stripped)
[ 31.305]
X.Org X Server 1.15.99.901 (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-
[ 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/
grep: /etc/X11/
# grep -v ^\# /etc/X11/xorg.conf | grep DisplaySize
grep: /etc/X11/xorg.conf: no such file or directory
# grep -v ^\# /etc/X11/
grep: /etc/X11/
# 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)
In freedesktop.org Bugzilla #39949, Felix Miata (mrmazda) wrote : | #70 |
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://
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 freedesktop.org Bugzilla #39949, Sndirsch-suse (sndirsch-suse) wrote : | #71 |
(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 |
In freedesktop.org Bugzilla #39949, Felix Miata (mrmazda) wrote : | #72 |
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.
In freedesktop.org Bugzilla #39949, Felix Miata (mrmazda) wrote : | #73 |
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.
In freedesktop.org Bugzilla #39949, Felix Miata (mrmazda) wrote : | #74 |
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
In freedesktop.org Bugzilla #39949, Romano Giannetti (romano-giannetti) wrote : | #75 |
Probably this bug has been marked invalid because there is a mix of two bugs here: one is related to panning (which I do not know if it's fixed or no), and the other one to mouse constraints when scaling.
I have X.Org X Server 1.14.5 , and if I issue
xrandr --output LVDS1 --scale 2x2
the screen scales correctly, but then the mouse is restricted to the (original 1x1 viewport) upper left quarter of the screen, making the scaling completely unuseful.
It is quite easily reproducible.
In freedesktop.org Bugzilla #39949, Miguel Angel Fraile (oldmike-gmail) wrote : | #76 |
Totally agree.
So perhaps this could be renamed to something like "Xrandr scaling does not
scale the mouse pointer area" or be splitted to a different bug report.
On Apr 21, 2014 4:26 PM, <email address hidden> wrote:
> *Comment # 53 <https:/
> on bug 39949 <https:/
> Romano Giannetti <email address hidden> *
>
> Probably this bug has been marked invalid because there is a mix of two bugs
> here: one is related to panning (which I do not know if it's fixed or no), and
> the other one to mouse constraints when scaling.
>
> I have X.Org X Server 1.14.5 , and if I issue
>
> xrandr --output LVDS1 --scale 2x2
>
> the screen scales correctly, but then the mouse is restricted to the (original
> 1x1 viewport) upper left quarter of the screen, making the scaling completely
> unuseful.
>
> It is quite easily reproducible.
>
> -------
> You are receiving this mail because:
>
> - You are on the CC list for the bug.
>
>
In freedesktop.org Bugzilla #39949, Felix Miata (mrmazda) wrote : | #77 |
(In reply to comment #53)
> Probably this bug has been marked invalid because there is a mix of two bugs
> here: one is related to panning (which I do not know if it's fixed or no),
> and the other one to mouse constraints when scaling
This bug has not been marked invalid.
> I have X.Org X Server 1.14.5 , and if I issue
> xrandr --output LVDS1 --scale 2x2
> the screen scales correctly, but then the mouse is restricted to the
> (original 1x1 viewport) upper left quarter of the screen, making the scaling
> completely unuseful.
That's why the summary says doesn't "work". Unuseful and doesn't work are functionally equivalent ways of saying it is broken (constrained mouse) and thus not providing function (able to reach all areas of screen with mouse) that makes it usable (can't click mixer icon on panel).
In freedesktop.org Bugzilla #39949, Alexander E. Patrakov (patrakov-gmail) wrote : | #78 |
Why is this bug still in the NEEDINFO state? I.e. what info is needed before someone reviews the patch?
In freedesktop.org Bugzilla #39949, Alexander E. Patrakov (patrakov-gmail) wrote : | #79 |
The bug is also relevant to scaling. You can test it (assuming a 1920x1200 monitor) with the following example commands:
xrandr --fb 3840x2400
xrandr --output DVI-I-1 --scale 2x2
The example has no purpose as written, except to illustrate the bug, but similar "xrandr --scale" commands are useful if one wants to mirror a 1366x768 laptop screen and a 1920x1080 projector for a presentation.
In freedesktop.org Bugzilla #39949, Jamundso (jamundso) wrote : | #80 |
(In reply to comment #56)
> Why is this bug still in the NEEDINFO state? I.e. what info is needed before
> someone reviews the patch?
Worth repeating...
Why is this bug still in the NEEDINFO state?
In freedesktop.org Bugzilla #39949, Harald Judt (hjudt) wrote : | #81 |
I too can confirm that scaling doesn't work with radeon.
On a laptop with intel driver, the following works fine, except the mouse pointer is confined to the mode area, but I believe that is a known xorg-server bug:
xrandr --fb 1920x1080 --output eDP1 --mode 1600x900 --scale-from 1920x1080
The same command, adapted to the radeon output device doesn't work. Same software configuration (xorg-1.15.99.903, libdrm-git, mesa-git, xf86-video-ati-git, various kernel versions (at the moment 3.15.2)). Screen rotation does work, though.
In freedesktop.org Bugzilla #39949, Harald Judt (hjudt) wrote : | #82 |
The patch from attachment #94929 solves the issues with constraining the mouse pointer, so everything works fine on intel. I will file a separate bug for the radeon driver.
In freedesktop.org Bugzilla #39949, Alan Coopersmith (alan-coopersmith) wrote : | #83 |
(In reply to comment #58)
> Why is this bug still in the NEEDINFO state?
Because there are approximately zero active Xorg developers with enough
time to keep up on bugzilla. Patches mailed to the xorg-devel mailing
list may get reviewed & applied faster, as described on:
http://
In freedesktop.org Bugzilla #39949, Alexander E. Patrakov (patrakov-gmail) wrote : | #84 |
Today I talked about this bug with Keith Packard. As a result of our testing, I have to state that, with the patch, the pointer is not constrained properly on the right side if one applies keystone correction. That's with xorg-server 1.16.1, will now retest with the latest git.
In freedesktop.org Bugzilla #39949, Alexander E. Patrakov (patrakov-gmail) wrote : | #85 |
Retested with the latest git. The patch indeed breaks constraining the mouse on the right side when keystone correction is active. However, the whole "keystone correction" feature is already so horribly broken that I'd just propose to drop it.
The breakage is that, if you click something, the click will not go into a point that you intended to click. I.e. you can't even undo the damage using the xkeystone GUI.
In freedesktop.org Bugzilla #39949, Gnome-9 (gnome-9) wrote : | #86 |
Tested modified Chris Wilson's patch with 1.16.0 on Ubuntu, works (no keystone).
https:/
In freedesktop.org Bugzilla #39949, Alex Fiestas (afiestas) wrote : | #87 |
With the proliferation of hidpi laptops having scale properly working is becoming more important since it is the only way of using embedded and external displays with a decent experience.
I do not know for what keystone is used these days but, maybe we could consider breaking it in favor of scale?
We can't wait until Wayland + al Compositors to implement scaling imho.
Thanks.
In freedesktop.org Bugzilla #39949, Jymbob (james-scholes) wrote : | #88 |
(In reply to Alex Fiestas from comment #65)
> With the proliferation of hidpi laptops having scale properly working is
> becoming more important since it is the only way of using embedded and
> external displays with a decent experience.
>
> I do not know for what keystone is used these days but, maybe we could
> consider breaking it in favor of scale?
>
> We can't wait until Wayland + al Compositors to implement scaling imho.
>
> Thanks.
Seconded. Chris's patch has been around for over a year. A second screen attached to a HiDPI laptop is now a far more common use case than pre-output keystoning.
If necessary we could open a new ticket (this has been suggested before) to isolate the scaling issue.
James
In freedesktop.org Bugzilla #39949, Pali (pali) wrote : | #89 |
James, better create new bug ticked for it...
In freedesktop.org Bugzilla #39949, Niccolò Belli (darkbasic) wrote : | #90 |
Can someone please help me to port this little patch to xorg-1.17.2?
https:/
This is part of the Ubuntu patch updated against 1.16.
In freedesktop.org Bugzilla #39949, Jeremy Sequoia (jeremyhu) wrote : | #91 |
I suggest you ask on xorg-devel about your patch.
In freedesktop.org Bugzilla #39949, Markus Ortel (markus-ortel) wrote : | #92 |
Not to bug you guys ;-), but as we are on the road to christmas in 2016 ...
Any news? Is there another bug ticket? Is status "NEEDINFO" still valid?
Does anyone really needs info I or someone else can provide?
In freedesktop.org Bugzilla #39949, Alexander E. Patrakov (patrakov-gmail) wrote : | #93 |
No news, the bug is still reproducible, and it is not clear what information is needed.
In freedesktop.org Bugzilla #39949, Jeremy Sequoia (jeremyhu) wrote : | #94 |
AFAICT, nobody has followed my direction above and brought this up for discussion on xorg-devel. Without that, it's not likely to be fixed.
In freedesktop.org Bugzilla #39949, Felix Miata (mrmazda) wrote : | #95 |
Broken panning, Bug 77321 , got a downstream fix 5 months ago in
https:/
In freedesktop.org Bugzilla #39949, Timo Aaltonen (tjaalton) wrote : | #96 |
if I'm reading things correctly, this is what suse added
which is not what has been proposed here so far
In freedesktop.org Bugzilla #39949, Sndirsch-suse (sndirsch-suse) wrote : | #97 |
(In reply to Timo Aaltonen from comment #74)
> if I'm reading things correctly, this is what suse added
>
> https:/
> cgi?id=
>
> which is not what has been proposed here so far
Egbert still plans to bring this patch/topic up on xorg-devel for discussion, so things hopefully won't get lost.
In freedesktop.org Bugzilla #39949, Jhonmerced5 (jhonmerced5) wrote : | #98 |
Wow, guys. This discussion definitely took some time ;) Any update? https:/
In freedesktop.org Bugzilla #39949, Robertvanwezel (robertvanwezel) wrote : | #99 |
Yeah, really curious about an update!
https:/
In freedesktop.org Bugzilla #39949, Brianbrowns123 (brianbrowns123) wrote : | #100 |
Stefan, any news from Egbert on this? Why it takes so long
--
Brian
https:/
In freedesktop.org Bugzilla #39949, Mattst88 (mattst88) wrote : | #101 |
I sent Chris Wilson's patch to the mailing list.
Changed in xorg-server: | |
status: | Incomplete → Confirmed |
In freedesktop.org Bugzilla #39949, Mattst88 (mattst88) wrote : | #102 |
Fixed by:
https:/
Will be in xserver-1.20.
Changed in xorg-server: | |
status: | Confirmed → Fix Released |
Steve Langasek (vorlon) wrote : | #103 |
The Precise Pangolin has reached end of life, so this bug will not be fixed for that release
Changed in xorg-server (Ubuntu Precise): | |
status: | Triaged → Won't Fix |
Ryan Sutton (oldmansutton) wrote : | #104 |
Well there you go, if you just wait 10 years, you don't ever have to fix anything. Could have fixed it 5-6 years ago, but why bother, right?
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.
Description:
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. /bugzilla. redhat. com/show_ bug.cgi? id=710191
https:/
A patch has been proposed, but seems not to be moving. lists.x. org/archives/ xorg-devel/ 2011-June/ 023715. html
> 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://
xorg-x11- server- Xorg-1. 10.3-1. fc15.x86_ 64 4.fc15. x86_64 #1 SMP Fri Jul 29 18:46:53 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
Linux sirius.localdomain 2.6.40-
01:00.0 VGA compatible controller: ATI Technologies Inc Mobility Radeon HD 3400 Series
radeon driver.