Bug 77321 - xorg.con* configuration of panning for KMS supported drivers (ATI, Intel, Nouveau) quit working
Summary: xorg.con* configuration of panning for KMS supported drivers (ATI, Intel, Nou...
Status: RESOLVED WONTFIX
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/Ext/RandR (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL: https://bugzilla.opensuse.org/show_bu...
Whiteboard: downstream fixed
Keywords: regression
Depends on:
Blocks:
 
Reported: 2014-04-11 09:53 UTC by Felix Miata
Modified: 2018-07-17 10:30 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Felix Miata 2014-04-11 09:53:28 UTC
This is a fork from 2011's bug 39949 which describes more than one bug as filed and has been summarized. 

In earlier servers, e.g. Fedora's 1.9.4, openSUSE's 1.10.4 & 1.9.3 and Mandriva's 1.10.3, the following minimal xorg.conf is sufficient to enable working panning:

Section "Device"
    Identifier "Default Device"
EndSection

Section "Monitor"
    Identifier	"Default Monitor"
	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

Since sometime in 1.10.x, continuing even as of 1.16rc1, e.g. in Kubuntu's 1.11.3, when same xorg.conf is used, the mouse is constrained to the physical screen size, preventing visibly reaching the desktop portion that is below and to the right of the physical screen. This constraint is absent if instead e.g. for Intel 'xrandr  --dpi 120 --fb 1920x1200 --output VGA1 --mode 1440x900 --panning 1920x1200' is used to produce the same screen configuration.
Comment 1 Felix Miata 2016-02-24 05:29:24 UTC
This was fixed in openSUSE 13.1, 13.2, 42.1 and Tumbleweed over a month ago. That bug's owner reportedly was denied access to submit a fix here, had last submitted xorg/xserver patch accepted at https://cgit.freedesktop.org/xorg/xserver/commit/?id=44d0fd435a4eaf45e252b4f00409152a6d599dfc .
Comment 2 Alan Coopersmith 2016-02-25 20:03:03 UTC
We've never denied Egbert access to submit patches to X.Org, and since he's a
member of the X.Org Board of Directors, he would know how to appeal if we had.
Comment 3 Stefan Dirsch 2018-07-17 10:30:06 UTC
(In reply to Alan Coopersmith from comment #2)
> We've never denied Egbert access to submit patches to X.Org, and since he's a
> member of the X.Org Board of Directors, he would know how to appeal if we
> had.

Egbert's patch came in with

commit 44d0fd435a4eaf45e252b4f00409152a6d599dfc
Author: Egbert Eich <eich@suse.de>
Date:   Tue Nov 24 17:37:36 2015 +0100

    kdrive/UnregisterFd: Fix off by one

This was after xorg-server 1.18 was released.

# git describe 44d0fd435a4eaf45e252b4f00409152a6d599dfc
xorg-server-1.18.0-26-g44d0fd435

but then shortly after was considered dead code and was removed completely.

commit c0375dced38674ed98562529530d89ff02c48100
Author: Adam Jackson <ajax@redhat.com>
Date:   Fri Mar 24 15:58:53 2017 -0400

    kdrive: static and dead code cleanup

This change came after xorg-server 1.19

# git describe c0375dced38674ed98562529530d89ff02c48100
xorg-server-1.19.0-232-gc0375dced

So I'm afraid this became a WONTFIX, unless it has been fixed meanwhile via other means.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.