The xfce background drawer in xfce-backdrop.c does not work properly if panning is enabled on NVIDIA hardware using the proprietary nvidia hardware driver. The problem only appears if *panning* is enabled, and only if the *proprietary* NVIDIA driver is used. That is, to reproduce the problem, install the proprietary NVIDIA driver, and enable panning with xrandr such as: xrandr --output DVI-I-3 --panning 2560x2048 # or something similar The net result is that only the upper left corner of the screen will be filled with the background image, the rest of the screen is garbled. The problem seems to be caused by a mis-interpretation of the "monitor dimension", which could either be understood as the "available size visible on the monitor", or "the full size of the panning area". With panning enabled, the two rectangles are clearly different. The proprietary nvidia driver interprets "monitor dimension" as the physical size of the visible area on the monitor, in pixels. The nouveau driver interprets it as "the total available panning area, in pixels". On a 1280x1024 monitor with the above xrandr command active, the former will return "1280x1024", the latter "2560x2048". The problem seems to be as follows: Xfce-backdrop.c in the xfdesktop source calls gdk_screen_get_monitor_geometry() from libgtk. libgtk again calls into libxrandr, namely XRRGetCrtcInfo(). Unfortunately, the geometry it returns is not well documented enough (at least, I could not make enough sense of it), so what it returns for the proprietary NVIDIA driver is the geometry of the visible area of the monitor. For the nouveau driver, it returns the total panning area. Apparently, gdk_screen_get_monitor_geometry() does not return useful information at this point... The same problem seems to appear in Xfwm4. Here the window manager disallows moving windows out of the panning area.
Thanks for your detailed report. Did you forward this bug upstream? According to your bug description, XRRGetCrtcInfo() does not return correct data in one specific case.
Well, yes, I did, but the question is whether this is really a bug in XRRGetCrtcInfo(). The main problem I have here is that the interface of this call is not really properly described. It returns the "dimensions of the monitor". Indeed, my monitor is 1280x1024 pixels wide, so in that sense, the NVIDIA driver is actually correct. Note that the documentation does not say that it returns the "dimensions of the panning area", which would be something different. Thus, I'm not really clear that this is really an upstream bug. I would rather say that gdk_screen_get_monitor_geometry() works as advertised, unfortunately, it is not advertised complete enough to really draw the conclusion that it should return the panning area. (-; It is probably the wrong call for the information you need: https://developer.gnome.org/gdk3/stable/GdkScreen.html#gdk-screen-get-monitor-geometry Checking the sources of gtk++, you obtain the X11 screen dimensions(!) by gdk_screen_get_width() and gdk_screen_get_height(). These two calls return the size of the render-able area of the screen(!) and not the dimensions of the monitor(!) (for whatever the latter means). Note that screen->width and screen->height (with screen = X11 screen structure) contain the correct values, and - up to my knowledge - gdk_screen_get_XXXX() return these values. Thus, the proposed fix is to replace gdk_screen_get_monitor_geometry() by the above two calls instead.
(In reply to Thomas Richter from comment #2) > [...] > Note that screen->width and screen->height (with screen = X11 screen > structure) contain the correct values, and - up to my knowledge - > gdk_screen_get_XXXX() return these values. > > Thus, the proposed fix is to replace gdk_screen_get_monitor_geometry() by > the above two calls instead. I disagree. I reckon both xfdesktop and xfwm4 want the monitor size here, not the screen size... For xfdesktop, this is to adjust the backdrop to the actual monitor size whereas for xfwm4, this is to prevent the user from moving windows outside of the monitor, so this works as intended.
Created attachment 6315 Screen shot of my damaged desktop
Sorry, now I'm completely confused. You say that "xfce wants the monitor size, not the screen size". Is is equivalent to saying "panning does not work as intended for the nouveau driver" (and by that, for the intel driver and the radeon driver because they work all the same). Thus, the intel driver is broken? Because there I *can* move my windows freely over the entire desktop, including the panning area. Because gdk_screen_get_monitor_geometry() *there* returns the panning area, not the visible monitor area. So, *that* is a bug, you say? Huh, I always thought that this is exactly how xfce and X11 *should* work with panning enabled, namely backfill the entire area and allow users to move windows there! Second, I'm not even sure you understand the problem... it seems you miss a piece of information, so allow me to re-iterate: With the current usage of gdk_screen_get_monitor_geometry() in xfce (xfwm4 and friends), I get a garbled screen on NVIDIA hardware: The upper left area is fine, but if I scroll screen out of this area by moving the mouse to the borders of the area, I get completely trashed graphics because the xfce background fill does not backfill this area, and I cannot move windows there either. Just to re-iterate: I *can* move windows there with intel, nouveau and radeon, and I get access this area simply because X scrolls the screen to this area whenever the mouse pointer touches the border. For illustration, I'm attaching a picture of my complete desktop. I also got a reply from Chris Wilson (xorg) on this. Apparently, the misinterpretation of the return value is due to NVIDIA not supporting randr1.3. To quote Chris: /* snip */ RRCrtcGetInfo: 'x' and 'y' indicate the position of this CRTC within the screen region. They will be set to 0 when the CRTC is disabled. 'width' and 'height' indicate the size of the area within the screen presented by this CRTC. This may be different than the size of the mode due to rotation, the projective transform, and the Border property described below. They will be set to 0 when the CRTC is disabled. From ftp://download.nvidia.com/XFree86/Linux-x86/302.07/README/xrandrextension.html Known Issues RandR per-CRTC panning configuration through the RandR 1.3 RRGetPanning and RRSetPanning requests is not yet implemented. which explains the difference (since RRGetPanning is used by Xorg to determine the presented area for RRCrtcGetInfo). For Nvidia, Xorg can only report the current location of the CRTC with respect to the frontbuffer, for other RandR1.3 drivers like nouveau, it will report the full panning size as intended. -Chris /* snip */
All I am saying is both xfwm4 and xfdesktop use the desktop geometry where the desktop geometry is meant. The fact that nvidia with panning is not returning the right values as expected is a problem with nvidia, not with xfwm4 or xfdesktop. Breaking the intended behaviour of both xfdesktop and xfwm4 with all open-source drivers just to please one closed source driver with an option of seldom use (panning) would be just plain wrong.
Hold on, this is not quite true, please go into Chris' comment on this (I'm trying to dig a bit deeper in the meantime). Apparently, and this is how I understand this problem right now, NVIDIA does not return the proper values because it *cannot* return the proper values because randr1.2 does not have the abilities to return the desktop values in first place. IOW, the breakage is because either gtk+ or xfce cannot operate on X11 drivers that only support randr1.2, but not randr1.3? I somehow don't understand you... If the same interface, namely XRRGetCrtcInfo() returns semantically different information (panning area vs. monitor area) depending on data the caller has no information about and has no control about, then this looks like a broken interface to me. If gtk or xfce depends on such broken interface, then I would rather say that this requires a change. I still do not understand well enough where and how, but the current situation is not quite acceptable.
(In reply to Thomas Richter from comment #7) > IOW, the breakage is because either gtk+ or xfce cannot operate on X11 > drivers that only support randr1.2, but not randr1.3? xfce doesn't care which version or RandR the driver uses becausse it relies on a higher level API (gtk+ in this case). The proprietary driver using older API is not xfce problem. > I somehow don't understand you... If the same interface, namely > XRRGetCrtcInfo() returns semantically different information (panning area > vs. monitor area) depending on data the caller has no information about and > has no control about, then this looks like a broken interface to me. And how is that a problem with xfce? Again, nvidia using an older, deprecated RandR 1,2 interface has nothing to do with xfce. > If gtk or xfce depends on such broken interface, then I would rather say > that this requires a change. Sure, why don't you take it to the vendor of your proprietary driver, ask them for the code so you can send a patch to fix that in the driver? > I still do not understand well enough where and > how, but the current situation is not quite acceptable. Alternatively, use an open source driver, either way, that's not a bug in xfce.
What I did not understand is that panning came into play with randr1.3, and the panning NVIDIA offers is a proprietary extension that is not compatible with panning as offered by the randr1.3. I would love to use the nouveau driver, but it does not support OpenCL and that is something I currently depend on (besides the panning, that is).
So, it's not a bug in Xfce. I'll go ahead and close this report then.