| Bug ID | 110660 |
|---|---|
| Summary | GeForce GT 750M Mac Edition fullscreen issues |
| Product | Mesa |
| Version | unspecified |
| Hardware | Other |
| OS | All |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | Drivers/DRI/nouveau |
| Assignee | nouveau@lists.freedesktop.org |
| Reporter | ak@axet.ru |
| QA Contact | nouveau@lists.freedesktop.org |
Created attachment 144215 [detai=
ls]
xorg.log
Driver feels stable working with default X11 apps, sleep, hibernate - ok. B=
ut
when I start games, in fullscreen mode is has few issues.
Openarena sometimes starts with white lines, same happens with some wine ga=
mes
(Jedi Knight 2). Some wine games in fullscreen show 4 displays on one scree=
n.
Screenshots and video attached.
Created attachment 144217<=
/a> [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 accele= ration with fbdev. My guess is that your issues are with llvmpipe or whatever the softw= are 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/questi= ons/1038899/xorg-fails-to-start-after-upgrade-to-18-04-dev-dri-card0-no-suc= h-file My drm file exists and readable: axet@axet-laptop:~$ ls -al /dev/dri/ total 0 drwxr-xr-x 3 root root 100 =D0=BC=D0=B0=D1=8F 10 17:41 . drwxr-xr-x 21 root root 4640 =D0=BC=D0=B0=D1=8F 10 17:42 .. drwxr-xr-x 2 root root 80 =D0=BC=D0=B0=D1=8F 10 17:41 by-path crw-rw----+ 1 root video 226, 0 =D0=BC=D0=B0=D1=8F 10 17:41 card0 crw-rw----+ 1 root video 226, 128 =D0=BC=D0=B0=D1=8F 10 17:41 renderD128 axet@axet-laptop:~$=20 no cat errors: axet@axet-laptop:~$ cat /dev/dri/card0=20 ^C axet@axet-laptop:~$=20 all with disabled selinux: axet@axet-laptop:~$ getenforce=20 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 se= em to be a nouveau issue (at least not yet).
| What | Removed | Added |
|---|---|---|
| Attachment #144215 is obsolete | 1 |
Created attachment 144220 = [details] lightdm xorg logs I switched from gdm to lightdm and "No such file or directory" go= ne. Thanks to http= s://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D748463 and 'sudo lsof /dev/dri/card0' But graphics issues are the same!
(In reply to Alexey Kuznetsov from comment #8) > Created attachme= nt 144220 [details] > lightdm xorg logs >=20 > I switched from gdm to lightdm and "No such file or directory&quo= t; gone. Thanks > to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D748463 and 'sud= o lsof > /dev/dri/card0' >=20 > But graphics issues are the same! OK well those logs look MUCH happier. Now ... that "panel gets messed up with vertical white lines" thi= ng 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 cha= nge 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 1= 280 1360 1488 1696 960 963 967 996 -hsync +vsync (59.8 kHz) [ 36.683] (II) NOUVEAU(0): Modeline "1152x864"x60.0 81.77 1= 152 1216 1336 1520 864 867 871 897 -hsync +vsync (53.8 kHz) [ 36.683] (II) NOUVEAU(0): Modeline "1024x768"x59.9 63.53 1= 024 1072 1176 1328 768 771 775 798 -hsync +vsync (47.8 kHz) [ 36.683] (II) NOUVEAU(0): Modeline "800x600"x60.0 38.31 80= 0 832 912 1024 600 603 607 624 -hsync +vsync (37.4 kHz) [ 36.683] (II) NOUVEAU(0): Modeline "640x480"x59.9 23.98 64= 0 664 720 800=20 480 483 487 500 -hsync +vsync (30.0 kHz) [ 36.683] (II) NOUVEAU(0): Modeline "720x400"x60.0 22.41 72= 0 744 808 896=20 400 403 413 417 -hsync +vsync (25.0 kHz) [ 36.683] (II) NOUVEAU(0): Modeline "640x400"x60.0 20.00 64= 0 664 720 800=20 400 403 409 417 -hsync +vsync (25.0 kHz) [ 36.683] (II) NOUVEAU(0): Modeline "640x350"x59.8 17.52 64= 0 664 720 800=20 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?
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 ca= n do like "xrandr -s xxxxx; sleep 5; xrandr -s 2880x1800" which will restore the old res= olution. 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 na= me of the property.
Confirming: none modes are working. Modes below 640x480 - brea= king X-server (only mouse cursor visible)
xrandr --output eDP-1 --set "scaling mode" "Ful= l" fix the issue. When I use "Full" scaling, resolution switch prope= rly, "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 =3D 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" 720x= 400 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", "Defa= ult" 720x400 enter wired mode: feels like > static screen below cursor and only mouse cursor moving, I can't chang= e 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? Presum= ably the "scaling mode" is still required for you? Or are you saying t= hat switching to 720x400 is still broken, even with the scaling mode =3D full, but switch= ing 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 mode= s 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=20
VertFreq: 59 Hz, HorFreq: 111101 Hz
Monitor name: Color LCD
Dummy block
Dummy block
Checksum: 0xde (valid)