It isn’t the module format I’m speaking of. It is the SoC inside of it. This is the same SoC as used with the TX1, which in turn is much older. In fact, the TX1 was the first 64-bit ARM system with a GPU, and came right after the TK1 (which was in turn the first 32-bit ARM system with a GPU). The TK1 did not come with a separate module and carrier board; the TX1 was the first separate Jetson module/carrier board. The Nano was a new form factor, but the technology on the silicon was already old.
When you speak of the driver branch, such as the 440, you are speaking of PCI/PCIe-based GPUs. Those have different drivers than what Jetsons use due to the Jetson GPUs being directly integrated to the memory controller. The basic architecture, what you mentioned as Maxwell, is the same, but the drivers are incompatible in mainline versus Jetson due to the memory controller integration.
I think the GPU part of the drivers, excluding the memory controller versus PCIe, are probably the same. However, These older GPUs have not had new feature development for a long time, and during the time in which they were actively developed I think Wayland and Vulkan were much more primitive than they are now.
I know it isn’t what you want to hear, but if you want a more modern driver you would probably have to use one of the Xavier or Orin series (these are actively developed for new features and would tend to follow updates for Wayland and Vulkan). Even if there is a bug in software for Wayland/Vulkan in Orin or Xavier, this would be actively supported as a fix, whereas unless it is for security reasons, then it is unlikely to see such a fix with the maintenance-only SoC of the TX1/Nano.
This does not mean that there is not a bug fix possible for Wayland/Vulkan, but someone from NVIDIA would have to know of a specific error or issue to say if that has a fix. Upgrading to Ubuntu 20.04 won’t happen, at least not officially. I have seen people on the forums who sometimes succeed (with some work) at such an upgrade. Unfortunately, that upgrade won’t be an upgrade of the GPU driver since they are binary-only in these older systems, and going to a new Linux release might imply needing to either hold back the GPU driver release, or else going to Mesa (which is software-rendering, and loses the GPU’s benefits).
Installing kernel modules for various squashfs items should be relatively straight-forward. It is just a case of configuring that release of kernel source to your running system’s configuration (including CONFIG_LOCALVERSION), adding those features with a menu editor in module format, compiling, and copying the resulting squashfs “*.ko” files to the right subdirectory within “/lib/modules/$(uname -r)/kernel”. In fact there is an extended thread on adding this:
https://forums.developer.nvidia.com/t/how-do-i-install-ubuntu-frame-in-jetson-nano/228370
(much of this though is just about how to compile and install modules; I don’t use squashfs, so I don’t know all of the requirements to be compiled when working on this)
The topic of supporting Xorg is in fact one of the more interesting topics. When it comes to a binary-only GPU driver in user space, then that means the driver has to work with the specific Application Binary Interface (the “ABI”), and that newer Xorg X servers https://forums.developer.nvidia.com/t/how-do-i-install-ubuntu-frame-in-jetson-nano/228370usually use a new ABI. If a newer Xorg server were to be available with the older ABI, then there would be no issue to simply copying the old GPU driver from the older release into a newer release.
There was some semi-recent news about NVIDIA providing source now for GPU drivers, but I don’t know if that applies to Jetsons. I don’t know the details, but at least for the PCIe video cards, there is apparently some publicly available source for it now.