Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nixos/xserver: use modern video drivers #100402

Closed
wants to merge 1 commit into from

Conversation

@TredwellGit
Copy link
Member

@TredwellGit TredwellGit commented Oct 13, 2020

Motivation for this change

cirrus is obsolete: https://www.vintage3d.org/cirrus.php
nv is obsolete: https://www.phoronix.com/scan.php?page=article&item=nvidia_kills_nv&num=1
vesa is obsolete: https://www.phoronix.com/scan.php?page=news_item&px=Nzc3Nw
ati and ati_unfree are superseded by amdgpu and amdgpu-pro: https://wiki.gentoo.org/wiki/ATI_FAQ#Is_my_AMD.2FATI_board_supported.3F
nouveau and fbdev added for better fallback support.

Things done
@TredwellGit
Copy link
Member Author

@TredwellGit TredwellGit commented Oct 13, 2020

Also can someone merge #98974?

@buckley310
Copy link
Contributor

@buckley310 buckley310 commented Oct 14, 2020

Working here.

I applied this change, removed xserver.videoDrivers from my config, and rebooted. Amdgpu driver was loaded.
I'm using an AMD 5700XT.

@Colecf
Copy link

@Colecf Colecf commented Oct 18, 2020

Please don't remove vesa from the defaults. I have an nvidia RTX 3080, and the nix-packaged version of the nvidia driver is currently version 440.100, which doesn't support my card. Vesa is the only video driver that works for me.

Of course, it doesn't support the full display resolution, but its much better to at least get into a functioning version of the desktop as opposed to being locked out and forced to roll back to an earlier nixos generation.

@TredwellGit
Copy link
Member Author

@TredwellGit TredwellGit commented Oct 18, 2020

I would prefer if someone just merged and backported #98191.

@@ -248,11 +248,10 @@ in

videoDrivers = mkOption {
type = types.listOf types.str;
# !!! We'd like "nv" here, but it segfaults the X server.
default = [ "radeon" "cirrus" "vesa" "modesetting" ];
Copy link
Member

@Atemu Atemu Nov 18, 2020

What's the reason for removing cirrus and vesa here?

Putting them as a lower priority than modesetting would be appropriate I think.

Copy link
Member Author

@TredwellGit TredwellGit Nov 19, 2020

Did you read the articles? Both cirrus and vesa are obsolete.

Copy link
Contributor

@thiagokokada thiagokokada Jan 4, 2021

Any reason we don't add nouveau here 🤔 ?

Copy link
Contributor

@thiagokokada thiagokokada Jan 4, 2021

BTW, having vesa as the last option seems interesting at least. In case everything else fails at least the user would have a "working" X11 (and in the linked article provided from Phoronix this is exactly the use case they cite as valid, as a fallback driver).

Copy link
Member Author

@TredwellGit TredwellGit Jan 4, 2021

Nouveau can't reclock modern GPUs and lacks Vulkan support. See pages 2 and 3 of this article. I don't see why anyone would purchase an NVIDIA GPU and want to use anything but the nvidia video drivers. If you cared about using libre software you would not have purchased NVIDIA in the first place.

Copy link
Contributor

@thiagokokada thiagokokada Jan 5, 2021

Do you still want me to add it?

I still see value (because in the worst case the user will have no video, but in the slightly better case the user will have video but no accel), but:

We now refuse to run on machines with UEFI firmware (on Linux only, patches welcome for other OSes) since it won't work in the general case and you probably have a kernel framebuffer driver running already.
All users are recommended to upgrade, ideally to a better video card and/or dri

So maybe we should add fbdev as fallback instead? I also found this article about Fedora changing the default: https://www.phoronix.com/scan.php?page=news_item&px=Fedora-VESA-FBDEV-Planning

But I don't know if they're setting fbdev or using something else.

Copy link
Member Author

@TredwellGit TredwellGit Jan 5, 2021

Can you test to make sure that fbdev does not supersede modesetting on Intel?

Copy link
Member Author

@TredwellGit TredwellGit Jan 5, 2021

Copy link
Contributor

@thiagokokada thiagokokada Jan 5, 2021

So I set:

{
 xserver.videoDrivers = [ "amdgpu" "nouveau" "modesetting" "fbdev" ];
}

Did a rebuild, sudo systemctl restart display-manager.service and it seems to work fine:

~
❯ cat /var/log/X.0.log | grep fbdev
[ 49210.177] (**) |-->Screen "Screen-fbdev[0]" (3)
[ 49210.177] (**) |   |-->Device "Device-fbdev[0]"
[ 49210.177] (==) No monitor specified for screen "Screen-fbdev[0]".
[ 49210.177] (**) ModulePath set to "/nix/store/d4ggz00ranwmx2isjjx5zmdv0gpnyl7s-xf86-input-libinput-0.28.2/lib/xorg/modules/input,/nix/store/qhgh8v03j4q2hj34ri42jdd1bl2cwll6-xf86-video-amdgpu-19.0.1/lib/xorg/modules/drivers,/nix/store/j1kpqqfqlhywhh0v41d7l6aq4a9cj5b3-xf86-video-nouveau-1.0.15/lib/xorg/modules/drivers,/nix/store/30a13n1yhqpx3fk18dxj7926rm9by65n-xf86-video-fbdev-0.5.0/lib/xorg/modules/drivers,/nix/store/9hzf53n2sd5y4d5ffbkwa8h4axg47b11-xorg-server-1.20.10/lib/xorg/modules,/nix/store/9hzf53n2sd5y4d5ffbkwa8h4axg47b11-xorg-server-1.20.10/lib/xorg/modules/drivers,/nix/store/9hzf53n2sd5y4d5ffbkwa8h4axg47b11-xorg-server-1.20.10/lib/xorg/modules/extensions,/nix/store/fhwz85bwfrv12xqkyjd8jbc3av1imccg-xf86-input-evdev-2.10.6/lib/xorg/modules/input"
[ 49210.185] (II) LoadModule: "fbdev"
[ 49210.185] (II) Loading /nix/store/30a13n1yhqpx3fk18dxj7926rm9by65n-xf86-video-fbdev-0.5.0/lib/xorg/modules/drivers/fbdev_drv.so
[ 49210.185] (II) Module fbdev: vendor="X.Org Foundation"
[ 49210.185] (II) FBDEV: driver for framebuffer: fbdev
[ 49210.197] (WW) Falling back to old probe method for fbdev
[ 49210.197] (II) Loading sub module "fbdevhw"
[ 49210.197] (II) LoadModule: "fbdevhw"
[ 49210.197] (II) Loading /nix/store/9hzf53n2sd5y4d5ffbkwa8h4axg47b11-xorg-server-1.20.10/lib/xorg/modules/libfbdevhw.so
[ 49210.197] (II) Module fbdevhw: vendor="X.Org Foundation"
[ 49210.310] (II) UnloadModule: "fbdev"
[ 49210.310] (II) Unloading fbdev
[ 49210.310] (II) UnloadSubModule: "fbdevhw"
[ 49210.310] (II) Unloading fbdevhw

~
❯ cat /var/log/X.0.log | grep modesetting
[ 49210.177] (**) |-->Screen "Screen-modesetting[0]" (2)
[ 49210.177] (**) |   |-->Device "Device-modesetting[0]"
[ 49210.177] (==) No monitor specified for screen "Screen-modesetting[0]".
[ 49210.185] (II) LoadModule: "modesetting"
[ 49210.185] (II) Loading /nix/store/9hzf53n2sd5y4d5ffbkwa8h4axg47b11-xorg-server-1.20.10/lib/xorg/modules/drivers/modesetting_drv.so
[ 49210.185] (II) Module modesetting: vendor="X.Org Foundation"
[ 49210.185] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
	"Screen-modesetting[0]" for depth/fbbpp 24/32

So yeah, it works. Just to make sure I also did:

{
 xserver.videoDrivers = [ "fbdev" "modesetting" ];
}

In this case, the fbdev was selected as the default driver. BTW, it was nice because I also guarantee that fbdev works as a good fallback: I had full resolution desktop (but my composition didn't work, but I think this was expected).

P.S.: I tested this in release-20.09, but this shouldn't make any difference since both release-20.09 and nixos-unstable are using X.org 1.20.2.

Copy link
Member Author

@TredwellGit TredwellGit Jan 5, 2021

This is good because using vesa prevents fixing #43984 according to https://wiki.ubuntu.com/X/Rootless. The order being respected is nice since it means old AMD GPUs can be supported by default as well.

nixos/modules/services/x11/xserver.nix Outdated Show resolved Hide resolved
@TredwellGit
Copy link
Member Author

@TredwellGit TredwellGit commented Dec 30, 2020

What needs to be done to get this merged?

@ajs124
Copy link
Member

@ajs124 ajs124 commented Dec 31, 2020

This should probably have a changelog entry, besides that, it seems like a sensible change to me.

@TredwellGit
Copy link
Member Author

@TredwellGit TredwellGit commented Dec 31, 2020

You mean release notes entry, right?

@ajs124
Copy link
Member

@ajs124 ajs124 commented Dec 31, 2020

Yes, sorry.

@TredwellGit
Copy link
Member Author

@TredwellGit TredwellGit commented Jan 4, 2021

I will write a release notes entry later today.

<para>
AMD provides a proprietary driver for its graphics cards that has better 3D
performance than the X.org drivers. It is not enabled by default because
it’s not free software. You can enable it as follows:
<programlisting>
<xref linkend="opt-services.xserver.videoDrivers"/> = [ "ati_unfree" ];
</programlisting>
You will need to reboot after enabling this driver to prevent a clash with
other kernel modules.
</para>
<note>
<para>
For recent AMD GPUs you most likely want to keep either the defaults
or <literal>"amdgpu"</literal> (both free).
Copy link
Contributor

@thiagokokada thiagokokada Jan 5, 2021

Won't we want to document amdgpu-pro here 🤔 ?

<listitem>
<para>
<xref linkend="opt-services.xserver.videoDrivers" /> no longer uses the <literal>cirrus</literal> and <literal>vesa</literal> device dependent X drivers by default.
</para>
</listitem>
Copy link
Contributor

@thiagokokada thiagokokada Jan 5, 2021

I would make this slightly more complete:

opt-services.xserver.videoDriver no longer sets deprecated cirrus and vesa drivers, but now enables both amdgpu and nouveau drivers by default.

This way, for people that used to put amdgpu or nouveau in their configuration, they can remove it if they want.

@thiagokokada
Copy link
Contributor

@thiagokokada thiagokokada commented Jan 12, 2021

@TredwellGit Are you still interested in merging this PR? Needs rebasing and fixing the merge conflict.

@TredwellGit
Copy link
Member Author

@TredwellGit TredwellGit commented Jan 12, 2021

Yes, just have been busy.

@xaverdh
Copy link
Contributor

@xaverdh xaverdh commented Feb 1, 2021

I rebased it: #111551

@TredwellGit
Copy link
Member Author

@TredwellGit TredwellGit commented Feb 1, 2021

It is not rebasing it that is the problem. It is being required to write documentation for a proprietary graphics driver that not even the maintainers of that driver want to write.

@xaverdh
Copy link
Contributor

@xaverdh xaverdh commented Feb 1, 2021

It is not rebasing it that is the problem. It is being required to write documentation for a proprietary graphics driver that not even the maintainers of that driver want to write.

I must have missed something, documentation on what needs to be written? Do you refer to amdgpu-pro, nvidia or something else?

@thiagokokada
Copy link
Contributor

@thiagokokada thiagokokada commented Feb 1, 2021

It is not rebasing it that is the problem. It is being required to write documentation for a proprietary graphics driver that not even the maintainers of that driver want to write.

https://github.com/NixOS/nixpkgs/pull/100402/files/541566b878d50f3669a03f1dcaefe494615e3a3c#diff-d8bd1210dab67b94b4639b9835d4077e1e28ef945212cfa0f20cd5993bfd03b1

Are you saying that about my comments? I am not requiring you do to anything, I don't even have approval/veto powers here (no commit access). That was just a suggestion.

BTW, it is not like I asked you to do document something very obscure either, I just asked for add something similar that already existed for ati_unfree for amdpro.

@TredwellGit
Copy link
Member Author

@TredwellGit TredwellGit commented Feb 1, 2021

I am going to close in favor of #111551. Someone who wants to document amdgpu-pro can do so in a different pull request.

@TredwellGit TredwellGit closed this Feb 1, 2021
@TredwellGit TredwellGit deleted the nixos/xserver branch Feb 17, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

8 participants