Indirect GLX being required by Linux libraries

This is somewhat of a copy and paste in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228287 in the FreeBSD bug database.

There are two issues that I see with the Linux libraries as provided with the Nvidia driver:

  1. There are three empty libraries:
    1. libEGL.so.1
    2. libGLESv1_CM.so.1
    3. libGLESv2.so.2
  2. Indirect GLX needs to be enabled in the X server to run Linux 32-bit applications with hardware acceleration.

The first one may not be an issue, but it is odd. If it is expected, would you update the README to explain it? This would help reduce future questions. An error I see with this comes from running eglinfo32 from a Linux distribution:

./eglinfo32: error while loading shared libraries: /lib/libEGL.so.1: file too short

As for the second issue, the X server is being required to be run with indirect GLX which has security implications. Since native FreeBSD OpenGL applications run well without it, it leads me to suspect that the provided Linux libraries can be fixed to also run without indirect GLX.

The error seen when attempting to run Linux 32-bit binaries is:

libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  153 (GLX)
  Minor opcode of failed request:  3 (X_GLXCreateContext)
  Value in failed request:  0x0
  Serial number of failed request:  35
  Current serial number in output stream:  37

If you need any more details the bug listed above may answer your question. If not, please ping me.

Thank you.

Thanks to Tijl Coosemans, this was fixed in the FreeBSD src and ports trees. The changes in the ports tree may be of interest to the developers here. https://svnweb.freebsd.org/ports?view=revision&revision=487446

Sorry for the very slow reply to this thread. I just tracked down both of these problems:

  1. Empty libraries

    This is a bug in the packaging step that copies the Linux libraries into the compatibility directory in the FreeBSD package. I’m working on a fix for a future release.

  2. Indirect rendering

    This looks like a bug in FreeBSD. When Linux applications try to look at /dev, what they actually see are the contents of /compat/linux/dev. Since this starts out empty, the Linux driver does not see the device nodes it expects and tries to create them. If the application is not running as root, this just fails and the application falls back to indirect rendering immediately. If the application is root, then it uses mknod to create a device node with the Linux device major & minor numbers (195 and 255, for /dev/nvidiactl), opens that device, and then tries to make an ioctl() call on that. In the FreeBSD 11.2 kernel, this call fails immediately in vn_ioctl(), which returns ENOTTY for character device files. On FreeBSD 12.0, there’s support for character devices in vn_ioctl() but this just ends up in zfs_freebsd_ioctl(), which also returns ENOTTY.

    You can work around the problem by mounting the real FreeBSD devfs on top of /compat/linux/dev:

    # mount -t devfs none /compat/linux/dev
    

Hello everybody. I am pretty good with editing files and using linux or freebsd in general. But I am trying to fix the first bug in this post where there are empty libraries being copied. Problem is I am not as good at shell scripting as I need to be to edit the part in The make file, and other files that copy them. Can I manually copy them for right now or is there some other “fix” so I dont have to wait for a new driver? Im stuck in a hard place right now. My RTX 2060 isnt supported yet in the packages or ports driver (“nvidia-driver”) because it is too new, but installing manually via the one from the site works, i can get in X but all my programs using linux compatibility and requiring 32 bit libs do not because of the missing libs error. I even tried editing the makefile for the port and changing the version, but its not working either I get errors. Please give me any ideas. Thanks for any help!

This is now fixed as of may 14th 2019. Although I got no responses here, I just wanted to thank you for your work.

Thank you all involved in solving and fixing this! I confirm that I am able to run both 32-bit and 64-bit versions of eglinfo without errors.

I do notice a small difference between the two outputs but that may be due to what libraries are installed on FreeBSD for 32-bit and 64-bit. I do not know. Here is the difference in outputs:

--- eglinfo32.txt	2019-07-28 18:00:55.025118000 -0400
+++ eglinfo64.txt	2019-07-28 18:01:05.352274000 -0400
@@ -33,7 +33,8 @@
     EGL_NV_post_sub_buffer EGL_NV_stream_metadata EGL_NV_stream_reset
     EGL_NV_stream_sync EGL_NV_stream_consumer_gltexture_yuv
     EGL_NV_stream_attrib EGL_NV_sync EGL_NV_system_time
-    EGL_NV_output_drm_flip_event
+    EGL_NV_output_drm_flip_event EGL_WL_bind_wayland_display
+    EGL_WL_wayland_eglstream
 Configurations:
      bf lv colorbuffer dp st  ms    vis   cav bi  renderable  supported
   id sz  l  r  g  b  a th cl ns b    id   eat nd gl es es2 vg surfaces 
@@ -132,6 +133,7 @@
     EGL_NV_stream_metadata EGL_NV_stream_reset EGL_NV_stream_sync
     EGL_NV_stream_consumer_gltexture_yuv EGL_NV_stream_attrib EGL_NV_sync
     EGL_NV_system_time EGL_NV_output_drm_flip_event
+    EGL_WL_bind_wayland_display EGL_WL_wayland_eglstream
 Configurations:
      bf lv colorbuffer dp st  ms    vis   cav bi  renderable  supported
   id sz  l  r  g  b  a th cl ns b    id   eat nd gl es es2 vg surfaces