Created attachment 111332 [details] dmesg output just after attempt to switch to 800x600 and recovery When I boot up and login I end up with the desktop in 1680x1050 resolution. I can do scaling to get other effective resolutions, but if I actually try to switch the used resolution to any of the other availble ones (e.g. 1280x1024, 800x600) I end up with parts of the output scattered all over the screen in medium sized blocks. Usually the screen will switch back to 1680x1050 and work OK when I don't confirm I want to stay in the new resolution, but sometimes things end up messed up when it switches back and I ned to shutdown to recover. I am using x86_64 Fedora 21 with various kernels. I have seen this issue with the normal 3.17 kernels, 3.18 rawhide nodebug kernels and the mainline 3.19 kernel (the latter fixes another Nouveau problem I had). Currently mesa is at 10.4, though I think it was at 10.3 when I first switched this machine over to linux and I still had the same issue. The reason I care about this is that I want to play some games in wine that use 800x600 and the workaround of using xrandr scaling before and after slows things down and is ugly.
Created attachment 111333 [details] xorg.log
I restested this after updating to 3.19 with 08b022a9655bf925e6683422590306429b752ccd which included: nouveau: fix 3.18 regression for old userspace Things are still behaving the same way.
http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=74a8f4fb816b90ec1468855b88ed365b6e15876c Does this prevent your issue?
I tried out http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=74a8f4fb816b90ec1468855b88ed365b6e15876c but it didn't seem to change things for me. Trying to switch to 800x600 still resulted in a garbled display.
Is it worth testing this on mesa 10.5 at this time? 10.5 is in rawhide and the 3.19 kernel will probably be soon. I don't want to move the affected machine on to rawhide right now, but I could test a live image in the not too distant future.
Would it be worth testing this with i686 to see if it is x86_64 specific?
(In reply to Bruno Wolff from comment #5) > Is it worth testing this on mesa 10.5 at this time? 10.5 is in rawhide and > the 3.19 kernel will probably be soon. I don't want to move the affected > machine on to rawhide right now, but I could test a live image in the not > too distant future. The issue is almost definitely in the kernel. Potentially it's tickled by xf86-video-nouveau. Mesa is almost definitely not connected.
Does http://cgit.freedesktop.org/mesa/drm/commit/?id=d7c0a08bc576deb07df6c3f91f393ca8edd0c4bf (modetest: Allocate dumb buffers with the correct bpp) look like a change that might help me? (i.e. is it worth me rebuilding libdrm to test?)
I tested http://cgit.freedesktop.org/mesa/drm/commit/?id=d7c0a08bc576deb07df6c3f91f393ca8edd0c4bf , but it didn't help.
Things seem to be working now. I am not sure what fixed it. I recently got mesa 10.5 and I am running 3.20 test kernels.
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.