Bug 710191
Summary: | [RV620] RandR 1.3 panning doesn't work | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Daniel <danielsjensen1> | ||||||
Component: | xorg-x11-server | Assignee: | Peter Hutterer <peter.hutterer> | ||||||
Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 15 | CC: | felix.kuehling, hgkamath, mcepl, rdtennent, samuel-rhbugs, tiagomatos, vbenes, xgl-maint | ||||||
Target Milestone: | --- | Keywords: | Triaged | ||||||
Target Release: | --- | ||||||||
Hardware: | x86_64 | ||||||||
OS: | Linux | ||||||||
Whiteboard: | [cat:conf_input] | ||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | 655212 | Environment: |
RHEL 6, Radeon graphics
|
||||||
Last Closed: | 2011-09-14 09:33:57 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Daniel
2011-06-02 16:02:26 UTC
Created attachment 510002 [details]
xrandr -q, dmesg, /var/log/Xorg.0.log, /var/log/messages
Created attachment 510006 [details]
xrandr -q, dmesg, /var/log/Xorg.0.log, /var/log/messages (2nd attempt)
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. 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. 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. 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. 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. 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. 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 (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. still present in xorg-x11-server-Xorg-1.10.4-1.fc15.x86_64 upstream bug report RandR panning doesn't work https://bugs.freedesktop.org/show_bug.cgi?id=39949 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. 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? |