I have installed a clean install of Mint 19.2 on an ASUS TUF FX505DT laptop.
The amdgpu pro driver seems to work correctly. Prime is installed and makes the change when requested to.
The Nvidia card does not work when prime makes the transition.
The kernel is updated to 5.0x
nvidia-bug-report.log.gz (1.08 MB)
Please run nvidia-bug-report.sh as root and attach the resulting .gz file to your post. Hovering the mouse over an existing post of yours will reveal a paperclip icon.
[url]https://devtalk.nvidia.com/default/topic/1043347/announcements/attaching-files-to-forum-topics-posts/[/url]
Thank you. Attached nvidia-bug-report.log.gz file to original post.
Unfortunately, it seems that you have the same amd gpu model with 128MB VRAM like here:
[url]AMD Ryzen 7 + Geforce GTX 1660 Ti laptop ---> cannot get Nvidia to be used as primary graphics - Linux - NVIDIA Developer Forums
In contrast to the models with 2GB VRAM, this doesn’t properly work.
When you switch to nvidia, do you get a black screen on reboot, or what symptoms do you get? If you get a black screen, does suspending/resuming (close the lid) twice make it work?
Nvidia-smi reports 3911 MiB of VRAM. It’s listed as a 4G video card on the product specifications. So far the symptoms are just that I can’t get the Nvidia Card ON by using Prime, and that as a result the AMD Radeon Vega takes the helm. Prime-select query results in Nvidia, yet nvidia-smi says OFF all the time.
You misunderstood.
The nvidia gpu has 4GB vram.
The integrated AMD gpu has 128MB vram and that model had problems previously.
Since this is a hybrid graphics notebook, both gpus have to work together.
Looking at the logs again, you’re missing one config option for the nvidia gpu to take control. Please add
Option "PrimaryGpu" "true"
inside the OutputClass section of
/usr/share/X11/xorg.conf.d/10-nvidia.conf
reboot, report back.
RESULT:
Seems to be fully operational now save that I have to open terminal session and run startx manually.
Please create a new nvidia-bug-report.log.
What do you mean by “nvidia-smi indicates GPU is off”? If the gpu would be off, nvidia-smi would not work.
Latest nvidia-bug-report log
nvidia-bug-report.log.gz (1.08 MB)
There seem to be two Xorg sessions started on the nvidia gpu, the initial, defunct and the manually started one. Please post the output of
ps a |grep X
Output requested:
ps a | grep X
1035 tty7 Ssl+ 0:01 /usr/lib/xorg/Xorg -core :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
1339 tty4 S+ 0:00 xinit /etc/X11/xinit/xinitrc – /etc/X11/xinit/xserverrc :1 vt4 -keeptty -auth /tmp/serverauth.V1AQigUtlH
1340 tty4 Sl 0:42 /usr/lib/xorg/Xorg -nolisten tcp :1 vt4 -keeptty -auth /tmp/serverauth.V1AQigUtlH
4074 pts/0 S+ 0:00 grep --color=auto X
If you switch back to vt7 (maybe multiple times back and forth), does that invisible session come alive?
So, I’m having the same issue as aranthorne. I have an ASUS TUF FX505DU laptop (Ryzen 7 3750H + Geforce GTX 1660Ti), and after I managed to make the NVIDIA driver works, everytime I start up the machine I get a black screen. If I manually enter a terminal via CTRL+ALT+F1 and start a new session via startx, it works fine.
ps a | grep X | grep -v grep
1044 tty7 Ssl+ 0:01 /usr/lib/xorg/Xorg -core :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
1406 tty1 S+ 0:00 xinit /etc/X11/xinit/xinitrc – /etc/X11/xinit/xserverrc :1 vt1 -keeptty -auth /tmp/serverauth.XlZMjpCkfS
1407 tty1 Sl 0:13 /usr/lib/xorg/Xorg -nolisten tcp :1 vt1 -keeptty -auth /tmp/serverauth.XlZMjpCkfS
Like generix said, there’s two X sessions, the manually started one and the dead one. Switching back and forth to VT7 didn’t solved the issue nor brought the session back alive. Any solutions for this?
Xorg.0.log (35 KB)
nvidia-bug-report.log.gz (1.08 MB)
Generix:
No if I attempt to switch back and forth the invisible session does not come to life. BUT the manually started Xsession works well enough for my purposes until a better solution is available.
Please also attach to the mentioned freedesktop.org bug report with the found info that the second X session works.
Hello
I have the axact same problem but then on an asus vivobook 570zd
a laptop with a mobile ryzen 2500u and an nvidia gtx1050 2GB
if i put the Option “PrimaryGpu” “true”
into my 10-nvidia.conf
i get the black screen
if a manually start a new session it starts fine with nvidia as an renderer.
it works but i do need to start a manual session everytime i restart my machine
attached the latest nvidia bug report
nvidia-bug-report.log.gz (260 KB)
Another user has found a workaround by connecting an external monitor, which will work. Log in there, start control center and you will find your internal display disabled. Enable it and it should then be working fine when the external monitor is disconnected.
Hello
I have seen that post but it doesnt work for me i need to manually start an x session everytime to get a picture on screen.
Ok, looking at the logs I can see that the external output is connected to the amd gpu, not the nvidia one so the workaround doesn’t work for you.
Please try this:
run
ps aux |grep X
should return something like
gdm 557 0.0 0.8 394368 71452 tty7 Sl+ 11:04 0:00 /usr/libexec/Xorg vt7 -displayfd 3 -auth /run/user/111/gdm/Xauthority -background none -noreset -keeptty -verbose 3
note down the path that comes after -auth, in my case
/run/user/111/gdm/Xauthority
get a root shell:
sudo -s
then run
DISPLAY=:0 XAUTHORITY=/run/user/111/gdm/Xauthority xrandr --output eDP-1-0 --off
DISPLAY=:0 XAUTHORITY=/run/user/111/gdm/Xauthority xrandr --output eDP-1-0 --auto
Edit: then switch to vt7 and check if the monitor came alive.
Another option would be to use render offload.
Hello
Both commands give me outputted this
oot@Client1-Linux:~# DISPLAY=:0 XAUTHORITY=/run/user/111/gdm/Xauthority xrandr --output eDP-1-0 --off
No protocol specified
Can’t open display :0
root@Client1-Linux:~# DISPLAY=:0 XAUTHORITY=/run/user/111/gdm/Xauthority xrandr --output eDP-1-0 --auto
No protocol specified
Can’t open display :0
display still isnt working