Bug 655212
| Summary: | RandR 1.3 panning doesn't work | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Felix Kuehling <felix.kuehling> | ||||||||||||
| Component: | xorg-x11-server | Assignee: | Adam Jackson <ajax> | ||||||||||||
| Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> | ||||||||||||
| Severity: | medium | Docs Contact: | |||||||||||||
| Priority: | low | ||||||||||||||
| Version: | 6.0 | CC: | airlied, hgkamath, hoolabaloooo, tpelka, vbenes | ||||||||||||
| Target Milestone: | rc | Keywords: | Triaged | ||||||||||||
| Target Release: | --- | ||||||||||||||
| Hardware: | Unspecified | ||||||||||||||
| OS: | Unspecified | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||
| Doc Text: |
Panning was broken in RHEL 6.1.
Users could no longer configure panning modes on the X server using randr.
Patch was taking from upstream to fix.
Panning works for users.
|
Story Points: | --- | ||||||||||||
| Clone Of: | |||||||||||||||
| : | 710191 (view as bug list) | Environment: |
RHEL 6, Radeon graphics
|
||||||||||||
| Last Closed: | 2011-12-06 14:38:29 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: | |||||||||||||||
| Bug Depends On: | |||||||||||||||
| Bug Blocks: | 713024 | ||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
Felix Kuehling
2010-11-19 21:36:09 UTC
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. Created attachment 463549 [details]
Xorg.0.log
Xorg.0.log using the free Radeon driver
Created attachment 463550 [details]
Xorg.9.log
Xorg.9.log. It's several days old but included for completeness.
Created attachment 463551 [details]
dmesg output
Created attachment 463552 [details]
/var/log/messages
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. 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. 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. 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. 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? Dear Felix, would you mind providing requested info (see #c13). Thank you Tom (In reply to comment #13) > 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? Yes, that's what I had in mind. Also present on fedora-15/x86_64/radeon HD3410/2.6.38.8-32.fc15.x86_64 xorg-x11-server-Xorg-1.10.2-1.fc15.x86_64 Cannot make local desktop pan a larger virtual screen. xrandr --fb 1600x1280 --output LVDS --mode 1280x800 --panning 1600x1280 Use Case: * enable vino * remote-desktop * enable a framebuffer size larger than LVDS with panning, note that VNC client is able to see the whole desktop. Attempts to move the mouse in the vnc client outside the constraints of the local mouse pointer, perhaps also cause the Xmouse pointer to malfunction. It become stuck and shakes rapidly in place. Should this be a separate bug in product line fedora ? Bug 710191 is already filed for Fedora 15 Created attachment 510001 [details]
710191 (RandR 1.3 panning doesn't work on Fedora)
(In reply to comment #13) > 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? The panning area becomes the X-screen area. The panning area is usually larger than the CRTC area. Regions outside CRTC area but inside the panning area should not be considered hidden, as they can be reached by panning. Yes, it should be possible to reach those screen areas by CRTC-area border crossing. The mouse should be constrained to the whole panning-area, and not just the part originally visible as the CRTC area. The mouse constraining feature is intended to keep the mouse inside only accessible areas, which includes area which can be panned to, and prevent the mouse from dragging windows to inaccessible regions. According to me, the bug is that the mouse pointer constraints are using the CRTC boundaries and not the panning area boundaries. The mouse pointer should be prevented from border crossing the the panning area boundaries into areas might be inaccessible. The fix to this issue does not come in conflict with the boundary-check-fix to keep the mouse away from inaccessible areas. Its just a matter of checking against the right boundary. 3556059 build (RHEL-6.2-xorg-rebase, /cvs/dist:rpms/xorg-x11-server/RHEL-6:xorg-x11-server-1_10_3-5_el6) completed successfully MODIFIED confirmed also on FC15, intel gma, 1.10.3-1 boy this bug is _really_ annoying. needed this both on the netbook and at work (need a "big display" emulation badly). therefore priority doesn't seem low to me personally thanks
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
New Contents:
Panning was broken in RHEL 6.1.
Users could no longer configure panning modes on the X server using randr.
Patch was taking from upstream to fix.
Panning works for users.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2011-1602.html |