Bug 110660 - GeForce GT 750M Mac Edition fullscreen issues
Summary: GeForce GT 750M Mac Edition fullscreen issues
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-05-10 12:01 UTC by Alexey Kuznetsov
Modified: 2019-12-04 09:49 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
xorg.log (21.14 KB, text/x-log)
2019-05-10 12:01 UTC, Alexey Kuznetsov
no flags Details
dmesg.log (135.07 KB, text/plain)
2019-05-10 12:01 UTC, Alexey Kuznetsov
no flags Details
guild wars 9 displays (2.92 MB, image/jpeg)
2019-05-10 12:07 UTC, Alexey Kuznetsov
no flags Details
guildwars window mode (slow) (1.92 MB, image/jpeg)
2019-05-10 12:08 UTC, Alexey Kuznetsov
no flags Details
lightdm xorg logs (33.12 KB, text/plain)
2019-05-10 15:15 UTC, Alexey Kuznetsov
no flags Details
dmesg freeze (89.73 KB, text/x-log)
2019-05-12 14:42 UTC, Alexey Kuznetsov
no flags Details
xorg.log freeze (57.31 KB, text/x-log)
2019-05-12 14:43 UTC, Alexey Kuznetsov
no flags Details
force scaler usage for any non-natively-sized mode (1.64 KB, patch)
2019-05-25 18:54 UTC, Ilia Mirkin
no flags Details | Splinter Review
fix center and aspect scaling (2.56 KB, patch)
2019-05-25 22:37 UTC, Ilia Mirkin
no flags Details | Splinter Review
drm.debug dmesg-mode.log (204.23 KB, text/x-log)
2019-05-29 07:18 UTC, Alexey Kuznetsov
no flags Details
drm.debug dmesg-mode.log (822.90 KB, text/x-log)
2019-05-29 07:58 UTC, Alexey Kuznetsov
no flags Details
drm.debug dmesg-mode.log (795.79 KB, text/x-log)
2019-05-29 08:03 UTC, Alexey Kuznetsov
no flags Details
drm.debug dmesg-adv.log (913.76 KB, text/x-log)
2019-05-29 11:34 UTC, Alexey Kuznetsov
no flags Details
LVDS/eDP mode fix (767 bytes, patch)
2019-12-01 10:06 UTC, Alexey Kuznetsov
no flags Details | Splinter Review

Description Alexey Kuznetsov 2019-05-10 12:01:06 UTC
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.
Comment 1 Alexey Kuznetsov 2019-05-10 12:01:26 UTC
Created attachment 144216 [details]
dmesg.log
Comment 2 Alexey Kuznetsov 2019-05-10 12:07:42 UTC
Created attachment 144217 [details]
guild wars 9 displays
Comment 3 Alexey Kuznetsov 2019-05-10 12:08:07 UTC
Created attachment 144218 [details]
guildwars window mode (slow)
Comment 4 Alexey Kuznetsov 2019-05-10 12:09:41 UTC
openarea youtube video https://youtu.be/EtvDPZ1T4E4
Comment 5 Ilia Mirkin 2019-05-10 14:26:28 UTC
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...
Comment 6 Alexey Kuznetsov 2019-05-10 14:50:58 UTC
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:~$
Comment 7 Ilia Mirkin 2019-05-10 14:58:50 UTC
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).
Comment 8 Alexey Kuznetsov 2019-05-10 15:15:57 UTC
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!
Comment 9 Ilia Mirkin 2019-05-10 16:06:59 UTC
(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?
Comment 10 Alexey Kuznetsov 2019-05-10 16:21:58 UTC
Yep, xrandr -s 1920x1200 messing screen up.
Comment 11 Alexey Kuznetsov 2019-05-10 16:25:05 UTC
some modes create GW like screen, some open arena screen. Non are working but 2880x1800
Comment 12 Ilia Mirkin 2019-05-10 16:25:22 UTC
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.
Comment 13 Alexey Kuznetsov 2019-05-10 16:37:18 UTC
Confirming: none modes are working. Modes below 640x480 - breaking X-server (only mouse cursor visible)
Comment 14 Alexey Kuznetsov 2019-05-10 16:47:28 UTC
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.
Comment 15 Ilia Mirkin 2019-05-10 16:52:07 UTC
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.
Comment 16 Alexey Kuznetsov 2019-05-10 16:54:51 UTC
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.
Comment 17 Ilia Mirkin 2019-05-10 17:16:30 UTC
(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?
Comment 18 Alexey Kuznetsov 2019-05-10 17:36:23 UTC
I did several tests and now it working, probably it is dropbox hangs the system for few minutes during scanning.
Comment 19 Ilia Mirkin 2019-05-10 17:49:11 UTC
(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?
Comment 20 Alexey Kuznetsov 2019-05-10 18:19:52 UTC
I have to use xrendr command to make resolution switching work. Default mode produces broken white lines.
Comment 21 Ilia Mirkin 2019-05-10 18:23:31 UTC
(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?
Comment 22 Alexey Kuznetsov 2019-05-10 18:55:22 UTC
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.
Comment 23 Ilia Mirkin 2019-05-11 00:59:02 UTC
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)
Comment 24 Ilia Mirkin 2019-05-11 01:33:42 UTC
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.)
Comment 25 Alexey Kuznetsov 2019-05-11 07:15:20 UTC
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
Comment 26 Ilia Mirkin 2019-05-11 16:20:31 UTC
(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.
Comment 27 Alexey Kuznetsov 2019-05-12 14:42:34 UTC
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.
Comment 28 Alexey Kuznetsov 2019-05-12 14:42:53 UTC
Created attachment 144240 [details]
dmesg freeze
Comment 29 Alexey Kuznetsov 2019-05-12 14:43:06 UTC
Created attachment 144241 [details]
xorg.log freeze
Comment 30 Ilia Mirkin 2019-05-25 18:54:29 UTC
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.
Comment 31 Ilia Mirkin 2019-05-25 22:37:04 UTC
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).
Comment 32 Ilia Mirkin 2019-05-26 19:11:52 UTC
Alexei - if you get a chance, try applying the two patches I provide. They should make things work for you out of the box.
Comment 33 Alexey Kuznetsov 2019-05-28 16:58:14 UTC
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.
Comment 34 Ilia Mirkin 2019-05-28 17:19:25 UTC
(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...
Comment 35 Alexey Kuznetsov 2019-05-28 20:28:32 UTC
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.
Comment 36 Ilia Mirkin 2019-05-28 20:31:30 UTC
(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.
Comment 37 Ben Skeggs 2019-05-29 01:33:37 UTC
(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.
Comment 38 Alexey Kuznetsov 2019-05-29 07:18:41 UTC
Created attachment 144370 [details]
drm.debug dmesg-mode.log
Comment 39 Alexey Kuznetsov 2019-05-29 07:58:41 UTC
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!
Comment 40 Alexey Kuznetsov 2019-05-29 08:03:55 UTC
Created attachment 144372 [details]
drm.debug dmesg-mode.log

clean reboot
Comment 41 Alexey Kuznetsov 2019-05-29 11:34:47 UTC
Created attachment 144373 [details]
drm.debug dmesg-adv.log
Comment 42 Alexey Kuznetsov 2019-08-26 16:25:48 UTC
@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.
Comment 43 Alexey Kuznetsov 2019-12-01 10:06:01 UTC
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 ;)
Comment 44 Martin Peres 2019-12-04 09:49:27 UTC
-- 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.