If you look at a Jetson you will find it has file “/etc/nv_tegra_release”. That file is a list of NVIDIA-provided files. One specific file of interest is libGLX.so, but browsing each file and looking for what each file provides (although time consuming) will tell you what files are related to hardware access.
JetPack is a front end to the driver package. If you were to flash on command line via the driver package, then the “apply_binaries.sh” step would unpack those libraries into the “rootfs/” subdirectory before building the final rootfs image. That script is human readable and so you can see what is unpacked where.
The X server is often mistaken for being a desktop application. It isn’t. X is a unified interface (via X protocol events) to a buffer which happens to be useful to a video display. In the early days nobody did GPU computation for anything other than video display, and so naming tends to look like this is only for video display. The desktop environment with windows and applications is really the window manager and not X. Window managers are simply applications which use the X protocols to update a buffer. X itself does not provide any kind of user session.
X optionally loads a direct GPU access library…libGLX.so (this is dynamically loaded, and thus it has a dependency on a matching ABI). X runs a single program. That program manipulates a buffer. If you are without a display, then you still want a virtual server because you want the GPU to be accessible. There are some limited low-level cases of using the GPU without X, and I wish I could name them, but someone else will have to answer for your particular use-case (I wouldn’t mind seeing some examples of the low level cases just for my own curiousity). A strong clue though is that if any part of your program is linked against something using X protocols, then you must have the X server (a buffer context identified through the DISPLAY environment variable…the name of which is misleading since it doesn’t point at video display hardware, it points at a buffer usually used by video display hardware). Although you can exclude window managers and login managers you will likely need a virtual desktop in order to obtain a buffer context (it may be called a virtual desktop, but all it does is manage or point to a buffer).
A typical login goes like this:
- X is called (running as root or some system user) with a login manager as its only target.
- The user authenticates name and pass.
- X respawns suid of that user, but names a window manager as its only target.
- Window manager brings up windowing features. No window manager implies no features.
- Window manager allows running more programs. It isn't X running those programs (though events will eventually pass through to X).