After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 751070 - gdk_screen_get_monitor_geometry() with proprietary NVIDIA hardware and panning
gdk_screen_get_monitor_geometry() with proprietary NVIDIA hardware and panning
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Backend: X11
3.0.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2015-06-16 19:32 UTC by Thomas Richter
Modified: 2018-04-15 00:00 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Thomas Richter 2015-06-16 19:32:36 UTC
The semantics of the geometry information returned by gdk_screen_get_monitor_geometry() does not seem to be consistent between various X11 drivers if panning is enabled. 

Specifically, if one enables on a 1280x1024 panning with the command

xrandr --output DVI-I-3 --panning 2560x2048 # or similar

on a system with NVIDIA hardware, then the information returned by this call differs between the nouveau driver and the proprietary NVIDIA driver.

The nouveau driver returns as monitor geometry the total panning area (here: 2560x2048), whereas the NVIDIA driver returns instead the visible area on the monitor, in pixels (here: 1280x1024).

The problem seems to be related to the XRRGetCrtInfo() call from X11 which is used by libgtk+ to obtain this information. Apparently, libxrandr does not seem to be well documented enough to allow proper interpretation of the returned values. Given the name "Monitor Geometry", I am tempted to believe that the proprietary nvidia driver might be even correct.

In any event, it would probably be more systematic to return screen->width and screen->height (screen = the X11 screen structure) since that seems to be what most software (for example xfce4) seems to expect to work properly with panning active, and it would be at least consistent with what the nouveau driver (and the intel driver, on different hardware) returns via XRRGetCrtInfo().
Comment 1 Matthias Clasen 2015-06-18 20:53:48 UTC
If different drivers report inconsistent values, that should be reported as a bug of those X drivers.

A brief look at Xrandr.h seems to indicate that XCrtcInfo has no information at all on panning, and you have to use XRRGetPanning to get that.

I'm not convinced it makes sense to expose that in gdk, tbh.
Comment 2 Thomas Richter 2015-06-19 08:54:13 UTC
We don't disagree on XcrtInfo having "no information on panning", but what does that actually mean? Does it mean "returns information on the monitor size in pixels" or does it mean "returns the drawable area?"

For filing a bug report, one would first have to indicate what exactly the bug is. One can hardly break an interface that is not documented anywhere and whose interpretation is left to the reader. (-;

My current understanding of this affair is that gdk_screen_get_monitor_geometry() and/or XRRGetCrtInfo() are not well-documented enough to allow stable use in the presence of panning.

Once I have a proper definition of the interface (how it is supposed to be and what do the values mean), no problem filing bug reports to X drivers. But first things first: What *is* exactly the interface that is broken here?

IOW, it requires *at least* a documentation update of the gdk library to ensure that the values returned by gdk_screen_get_monitor_geometry() can be interpreted correctly even in the presence of panning. I don't know what the current function does return or should return, so I'm of little help here. I'm only saying that the interface it currently implements is not properly defined, so it breaks applications (i.e. xfce4) that depend on it. I really see this breakage here.
Comment 3 Matthias Clasen 2015-06-19 11:15:48 UTC
To me, panning doesn't seem like a supportable feature, so I'd rather ignore it than spent tons of time on figuring out how to support it.

But here's my 5c anyway, wrt to interpreting the scarce documentation:

The xrandr man page states:

"As  soon as panning is enabled, the CRTC position can change with every  pointer  move."

That only makes sense if the crtc geometry is the "monitor size in pixels". If it was "drawable area", then the position wouldn't change.
Comment 4 Thomas Richter 2015-06-19 11:28:33 UTC
Some more light on this by Chris Wilson (xorg). Apparently, the problem is that panning was introduced with randr1.3, and there it returns (as observed on intel, radeon and nouveau) the entire panning area. However, NVIDIA does not support randr1.3, but only randr1.2. The type of panning they support is a proprietary extension of randr1.2, which - however - does not implement the full interface of randr1.2. In particular, it does not support the panning extension (though supports panning), and hence returns the wrong information.

*sigh*
Comment 5 Matthias Clasen 2018-02-10 05:13:15 UTC
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
Comment 6 Matthias Clasen 2018-04-15 00:00:31 UTC
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla.

If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab:

https://gitlab.gnome.org/GNOME/gtk/issues/new