Bug 710191 - [RV620] RandR 1.3 panning doesn't work
Summary: [RV620] RandR 1.3 panning doesn't work
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-server
Version: 15
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Peter Hutterer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: [cat:conf_input]
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-06-02 16:02 UTC by Daniel
Modified: 2018-04-11 08:31 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 655212
Environment:
RHEL 6, Radeon graphics
Last Closed: 2011-09-14 09:33:57 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
xrandr -q, dmesg, /var/log/Xorg.0.log, /var/log/messages (275.73 KB, text/plain)
2011-06-26 22:59 UTC, Ganapathi Kamath
no flags Details
xrandr -q, dmesg, /var/log/Xorg.0.log, /var/log/messages (2nd attempt) (369.10 KB, text/plain)
2011-06-26 23:45 UTC, Ganapathi Kamath
no flags Details


Links
System ID Private Priority Status Summary Last Updated
FreeDesktop.org 39949 0 None None None Never

Description Daniel 2011-06-02 16:02:26 UTC
+++ This bug was initially created as a clone of Bug #655212 +++

Description of problem:
Panning with RandR 1.3 doesn't work. The "xrandr --output ... --panning ..." command resizes the desktop, but the mouse pointer can't be moved beyond the visible part of the desktop. Thus panning is impossible.


Version-Release number of selected component (if applicable):
xorg-x11-server-Xorg-1.10.1-14.fc15.x86_64


How reproducible:
Steps to Reproduce:
1. Open a terminal
2. run "xrandr", not the output name of the connected monitor (e.g. LVDS1)
3. xrandr --fb 1024x768 --output LVDS1 --mode 1024x600 --panning 1024x768 (something bigger than the current mode)
4. move the mouse pointer to try panning
  
Actual results:
xrandr --fb 1024x768 --output LVDS1 --mode 1024x600 --panning 1024x768 resizes the screen as expected. But the mouse pointer can't be moved beyond the visible part of the desktop. So panning is impossible.

Expected results:
Panning to the currently invisible part of the desktop should be possible when the mouse is moved past the edge of the viewport.

Additional info:
Currently using an Asus 1001P netbook with integrated Intel graphics.  I can almost get the correct behavior if I increase the borders in the panning command (i.e. xrandr --fb 1024x768 --output LVDS1 --mode 1024x600 --panning 1024x768x0x0/1024x768x0x0/0/0/0/168) but I then lose access to the 168 pixels on the bottom of the screen so it really isn't a valid solution.  I have the same problem using the xfce desktop manager so it probably isn't related to the new gnome-shell in fedora 15.  This problem looks so similar to Bug #655212 so I thought I would clone it but I can create a new bug report if that is the correct way to proceed.

--- Additional comment from mcepl on 2010-11-29 05:42:24 EST ---

Thanks for the bug report.  We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.

Please add drm.debug=0x04 to the kernel command line, restart computer (with free source drivers, please), and attach

* your X server config file (/etc/X11/xorg.conf, if available),
* X server log file (/var/log/Xorg.*.log)
* output of the dmesg command, and
* system log (/var/log/messages)

to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

--- Additional comment from felix.kuehling on 2010-11-29 13:59:54 EST ---

Created attachment 463549 [details]
Xorg.0.log

Xorg.0.log using the free Radeon driver

--- Additional comment from felix.kuehling on 2010-11-29 14:00:32 EST ---

Created attachment 463550 [details]
Xorg.9.log

Xorg.9.log. It's several days old but included for completeness.

--- Additional comment from felix.kuehling on 2010-11-29 14:00:56 EST ---

Created attachment 463551 [details]
dmesg output

--- Additional comment from felix.kuehling on 2010-11-29 14:01:21 EST ---

Created attachment 463552 [details]
/var/log/messages

--- Additional comment from pm-rhel on 2011-01-06 23:29:14 EST ---

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

--- Additional comment from syeghiay on 2011-01-07 11:20:15 EST ---

This request was erroneously denied for the current release of Red Hat
Enterprise Linux.  The error has been fixed and this request has been
re-proposed for the current release.

--- Additional comment from pm-rhel on 2011-02-01 00:58:49 EST ---

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

--- Additional comment from pm-rhel on 2011-02-01 13:53:13 EST ---

This request was erroneously denied for the current release of
Red Hat Enterprise Linux.  The error has been fixed and this
request has been re-proposed for the current release.

--- Additional comment from vbenes on 2011-05-26 05:32:46 EDT ---

I can see the same behaviour using nouveau driver.. I can set panning to 3000x3000 but then I cannot move screen via mouse border crossing .. is possibility to move to hidden screen areas via mouse movement the fix you want to have here?

Comment 1 Ganapathi Kamath 2011-06-26 22:59:29 UTC
Created attachment 510002 [details]
xrandr -q, dmesg, /var/log/Xorg.0.log, /var/log/messages

Comment 2 Ganapathi Kamath 2011-06-26 23:45:49 UTC
Created attachment 510006 [details]
xrandr -q, dmesg, /var/log/Xorg.0.log, /var/log/messages (2nd attempt)

Comment 3 Ganapathi Kamath 2011-06-26 23:58:06 UTC
In the first log, the command issued was
xrandr --fb 1600x1200 --output LVDS --mode 1280x800 --panning 1280x800
which is not quite right

In the second log
xrandr --fb 1600x1200 --output LVDS --mode 1280x800 --panning 1600x1200

Using 
xrandr --fb 1280x800 --output LVDS --mode 1280x800 --panning 1280x800
to restore


Use Case:
* Laptops have small screens.  Use xrandr to have a larger panned size. and use VNC from a workstation with a larger screen. let vino be enabled.

Observations: on issuing
xrandr --fb 1600x1200 --output LVDS --mode 1280x800 --panning 1600x1200

0) the local display does not pan. local mouse can maximally be moved to the orders. 

1) the VNC screen enlarges, background is drawn. 
2) If an application is in maximized state, then it maximizes to the new screen size
3) The gnome top-bar enlarges to cover the whole screen area
4) even on moving th VNC mouse, the local mouse is still trapped to the local display area. The tip of the mouse pointer is visible as a pixel when attempting to move mouse outside area
5) an unmaximized application may be dragged outside the local display area. it is completely drawn and visible in the remote VNC display. However, GUI elements outside local display area cannot be accessed as the X mouse pointer is trapped to a smaller area. attempting to click on something outside local display from the VNC client, only activates what is under the X-pointer.
6) a python xlib script that prints mouse location, always shows X pointer inside 1280x800 area, regardless. max values are at the border.

Comment 4 Ganapathi Kamath 2011-06-27 00:23:02 UTC
Panning-mechanism works, problem elsewhere ?

xrandr --fb 1600x1200 --output LVDS --mode 1280x800 --panning 1600x1200+0+0/1600x1200+0+0/32/32/32/32

This creates a 32 pixel border. 
The panning mechanism can be seen to work, although limtedly. When the mouse is moved to the border, the screen in panned and the screen area outside the 1280x800 area becomes visible, however x-mouse pointer is trapped to 1280x800 area. Therefore when moving into bottom border mouse pointer remains stuck 32 pixels above the bottom of the crtc, and further panning is prevented.

Something is artificially constraining the x-mouse pointer to the original CRTC-area.
The bug might be in the X-input side of things. The X mouse-pointer movement must be restricted to the entirety of the current screen-area.  Presently, the X pointer movement seems to be restricted to what it thinks is the original CRTC-area.  Xrandr, and otherX-window apps therefore only receive this incorrectly-restricted pointer location, and therefore do not pan, or  gui elements outside the initial area cannot be reached.

Maybe xrandr does not inform Xinput that screen area has changed, or maybe Xinput is not processing and using that information, to change the bounds of of x-mouse pointer movement.

Comment 5 Ganapathi Kamath 2011-06-27 00:40:51 UTC
X-mouse-pointer bounds are changed when screen-resolution is changed in using
gnome-control-center Display settings. ex. When changing resolution from 1280x800 to 800x600 and back. The x-mouse pointer coordinates is never allowed to be beyond the crtc area. 

Using, xrandr -q, it can be seen framebuffer size/screen size is changed automatically. Since laptop LVDS do have fixed resolutions. I believe that there is some low-level scaling, that fits the smaller resolution to the full-size of he LVDS screen, which xinput and xrandr are unaware of.

Therefore X-mouse pointer is listening to resolution-change events but not screen-size change events.

Maybe, the x-mouse pointer must absolute CRT coordinates, at which the pointer is displayed, and at the same time maintain the screen coordinates. The x-mouse pointer may not always be in the CRT unless the display in panned.

Comment 6 Ganapathi Kamath 2011-06-27 14:28:12 UTC
https://bugs.freedesktop.org/show_bug.cgi?id=20334
Mouse shouldn't move into area outside the monitors

somehow seems like a possible cause of this.

Comment 7 Matěj Cepl 2011-07-01 20:11:28 UTC
Ganapathi, please attach

* your X server config file (/etc/X11/xorg.conf, if available),
* X server log file (/var/log/Xorg.*.log)
* output of the command (depending on whether you use mouse or a touchpad)

evtest /dev/input/event5 # for PS/2 mouse
evtest /dev/input/event6 # for touchpad

* system log (/var/log/messages)

to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

Comment 8 Matěj Cepl 2011-07-01 20:33:59 UTC
Reporter, could you please provide the same the same information as requested in the comment 7 (except I don't know which /dev/input/event* device corresponds to the pointing device you use.

Comment 9 Rui Matos 2011-07-02 12:10:36 UTC
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

Comment 10 Ganapathi Kamath 2011-07-06 16:59:13 UTC
(In reply to comment #8)

$ find /etc/X11/xorg.conf*
/etc/X11/xorg.conf.d
/etc/X11/xorg.conf.d/00-system-setup-keyboard.conf
 cat /etc/X11/xorg.conf.d/00-system-setup-keyboard.conf 

Xorg.log file already attached (comment 2)
system log file /var/log/messages already attached (comment 2)

input device AT Translated Set 2 keyboard (/dev/input/event4)
input device PS/2 Mouse (/dev/input/event5)
input device AlpsPS/2 ALPS GlidePoint (/dev/input/event6)

for evtest,
The evtest works for event6, on a console screen Ctrl-Alt-F2, with events reported in touch pad coordinates as I do things with the touchpad. Didn't see anything interesting there. 
On X, it waited at the
"Testing ... (interrupt to exit)\n"
prompt for sometime, and pressed control C after no output.
meaning it was locked on read, possibly because X is already using them ?

(In reply to comment #9)
I looked at the code, and it seems to do the right thing.
You say crtcbounds is perhaps called several times elsewhere, perhaps in mouse bound check code, and that it is practical to return panning bounds in all those situations.
The only question that came to mind, is that is there a genuine situation where the an application would call crtcbounds() in order to genuinely determine the crtcbounds (what is visible on crt) and not the panning area bounds.  It is also fair to assume that no application should even know about a smaller crtc area once panning is configured.

Comment 11 Ganapathi Kamath 2011-09-12 19:16:53 UTC
still present in xorg-x11-server-Xorg-1.10.4-1.fc15.x86_64

Comment 12 Ganapathi Kamath 2011-09-14 02:27:26 UTC
upstream bug report
RandR panning doesn't work
https://bugs.freedesktop.org/show_bug.cgi?id=39949

Comment 13 Matěj Cepl 2011-09-14 09:33:57 UTC
I agree, I have joined the upstream bug (https://bugs.freedesktop.org/show_bug.cgi?id=39949) and believe that it is more appropriate to let it be resolved upstream.

Thank you for helping to make free software better.

Comment 14 Bob Tennent 2011-10-07 15:38:36 UTC
I believe I hit this bug on Centos-6.0 (xorg-x11-server-utils-7.4-15).
By accident I hit upon what might be a work-around on Fedora. After doing

xrandr --fb 2400x1600 --output LVDS1 --mode 1280x800 --panning 2400x1600

and not getting panning, I did

xrandr --output LVDS1 --scale 1x1

and it magically started to work! Who knows why?


Note You need to log in before you can comment on or make changes to this bug.