Regarding #279 with NVIDIA version string

[TheRealOne78]

The new open driver has a new word inside of the version string, NVIDIA UNIX Open Kernel Module for x86_64 ver_num, which affects quite a lot of projects.
By adding Open in the version string, millions of programs will break because they won't be able to read the version number since some programs approach reading the driver version by getting the 7th word, some by reading the last word, some by reading the n character, etc.
As an example, I also created the #279 issue, reffering to Lutris not being able to recognise the driver version.

This is a real issue because there are millions of programs that rely on nvidia.
A solution would be for all the developers in the world to update their code, which is very unrealistic, espacelly when some programs were abandoned.

Moving the Open in the version string wouldn't be a full solution:
Moving the Open at to the of the string would make the programs that read the last word to break.
Adding -open to the version string would make programs that read the version number as a float to fail because it won't accept characters.
Appending a number representing the open to the version number would also break some programs that consider the number to have 3 dots, for example 0 representing the open kernel module driver: 515.43.04.0.
Concatinating Open Kernel with a - or _ (Open-Kernel/Open_Kernel) would break the programs that count the characters.

The best sollution I can think right now would be that instead of adding Open to the version driver, release the open kernel module as a release channel: Release Channel: Open-Kernel.
This would make programs not to break because of the version string, but would also give the ability to check the release channel.
For example nvidia-smi can give the version and the channel:

+-----------------------------------------------------------------------------+
| NVIDIA-SMI 515.48.07    Driver Version: 515.48.07    CUDA Version: 11.7     |
| Release Channel: Open-Kernel                                                |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|                               |                      |               MIG M. |
|===============================+======================+======================|
|   0  NVIDIA GeForce ...  Off  | 00000000:01:00.0  On |                  N/A |
| 37%   59C    P0    53W / 160W |    227MiB /  6144MiB |      4%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+

And the kernel module to output the version normally as NVIDIA UNIX Kernel Module for x86_64 ver_num just like the closed-source kernel and give the ability to see the type of driver by appending the --release-channel argument.

This is probably an exception rather than the rule, but I can't see how this problem can be solved other than this way.

Nvidia GPUs were released about 22 years ago and in 22 years a lot of programs were created and abandoned. Changing something that would need to make all of these programs to be reprogrammed is definetely not the best sollution.

[aritger]

Thanks for the concern. What are some example programs, beyond Lutris, that parse /proc/driver/nvidia/version? I'm surprised if parsing that file is that common. I wouldn't consider that file to be a stable interface, just like I wouldn't consider, e.g., gcc --version to be a stable interface.

(Ironically, in the NVIDIA installer we've had to parse gcc --version in the past, and it is similarly intractable.)

If there are really many programs that parse /proc/driver/nvidia/version, then something like you suggest may be warranted. But, so far, Lutris is the only example I've seen since we released the open kernel modules.

[TheRealOne78]

For now, the only example I can find right now would be wazzapp, an unnofficial electron whatsapp web client which for some reason needs to check the GPU version.
Running it would initiate a GTK window, then kill, dumping me with this error information:

❯ wazzapp
(node:2134) electron: The default of contextIsolation is deprecated and will be changing from false to true in a future release of Electron.  See https://github.com/electron/electron/issues/23506 for more information
[2134:0608/190341.839919:FATAL:gpu_data_manager_impl_private.cc(445)] GPU process isn't usable. Goodbye.
/bin/wazzapp: line 2:  2134 Trace/breakpoint trap   /opt/wazzapp/wazzapp

I don't really know if it's really complaining about GPU version or the nvidia driver is really missing a feature, but it really sounds like it.
A funny fact would be that wazzapp developers archived their repo last week, basically abandoning it.

The idea is that if it happened with Lutris, it doesn't mean it can't happen with other programs as well, espacelly thinking there are probably millions of programs depending on the nvidia driver.

I will try more research on programs that rely on /proc/driver/nvidia/version.

[aaronp24]

If applications just need the version, I would recommend reading /sys/module/nvidia/version rather than /proc/driver/nvidia/version.

[aritger]

Right, and normally most applications shouldn't need to get the NVIDIA driver version in the first place, so I would hope very few applications today inspect /proc/driver/nvidia/version in such a way that the format change would be problematic.

[TheRealOne78]

I have found another instance where neofetch uses /proc/driver/nvidia/version for getting the nvidia driver version. However I am going to make an issue neofetch repo.