Created attachment 58730 [details] Xorg.0.log of crashed Xorg If I try to position my main screen leftsides to my integrated screen nouveau comes out on strike: xrandr --output LVDS-1 --right-of VGA-1 Previously it was showing garbage on the external screen but now with Xorg 7.6_1.10.4-201.1 and nouveau-0.0.16_20110720_b806e3f-34 it is just switching to the text console (you can see it) and then crashing Xorg itself. A Xinerama setup with nouveau would be very fine for my working environment (external screen + keyboard, at different resolution).
Created attachment 58732 [details] Xorg.0.log: external screen only, 1920x1200 Just setting the external screen to 1920x1200 gives an error as well: # xrandr --output LVDS-1 --off # xrandr --output VGA-1 --mode 1920x1200 X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 149 (RANDR) Minor opcode of failed request: 7 (RRSetScreenSize) Serial number of failed request: 28 Current serial number in output stream: 29
Hi Elmar Looking at your second log, I've noticed the following The kernel is failing to allocate new buffer object, meaning that either * xf86-video-nouveau, is not requesting the correct format/size * libdrm is not wise enough to forward the info to the kernel or * kernel is not aware about the specific format, etc Can you please check if there is an updated packages from openSUSE - see bug 47288 comment 2 Thanks Emil
By time this is the latest version. The only thing I can offer at the moment is to run Xorg with -logverbose 7, trying to strace it or to setterm a higher kernel reporting stage.
In deed, nouveau seems to have a problem in allocating video memory. I have 2GB main memory but however an Nvidia GForce 420 Go which uses to come with 32MB of dedicated video RAM like in most embedded systems. I can achieve a resolution off up to 1280x1024 (1600x1200 does not work) with a proper xorg.conf however not with desktop video effects. The desired setup as supported by the proprietary driver is 1920x1200+1024x768, xinerama. Switching DRI off doesn`t make a difference.
Created attachment 58815 [details] Xorg.0.log: xinerama configuration
Created attachment 58817 [details] Xorg.0.log: xinerama setup(right one) Here come the test results for full xinerama setup including -logverbose 7, strace & dmesg.
Created attachment 58818 [details] xorg.conf: xinerama setup
Created attachment 58819 [details] Xorg.strace: xinerama setup
Created attachment 58820 [details] Xorg.ltrace: xinerama setup
Created attachment 58821 [details] Xorg.dmesg: xinerama setup
Could you retest with more recent software? I think there have been a lot of changes both to xf86-video-nouveau/libdrm and the kernel since you tested this.
Well, I would have to reinstall on one of those machines ...
You could also boot with, e.g., an Arch livecd/liveusb which is fairly up-to-date.
Well done!; it works with oS13.1_MS4, xorg-x11-driver-video-nouveau-1.0.9-1.2.i586 for most practical purposes very well. However by finally plugging xranding and unplugging different monitors I did finally get an error on re-enabling the same screen with different resolution (i.e. --off -right-of --mode newone). The error may or may not have to do something with nouveau; see for the logs (using xorg-x11-7.6_1-9.2.noarch, Xorg server 1.14.2, release date 2013-06-25).
Created attachment 85551 [details] /var/log/messages (wild-xranding with different resolution)
Created attachment 85552 [details] Xorg.0.log (wild xranding with different resolution)
Is it a persistent failure (i.e. do future commands that used to work before start failing), or is it a "if I use this weird set of 75 arguments, it fails"? If the latter, what's exactly are the arguments?
No, all further requests have failed from a certain xrandr command on. The command looked very normal like this: xrandr --output VGA-1 --right-of LVDS-1 --mode 800x6000 The only difference to commands issued before was the resolution (given here as 800x600; may have been 1024x768 or something else).
Almost the same issue as originally, short on memory :'( I admit some work on optimising such cases for low (gpu/vram) memory may be needed, but I do not think it high up the priority list. Read - it's a most likely a gem/ttm work than nouveau specific. Either way anyone is welcome to give it a crack Following the messages from xorg.log drmmode_crtc_shadow_allocate > nouveau_allocate_surface > (libdrm) nouveau_bo_new > (most likely) drmCommandWriteRead(dev->fd, DRM_NOUVEAU_GEM_NEW...) > (kernel) nouveau_gem_ioctl_new > (most likely) nouveau_gem_new > chaos x)
I noticed that the kernel you used in the last test was compiled with gcc 4.8. Was libdrm also compiled with gcc 4.8? If so, please try it with libdrm-2.4.48 or later.
It should be the same compiler as I used the default toolkit of the same version of the distribution.
This is likely still an issue with some older machines though testing it got stuck because of a kernel s2ram bug: http://mirror1.htu.tugraz.at/archlinux/iso/2015.11.01/archlinux-2015.11.01-dual.iso. The notebook used to test this is still alive.
Bug 70510 seems to be the newer candidate (pls. correct if I missed sth.).
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.