Created attachment 144215 [details] xorg.log Driver feels stable working with default X11 apps, sleep, hibernate - ok. But when I start games, in fullscreen mode is has few issues. Openarena sometimes starts with white lines, same happens with some wine games (Jedi Knight 2). Some wine games in fullscreen show 4 displays on one screen. Screenshots and video attached.
Created attachment 144216 [details] dmesg.log
Created attachment 144217 [details] guild wars 9 displays
Created attachment 144218 [details] guildwars window mode (slow)
openarea youtube video https://youtu.be/EtvDPZ1T4E4
Based on your log, you're using fbdev. There will be no acceleration with fbdev. My guess is that your issues are with llvmpipe or whatever the software fallback you're using is. Acceleration doesn't load due to: [ 47.883] (EE) [drm] Failed to open DRM device for pci:0000:01:00.0: -19 [ 47.883] (EE) open /dev/dri/card0: No such file or directory Not sure what would cause that. Probably some sort of oddness in the setup/permissioning of something? You appear to be using systemd, which has a weird handoff with X that I never quite understood...
Thanks for tips. Seems like I'm not the only one: https://askubuntu.com/questions/1038899/xorg-fails-to-start-after-upgrade-to-18-04-dev-dri-card0-no-such-file My drm file exists and readable: axet@axet-laptop:~$ ls -al /dev/dri/ total 0 drwxr-xr-x 3 root root 100 мая 10 17:41 . drwxr-xr-x 21 root root 4640 мая 10 17:42 .. drwxr-xr-x 2 root root 80 мая 10 17:41 by-path crw-rw----+ 1 root video 226, 0 мая 10 17:41 card0 crw-rw----+ 1 root video 226, 128 мая 10 17:41 renderD128 axet@axet-laptop:~$ no cat errors: axet@axet-laptop:~$ cat /dev/dri/card0 ^C axet@axet-laptop:~$ all with disabled selinux: axet@axet-laptop:~$ getenforce Disabled axet@axet-laptop:~$
J'accuse ... systemd. I have no idea how that handoff is meant to work, I think it's supposed to get a file handle somehow for the card device? I don't know and am not particularly inclined to find out. Maybe someone else who looks at this bug tracker knows. Perhaps you can get some help from ubuntu support channels? This doesn't seem to be a nouveau issue (at least not yet).
Created attachment 144220 [details] lightdm xorg logs I switched from gdm to lightdm and "No such file or directory" gone. Thanks to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748463 and 'sudo lsof /dev/dri/card0' But graphics issues are the same!
(In reply to Alexey Kuznetsov from comment #8) > Created attachment 144220 [details] > lightdm xorg logs > > I switched from gdm to lightdm and "No such file or directory" gone. Thanks > to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748463 and 'sudo lsof > /dev/dri/card0' > > But graphics issues are the same! OK well those logs look MUCH happier. Now ... that "panel gets messed up with vertical white lines" thing is weird. That feels like that would happen on a modeswitch, e.g. when switching into full-screen mode of a game that's not running at 2880x1800, you want to change resolutions. (e.g. to 1024x768). Looks like we're not providing some setting quite right. Perhaps the panel needs us to do scaling... here are the valid modes reported: [ 36.683] (II) NOUVEAU(0): Modeline "2880x1800"x60.0 337.75 2880 2928 2960 3040 1800 1803 1809 1852 +hsync -vsync (111.1 kHz eP) [ 36.683] (II) NOUVEAU(0): Modeline "1920x1200"x60.0 193.48 1920 2056 2256 2592 1200 1203 1209 1245 -hsync +vsync (74.6 kHz) [ 36.683] (II) NOUVEAU(0): Modeline "1920x1080"x60.0 173.11 1920 2048 2248 2576 1080 1083 1088 1120 -hsync +vsync (67.2 kHz) [ 36.683] (II) NOUVEAU(0): Modeline "1600x1200"x60.0 161.23 1600 1712 1880 2160 1200 1203 1207 1245 -hsync +vsync (74.6 kHz) [ 36.683] (II) NOUVEAU(0): Modeline "1680x1050"x60.0 146.36 1680 1784 1960 2240 1050 1053 1059 1089 -hsync +vsync (65.3 kHz) [ 36.683] (II) NOUVEAU(0): Modeline "1400x1050"x60.0 121.79 1400 1488 1632 1864 1050 1053 1057 1089 -hsync +vsync (65.3 kHz) [ 36.683] (II) NOUVEAU(0): Modeline "1280x1024"x59.9 109.10 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync (63.7 kHz) [ 36.683] (II) NOUVEAU(0): Modeline "1280x960"x60.0 101.34 1280 1360 1488 1696 960 963 967 996 -hsync +vsync (59.8 kHz) [ 36.683] (II) NOUVEAU(0): Modeline "1152x864"x60.0 81.77 1152 1216 1336 1520 864 867 871 897 -hsync +vsync (53.8 kHz) [ 36.683] (II) NOUVEAU(0): Modeline "1024x768"x59.9 63.53 1024 1072 1176 1328 768 771 775 798 -hsync +vsync (47.8 kHz) [ 36.683] (II) NOUVEAU(0): Modeline "800x600"x60.0 38.31 800 832 912 1024 600 603 607 624 -hsync +vsync (37.4 kHz) [ 36.683] (II) NOUVEAU(0): Modeline "640x480"x59.9 23.98 640 664 720 800 480 483 487 500 -hsync +vsync (30.0 kHz) [ 36.683] (II) NOUVEAU(0): Modeline "720x400"x60.0 22.41 720 744 808 896 400 403 413 417 -hsync +vsync (25.0 kHz) [ 36.683] (II) NOUVEAU(0): Modeline "640x400"x60.0 20.00 640 664 720 800 400 403 409 417 -hsync +vsync (25.0 kHz) [ 36.683] (II) NOUVEAU(0): Modeline "640x350"x59.8 17.52 640 664 720 800 350 353 363 366 -hsync +vsync (21.9 kHz) Can you try, one-by-one, switching to them (e.g. with xrandr -s 1920x1200) and seeing if that's what causes the screwup? Is it only some modes, or any non-2880x1800 mode?
Yep, xrandr -s 1920x1200 messing screen up.
some modes create GW like screen, some open arena screen. Non are working but 2880x1800
Can you try like one or two other ones just to confirm? You can do like "xrandr -s xxxxx; sleep 5; xrandr -s 2880x1800" which will restore the old resolution. You can tell nouveau to do the scaling itself by setting the scaling mode xrandr property to full. Something like xrandr --prop "Scaling Mode" "Full" I'm going on memory, so run "xrandr --props" to get the actual name of the property.
Confirming: none modes are working. Modes below 640x480 - breaking X-server (only mouse cursor visible)
xrandr --output eDP-1 --set "scaling mode" "Full" fix the issue. When I use "Full" scaling, resolution switch properly, "720x400" killing Xserver. Same as: xrandr --output eDP-1 --set "scaling mode" "Full aspect" Working fine, but scaling properly with black box around.
When you say 720x400 "kills" the Xserver in scaling mode = full ... what do you mean exactly? Xorg process dies? Kernel hangs? I don't remember where the scaling is done, but IIRC it's in the kernel, so we could be driving the scaling engine incorrectly in certain cases.
No matter what mode "Full", "Default" 720x400 enter wired mode: feels like static screen below cursor and only mouse cursor moving, I can't change or click anything.
(In reply to Alexey Kuznetsov from comment #16) > No matter what mode "Full", "Default" 720x400 enter wired mode: feels like > static screen below cursor and only mouse cursor moving, I can't change or > click anything. OK, so there's no crash. It just doesn't work. Can you switch back from it? e.g. xrandr -s 720x400; sleep 5; xrandr -s 2880x1800 does that come back? Or is it stuck forever? If it's stuck, could you see if there's anything in the kernel logs?
I did several tests and now it working, probably it is dropbox hangs the system for few minutes during scanning.
(In reply to Alexey Kuznetsov from comment #18) > I did several tests and now it working, probably it is dropbox hangs the > system for few minutes during scanning. OK, so ... can you elaborate a bit on what's working and what's not? Presumably the "scaling mode" is still required for you? Or are you saying that switching to 720x400 is still broken, even with the scaling mode = full, but switching back to 2880x1800 afterwards works OK?
I have to use xrendr command to make resolution switching work. Default mode produces broken white lines.
(In reply to Alexey Kuznetsov from comment #20) > I have to use xrendr command to make resolution switching work. Default mode > produces broken white lines. Default mode is 2880x1800 -- I thought that worked OK. Perhaps provide the sequence of commands that works and the sequence that doesn't?
by "Default" I mean not calling xrendr. Without calling xrender (I'm calling it Default) only mode which is working is 2880x1800. If I xrendr "Full" or "Full aspect" all modes are working (previous 720x400 issues most likly due to dropbox freezes the system) Sorry for spammy and ambiguous conversation.
Hm. Curious. Based on the EDID data supplied, you only have a single real mode in there. And nouveau has logic to enable scaling in such cases. However it only checks for DRM_MODE_TYPE_DRIVER, but should probably check USERDEF in there as well? I don't know that logic too well. --- EDID version: 1.4 Manufacturer: APP Model a022 Serial Number 0 Made in week 4 of 2013 Digital display 8 bits per primary color channel DisplayPort interface Maximum image size: 33 cm x 21 cm Gamma: 2.20 Supported color formats: RGB 4:4:4 First detailed timing includes the native pixel format and preferred refresh rate Display x,y Chromaticity: Red: 0.6533, 0.3339 Green: 0.2998, 0.6201 Blue: 0.1464, 0.0498 White: 0.3125, 0.3291 Established timings supported: Standard timings supported: Detailed mode: Clock 337.750 MHz, 331 mm x 207 mm 2880 2928 2960 3040 hborder 0 1800 1803 1809 1852 vborder 0 +hsync -vsync VertFreq: 59 Hz, HorFreq: 111101 Hz Monitor name: Color LCD Dummy block Dummy block Checksum: 0xde (valid)
Alexey: Could you run grep . /sys/class/drm/card*-*/modes I'm curious if only X is generating those extra modes, or if the kernel is as well. (The mode generation logic is ... very difficult to process in one's head.)
axet@axet-laptop:~/Downloads$ grep . /sys/class/drm/card*-*/modes /sys/class/drm/card0-eDP-1/modes:2880x1800 /sys/class/drm/card0-eDP-1/modes:1920x1200 /sys/class/drm/card0-eDP-1/modes:1920x1080 /sys/class/drm/card0-eDP-1/modes:1600x1200 /sys/class/drm/card0-eDP-1/modes:1680x1050 /sys/class/drm/card0-eDP-1/modes:1400x1050 /sys/class/drm/card0-eDP-1/modes:1280x1024 /sys/class/drm/card0-eDP-1/modes:1280x960 /sys/class/drm/card0-eDP-1/modes:1152x864 /sys/class/drm/card0-eDP-1/modes:1024x768 /sys/class/drm/card0-eDP-1/modes:800x600 /sys/class/drm/card0-eDP-1/modes:640x480 /sys/class/drm/card0-eDP-1/modes:720x400 /sys/class/drm/card0-eDP-1/modes:640x400 /sys/class/drm/card0-eDP-1/modes:640x350 axet@axet-laptop:~/Downloads$ Also, "Full aspect" cut display from left and right on following resolutions: 1920x1080 720x400 640x350
(In reply to Alexey Kuznetsov from comment #25) > axet@axet-laptop:~/Downloads$ grep . /sys/class/drm/card*-*/modes > /sys/class/drm/card0-eDP-1/modes:2880x1800 > /sys/class/drm/card0-eDP-1/modes:1920x1200 > /sys/class/drm/card0-eDP-1/modes:1920x1080 > /sys/class/drm/card0-eDP-1/modes:1600x1200 > /sys/class/drm/card0-eDP-1/modes:1680x1050 > /sys/class/drm/card0-eDP-1/modes:1400x1050 > /sys/class/drm/card0-eDP-1/modes:1280x1024 > /sys/class/drm/card0-eDP-1/modes:1280x960 > /sys/class/drm/card0-eDP-1/modes:1152x864 > /sys/class/drm/card0-eDP-1/modes:1024x768 > /sys/class/drm/card0-eDP-1/modes:800x600 > /sys/class/drm/card0-eDP-1/modes:640x480 > /sys/class/drm/card0-eDP-1/modes:720x400 > /sys/class/drm/card0-eDP-1/modes:640x400 > /sys/class/drm/card0-eDP-1/modes:640x350 > axet@axet-laptop:~/Downloads$ Thanks, that's useful. I'm going to study the code a bit to figure out where these extra modes are coming from exactly. They're not in the EDID explicitly, but there's various logic to add various extra modes based on ... complex conditions. > Also, "Full aspect" cut display from left and right on following resolutions: > > 1920x1080 > 720x400 > 640x350 Hm, ideally they should have letterboxes on top/bottom in those cases. I'll have a look at the logic that does the full aspect scaling, it may be determining width/heights incorrectly.
Freezing issue I reported eriler is not related to Dropbox as previously assumed. It is an actual issue. Happens randomly, sometimes it hits in a row every time when I test it, sometimes it never happens. I been able to reproduce it more less stable if I start a game, exit it, then start to roll resolutions. In Dark Forces 2 it happens after I start a game very often if game switches resolution often (and game does it a lot) and game frezze at first loading screen. Sometimes freezing bug show static background with a live mouse (which reflects underlying windows and change mouse pointer to different action pending like resize, text, etc...). Sometimes it is completely black window with same mouse cursor functionality. Logs are perfectly normal, no crashes or anything. I'll attach them anyway.
Created attachment 144240 [details] dmesg freeze
Created attachment 144241 [details] xorg.log freeze
Created attachment 144344 [details] [review] force scaler usage for any non-natively-sized mode The attached patch should make the scaler get auto-enabled for the various "other" modes. This will not resolve the letterboxing issue - patch for that to follow later.
Created attachment 144346 [details] [review] fix center and aspect scaling This patch should fix the aspect scaling mode (and also makes adjustments to the center one - it wasn't obviously correct before).
Alexei - if you get a chance, try applying the two patches I provide. They should make things work for you out of the box.
Thanks! In Ubuntu kernel has no drivers/gpu/drm/nouveau/dispnv50/disp.c and drivers/gpu/drm/nouveau/dispnv50/head.c but instead those files merged into one drivers/gpu/drm/nouveau/nv50_display.c for some heck reason. Patching this file makes one problem disappear, only "fix center and aspect scaling" work properly (which confirms I build a kernel properly) but scaling modes without calling 'xrandr --output eDP-1 --set "scaling mode" "Full aspect"' still produces broken 8 displays.
(In reply to Alexey Kuznetsov from comment #33) > Thanks! In Ubuntu kernel has no drivers/gpu/drm/nouveau/dispnv50/disp.c and > drivers/gpu/drm/nouveau/dispnv50/head.c but instead those files merged into > one drivers/gpu/drm/nouveau/nv50_display.c for some heck reason. The code was refactored. The ubuntu kernel is older. > > Patching this file makes one problem disappear, only "fix center and aspect > scaling" work properly (which confirms I build a kernel properly) but Yay! > scaling modes without calling 'xrandr --output eDP-1 --set "scaling mode" > "Full aspect"' still produces broken 8 displays. Hmmmm... adjusted_mode is the wrong thing to look at maybe? What if you switch adjusted_mode -> mode in that conditional? I always get so confused with that...
Yep, bingo. Now it is scaling display and has no broken displays after reboot no need to call additional xrandr commands. But, feels like default "scaling mode" should be "Full aspect" instead "Full". Anyway, thanks for support! Nvidia should be ashamed for lack of linux support.
(In reply to Alexey Kuznetsov from comment #35) > Yep, bingo. Now it is scaling display and has no broken displays after > reboot no need to call additional xrandr commands. But, feels like default > "scaling mode" should be "Full aspect" instead "Full". Anyway, thanks for > support! Nvidia should be ashamed for lack of linux support. Well, on a regular monitor, using a smaller modeline generally scales it to the full size of that screen. This emulates that behavior by default. If you want something else, you have to fiddle with settings. I'm going to confer with people who actually understand all this mode/adjusted_mode bs to try to fix my earlier blunder.
(In reply to Alexey Kuznetsov from comment #35) > Yep, bingo. Now it is scaling display and has no broken displays after > reboot no need to call additional xrandr commands. But, feels like default > "scaling mode" should be "Full aspect" instead "Full". Anyway, thanks for > support! Nvidia should be ashamed for lack of linux support. Are you able to post a log file of "drm.debug=0x14", with Ilia's initial patch using adjusted_mode instead of mode? Both should be identical at this point in time, and I'd like to understand why one works and the other doesn't, before upstreaming this patch.
Created attachment 144370 [details] drm.debug dmesg-mode.log
Created attachment 144371 [details] drm.debug dmesg-mode.log Reupload with log_buf_len=1M. During this session it hangs during mode switching, rare black/static screen. I switch to linux console (alt f1) took log and switch back. Unusual, but it is restored with: 720x400 640x400 Failed to change the screen configuration! 640x350 Failed to change the screen configuration! Failed to change the screen configuration!
Created attachment 144372 [details] drm.debug dmesg-mode.log clean reboot
Created attachment 144373 [details] drm.debug dmesg-adv.log
@Ilia Mirkin this "blank screen" still happens time to time. Some time it is not just black screen, but previous screen buffer from another app (can be Login screen, or game). And now I found how to reanimate X11 and allow to see desktop, just run "killall -3 gnome-shell" from Alt+F3 console. Seems like gnome shell some how interfering with mode switching and crashing. It may give you a better understanding what is going on, since you know what is under hood. Just a little reminder, "blank screen" appears after I start and exit game, I have mouse cursor which react for underlying windows (change cursor to edit text or resize window) but I can't click anything, and most of the time I see just blank screen. Using ubuntu 19.10 when "black screen" occures I can switch to login screen, type my password (X11 works on login screen!) and get back to current running account under "black screen" strike, this time screen appears as login screen, mouse cursor still reacts to my original windows (so nothing killed, music playing, and windows alive) but I can't click anyting as usual.
Created attachment 146055 [details] [review] LVDS/eDP mode fix For some reason kernel 5.3.0 end up with your 'adjusted_mode' patch instead correct 'mode' patch. As result recent Ubuntu 9.10 (which I'm testing right now) still have problem with 9 displays... That quite strange since I expect this issue was fixed. I've checked kernel sources (for Ubuntu 19.10 kernel 5.3.0-23-generic), patch f8d6211ac (drm/nouveau/disp/nv50-: force scaler for any non-default LVDS/eDP modes) indeed persisted but with your first attempt fixing the issue! I did manually rebuild kernel 'mode' and it works again! Not sure what I have to do here... * https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/eoan/ * https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/eoan/commit/?id=f8d6211ac77f0d1f7aebc64e961dc28771ba0052 Here MY patch ;)
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/485.
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.