Enable modeset with NVIDIA driver?

[root]

The nouveau and radeon drivers enable modeset to generate a tiny
console font. Google search reveals how to disable modeset, but
I can't seem to find how to enable modeset resolution when using
a NVIDIA card and disabling nouveau.

I found this description from ArchWiki:
https://wiki.archlinux.org/index.php/NVIDIA#DRM_kernel_mode_setting

which includes:
If you are using a custom kernel, compilation of the Nvidia kernel modules can
be automated with DKMS.

Install the nvidia-dkms package (or a specific branch such as
nvidia-340xx-dkms). The Nvidia module will be rebuilt after every Nvidia or
kernel update thanks to the DKMS Pacman Hook.

Pure Video HD

At least a video card with second generation PureVideo HD is required for
hardware video acceleration using VDPAU.

DRM kernel mode setting

Warning: Enabling KMS causes GDM and GNOME to default to Wayland, which
currently suffers from very poor performance: FS#53284. Note: The NVIDIA driver
does not provide an fbdev driver for the high-resolution console for the kernel
compiled-in vesafb module. However, the kernel compiled-in efifb module supports
high-resolution nvidia console on EFI systems.[1] Another option to get
high-resolution consoles is to use GRUB, see NVIDIA/Tips and tricks#Fixing
terminal resolution and [2].

nvidia 364.16 adds support for DRM kernel mode setting. To enable this feature,
add the nvidia-drm.modeset=1 kernel parameter, and add nvidia, nvidia_modeset,
nvidia_uvm and nvidia_drm to your initramfs#MODULES.

Warning: Do not forget to run mkinitcpio every time you update driver. See
#Pacman hook for how to automate this.

I would appreciate any advice about how I can enable modeset font
while retaining the NVIDIA driver.


I see that sbopkg has dkms, but it isn't clear to me that is the solution
to my problem.

The machine uses a GTX-660 graphics card, and NVIDIA-Linux-x86_64-375.39.run
driver. It is currently using lilo to boot, but I can switch it to grub.


Thanks.

[Pascal Hambourg]

Le 20/08/2017 à 18:20, root a écrit :
>
> nvidia 364.16 adds support for DRM kernel mode setting. To enable this feature,
> add the nvidia-drm.modeset=1 kernel parameter, and add nvidia, nvidia_modeset,
> nvidia_uvm and nvidia_drm to your initramfs#MODULES.
>
> Warning: Do not forget to run mkinitcpio every time you update driver. See
> #Pacman hook for how to automate this.
>
> I would appreciate any advice about how I can enable modeset font
> while retaining the NVIDIA driver.

Note : the font has nothing to do with modesetting. Modesetting just
changes the framebuffer display resolution. The font is smaller because
the pixels are smaller.

According to the above, you need to pass a parameter value to the
nvdia-drm (or nvidia_drm) module. Is this module present ?

modinfo nvdia-drm

> I see that sbopkg has dkms, but it isn't clear to me that is the solution
> to my problem.

DKMS has nothing to do with KMS/modesetting. It is just a method to
automatically build external kernel modules.

> The machine uses a GTX-660 graphics card, and NVIDIA-Linux-x86_64-375.39.run
> driver. It is currently using lilo to boot, but I can switch it to grub.

You do not need GRUB. LILO can pass parameters to the kernel command
line too. See lilo.conf.

[root]

Pascal Hambourg <pas...@plouf.fr.eu.org> wrote:
> Le 20/08/2017 ?? 18:20, root a ??crit :

>>
>> nvidia 364.16 adds support for DRM kernel mode setting. To enable this feature,
>> add the nvidia-drm.modeset=1 kernel parameter, and add nvidia, nvidia_modeset,
>> nvidia_uvm and nvidia_drm to your initramfs#MODULES.
>>
>> Warning: Do not forget to run mkinitcpio every time you update driver. See
>> #Pacman hook for how to automate this.
>>
>> I would appreciate any advice about how I can enable modeset font
>> while retaining the NVIDIA driver.
>
> Note : the font has nothing to do with modesetting. Modesetting just
> changes the framebuffer display resolution. The font is smaller because
> the pixels are smaller.
>
> According to the above, you need to pass a parameter value to the
> nvdia-drm (or nvidia_drm) module. Is this module present ?
>
> modinfo nvdia-drm

The following nvidia modules are loaded:
nvidia_uvm 599998 0
nvidia_drm 39655 0
nvidia_modeset 773859 1 nvidia_drm
nvidia 12059531 2 nvidia_modeset,nvidia_uvm
drm_kms_helper 111734 1 nvidia_drm
drm 277190 3 nvidia_drm,drm_kms_helper
i2c_core 39534 6 nvidia,i2c_i801,i2c_smbus,i2c_dev,drm_kms_helper,drm

>
>> I see that sbopkg has dkms, but it isn't clear to me that is the solution
>> to my problem.
>
> DKMS has nothing to do with KMS/modesetting. It is just a method to
> automatically build external kernel modules.
>
>> The machine uses a GTX-660 graphics card, and NVIDIA-Linux-x86_64-375.39.run
>> driver. It is currently using lilo to boot, but I can switch it to grub.
>
> You do not need GRUB. LILO can pass parameters to the kernel command
> line too. See lilo.conf.

I created a file nvidia.conf under /etc/modprobe.d. The single line
in that file is:
options nvidia-drm modeset=1

Using the lilo append, I tried various lines to pass something
to the kernel. For instance I tried:
nvidia-drm.modeset=1

I have disabled any vga=xxx line in lilo.conf.

I haven't done anything with mkinitcpio.

So far nothing has enabled kernel mode setting.
Thanks for responding.

[Pascal Hambourg]

Le 20/08/2017 à 21:44, root a écrit :

> Pascal Hambourg <pas...@plouf.fr.eu.org> wrote:
>>
>> According to the above, you need to pass a parameter value to the
>> nvdia-drm (or nvidia_drm) module. Is this module present ?
>>
>> modinfo nvdia-drm
>
> The following nvidia modules are loaded:
> nvidia_uvm 599998 0
> nvidia_drm 39655 0
> nvidia_modeset 773859 1 nvidia_drm
> nvidia 12059531 2 nvidia_modeset,nvidia_uvm
>

> I created a file nvidia.conf under /etc/modprobe.d. The single line
> in that file is:
> options nvidia-drm modeset=1

That should do it, unless the module is loaded by the initramfs.
Can you check if the initramfs (initrd) contains the nvidia modules ?

> Using the lilo append, I tried various lines to pass something
> to the kernel. For instance I tried:
> nvidia-drm.modeset=1

That should do it too, regardless of whether the module is loaded by the
initramfs or not.

You can check the actual kernel command line in /proc/cmdline.
You can see the parameter list of nvidia_drm with

modinfo nvidia_drm

If Nvidia is kind enough to comply with the modern way to handle kernel
module parameters in sysfs, you can check the parameter values in
/sys/module/nvidia_drm(or nvidia-drm)/parameters/* pseudo-files.

[root]

Pascal Hambourg <pas...@plouf.fr.eu.org> wrote:
> Le 20/08/2017 ?? 21:44, root a ??crit :

>> Pascal Hambourg <pas...@plouf.fr.eu.org> wrote:
>>>
>>> According to the above, you need to pass a parameter value to the
>>> nvdia-drm (or nvidia_drm) module. Is this module present ?
>>>
>>> modinfo nvdia-drm
>>
>> The following nvidia modules are loaded:
>> nvidia_uvm 599998 0
>> nvidia_drm 39655 0
>> nvidia_modeset 773859 1 nvidia_drm
>> nvidia 12059531 2 nvidia_modeset,nvidia_uvm
>>
>> I created a file nvidia.conf under /etc/modprobe.d. The single line
>> in that file is:
>> options nvidia-drm modeset=1
>
> That should do it, unless the module is loaded by the initramfs.
> Can you check if the initramfs (initrd) contains the nvidia modules ?

mkinitrd does not load any nvidia modules.

>
>> Using the lilo append, I tried various lines to pass something
>> to the kernel. For instance I tried:
>> nvidia-drm.modeset=1
>
> That should do it too, regardless of whether the module is loaded by the
> initramfs or not.
>
> You can check the actual kernel command line in /proc/cmdline.
> You can see the parameter list of nvidia_drm with
>
> modinfo nvidia_drm

under the parm: line I find:
modeset:Enable atomic kernel modesetting (1=enable, 0=disable (default)) (bool)

>
> If Nvidia is kind enough to comply with the modern way to handle kernel
> module parameters in sysfs, you can check the parameter values in
> /sys/module/nvidia_drm(or nvidia-drm)/parameters/* pseudo-files.

/sys/module/nvidia_drm/parameters/modeset contains Y
so it seems that modeset should work, but it doesn't.

Just to make sure it isn't a hardware problem, I un-blacklisted
nouveau and rebooted: I got the tiny print and 1920x1080 resolution.

I had manually loaded mvidia_uvm and mvidia_drm in /etc/rc.d/rc.modules.local
because the nvidia_uvm module was not normally loaded for the GTX 660 card.
I went back and took out these lines from the rc.modules.local
file and rebooted. No change, and the modeset=Y is maintained.

Earlier this morning I requested help from Nvidia and they got back
to me within a couple of hours. Unfortunately for me I mentioned
in my request that my overall goal was to work with CUDA programming.
They completely ignored my modeset question and sent me information
about CUDA manuals.

Just now Nvidia referred me to the developer forum to answer the
modeset question.

Thanks for responding.

[root]

root <NoE...@home.org> wrote:
>> If Nvidia is kind enough to comply with the modern way to handle kernel
>> module parameters in sysfs, you can check the parameter values in
>> /sys/module/nvidia_drm(or nvidia-drm)/parameters/* pseudo-files.
>
> /sys/module/nvidia_drm/parameters/modeset contains Y
> so it seems that modeset should work, but it doesn't.
>

It seems that modeset is working. If I turn off my monitor
and turn it back on it says mode is 1920x1080 60Hz.
I can't seem to find a tiny enough font using setfont.

[Bit Twister]

On Sun, 20 Aug 2017 22:16:39 +0000 (UTC), root wrote:

> I can't seem to find a tiny enough font using setfont.

maybe dependent on the smallest font installed.
I would think 5x7 would be small enough. Example:
xterm -font 5x7
maybe something in a size 8
xterm -font lucidasanstypewriter-8

If installed you can list installed fonts,
xlsfonts

[root]

I am trying to do all this under a console. I want to
end up with a display matching that from nouveau.

All this might be a wasted effort. I have been aiming
toward programming a neural net with cuda cores. Now
I find tht Nvidia cuda is only 32 bits. Everything else
I have been doing has been moved up to 64 bits.

[Henrik Carlqvist]

On Mon, 21 Aug 2017 01:10:06 +0000, root wrote:
> Now I find tht Nvidia cuda is only 32 bits. Everything else I have been
> doing has been moved up to 64 bits.

As far as I know cuda is only available for 64 bit Linux at
https://developer.nvidia.com/cuda-downloads
If you somehow have been able to find and download 32 bit cuda that
should be fixed by downloading the right cuda from the link above.

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc351(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost

[vaso]

Sorry for Spam but Linus already said this :https://youtu.be/iYWzMvlj2RQ
That's why I don't use any nvidia chips.

[Rinaldi]

vaso decreed, Read These Runes!:

> Sorry for Spam but Linus already said this :https://youtu.be/iYWzMvlj2RQ
> That's why I don't use any nvidia chips.

Nothing has changed in the 5 years since then?

--
I'm defending her honor, which is more than she ever did.

[root]

vaso <vas...@gmail.com> wrote:
> Sorry for Spam but Linus already said this :https://youtu.be/iYWzMvlj2RQ
> That's why I don't use any nvidia chips.

If you want GPU programming you have a choice of AMD/ATI or Nvidia.
However bad Linus thinks Nvidia is, AMD/ATI are worse. I bought
a pair of ATI 5937 2GB video cards to experiment with their version
of GPU programming. You have to get fglrx (or something like that)
working before you can use the cards. I spent a couple of weeks trying
to get their unsupported drivers to work. No support, no updated
software, no working patches, nothing.

[The Real Bev]

On 08/21/2017 07:52 AM, Rinaldi wrote:
> vaso decreed, Read These Runes!:
>> Sorry for Spam but Linus already said this :https://youtu.be/iYWzMvlj2RQ
>> That's why I don't use any nvidia chips.
>
> Nothing has changed in the 5 years since then?

Are you THE Rinaldi?

--
Cheers, Bev
If voting could really change things, it would be illegal.
--Revolution Books, New York, New York

[Rinaldi]

The Real Bev decreed, Read These Runes!:

> On 08/21/2017 07:52 AM, Rinaldi wrote:
>> vaso decreed, Read These Runes!:
>>> Sorry for Spam but Linus already said this :https://youtu.be/iYWzMvlj2RQ
>>> That's why I don't use any nvidia chips.
>>
>> Nothing has changed in the 5 years since then?
>
> Are you THE Rinaldi?

There can be many but there is only one ;-)

Rinaldi
--
It is much easier to suggest solutions when you know nothing about the
problem.

[root]

Henrik Carlqvist <Henrik.C...@deadspam.com> wrote:
> On Mon, 21 Aug 2017 01:10:06 +0000, root wrote:
>> Now I find tht Nvidia cuda is only 32 bits. Everything else I have been
>> doing has been moved up to 64 bits.
>
> As far as I know cuda is only available for 64 bit Linux at
> https://developer.nvidia.com/cuda-downloads
> If you somehow have been able to find and download 32 bit cuda that
> should be fixed by downloading the right cuda from the link above.
>
> regards Henrik

Thanks a whole lot Henrik. Thanks to you I have CUDA 64 bit up
and running. For the benefit of Slackware people interested
here are the steps I did:

1. You cannot run under nouveau and, according to the Nvidia
developers group, you cannot simply enable modeset to
get tiny print. Live with the best fonts you can get
running under the console.
2. I chose to download the OpenSuse rpm package. First
I ran rpm2tgz to generate a Slackware package. Much
to my dismay, the resulting package was a package of
rpm files.
3. I put this "dorpm" script in my path:
file=$1
newf=${file/".rpm"/}
echo $newf
rpm2tgz $file
installpkg $newf.tgz
mv $newf.tgz /cudapacks
rm $file
4. I created a directory /cudapacks
5. Then I cd to / and ran this:
find . -name "*.rpm" -exec dorpm {} \;
6. After completion I had all the tgz packages in the
the /cudapacks directory, all the rpm files were
gone and the cuda software was installed.

7. I cd to /usr/local/cuda-8.0/samples/0_Simple/vectorAdd/
and compiled and executed vectorAdd, a program similar
to that shown by one of the example videos at the
developer site pointed to by Henrik.

In fact I did the steps above running under nouveau
and the vectorAdd program hung without any warning.
I put some debugging into the program and found it
was hanging at the point were the "malloc" program
was requesting memory from the device. In hopes
that it was the lack of Nvidia modules, I blacklisted
nouveau and rebooted. Thereafter the vectorAdd program
ran as it should.

There is an abundance of sample programs which can
readily be modified to fit particular needs.

Thanks again Henrik.

[Henrik Carlqvist]

On Mon, 21 Aug 2017 09:52:14 -0500, Rinaldi wrote:
> vaso decreed, Read These Runes!:
>> Sorry for Spam but Linus already said this
>> :https://youtu.be/iYWzMvlj2RQ That's why I don't use any nvidia chips.
>
> Nothing has changed in the 5 years since then?

I would say things has gotten even a little bit worse since the last few
years...

During all the years, installing the nVidia drivers has meant that you
will lock your system to only work with nVidia cards. This is because the
installation of the binary nVidia driver does not only add one more
graphics driver to your system which X is able to choose from among other
drivers when starting. Installing the nVidia binary driver also replaces
your OpenGL libraries with binary nVidia libraries which only work with
nVidia cards.

So what could become worse?

A few years ago they changed the version numbering of some OpenGL library
so that ldconfig instead links to the opensource library which gets
incompatible with the nVidia drivers installed. (Sorry, I don't remember
exactly which .so file, I avoid nVidia cards at home but have to live
with them at work). The workaround for this is to remove or rename the
original opensource library.

One or maybe two years ago, I think this was when nVidia came out with
the GTX 10xx series, those new cards required a newer version of the
driver. You also need this newest version of the driver if you want to
run the latest version of cuda. Unfortunately, this newest version does
no longer support older nVidia cards. Older cards need an older driver
and that old driver will not work with newer nVidia cards.

So even if someone decides to only shop nVidia cards for an organisation
during the years, you will not be able to create one standardized Linux
installation that will work on all machines. Every machine has to be
manually adopted depending on what graphics card it has. You will end up
with 3 versions of your installation.

* One installation works with all machines with other graphics cards than
nVidia. That installation also works with low performance and without
cuda functionality together with nVidia cards thanks to the nouveau
driver.

* Another installation works with good performance and full cuda
functionality but only om machines with the latest nVidia cards.

* The third installation gives good performance and obsolete cuda
functionality but only works on machines with older nVidia cards.

[Eef Hartman]

Henrik Carlqvist <Henrik.C...@deadspam.com> wrote:
> Installing the nVidia binary driver also replaces your OpenGL libraries
> with binary nVidia libraries which only work with nVidia cards.

They're actually just interfaces to the built-in GL that nVidia cards
have got. And it is only in Slackware that they REPLACE the other library,
because a link in Slackware puts them in the same directory
(/usr/X11R6/lib is a symbolic link to /usr/lib).
Even in Slackware you can prevent that by renaming the glx library before
installing the nVidia one:
lrwxrwxrwx 1 root root 17 2017-08-17 00:01 libglx.so ->
libglx.so.304.125
-rwxr-xr-x 1 root root 459140 2017-08-15 23:57 libglx.so.1.14.3
-rwxr-xr-x 1 root root 7158160 2015-10-05 13:21 libglx.so.304.125
(in which the 304.125 is the nVidia one and the 1.14.3 the recently
updated standard glx (GL from X) library).

As I've got an older nVidia card (Quadro FC1500) the 304 series of
drivers/libs is the latest one I can use.

[root]

Henrik Carlqvist <Henrik.C...@deadspam.com> wrote:
>
> During all the years, installing the nVidia drivers has meant that you
> will lock your system to only work with nVidia cards. This is because the
> installation of the binary nVidia driver does not only add one more
> graphics driver to your system which X is able to choose from among other
> drivers when starting. Installing the nVidia binary driver also replaces
> your OpenGL libraries with binary nVidia libraries which only work with
> nVidia cards.

I am (was) willing to dedicate a system to Nvidia in order to develop
cuda applications. Things didn't work out for me and I ran into the
OpenGL problem when I tried to back out of Nvidia. The immediate problem
with Nvidia for me was that I could not get a frame buffer with hdmi
resolution for console operations. I was using GTX 660 video card
(not supported by nouveau for X).

> A few years ago they changed the version numbering of some OpenGL library
> so that ldconfig instead links to the opensource library which gets
> incompatible with the nVidia drivers installed. (Sorry, I don't remember
> exactly which .so file,

It might be libGLdispatch.so.0

>
> One or maybe two years ago, I think this was when nVidia came out with
> the GTX 10xx series, those new cards required a newer version of the
> driver. You also need this newest version of the driver if you want to
> run the latest version of cuda. Unfortunately, this newest version does
> no longer support older nVidia cards. Older cards need an older driver
> and that old driver will not work with newer nVidia cards.

I don't think nouveau supports these Nvidia cards for X. When startx
failed using the GTX 660, the logfile went through a list of drivers
it tried and no GTX card equal to or higher than 660 came up.