The Nvidia GTK Tooltip Situation is Crazy

NOTE: This post is largely taken from my comment on the appropriate Ghostty discussion illustrating this issue.

On my desktop, I recently went back from a trusty little mini PC to a Franken-tower that has had one constant for about the last 10 years: an Nvidia GTX 1080. While this has been the first time I've used Linux with it, things have been relatively stable, save having some recent build issues in Nix 25.11 that have needed to be manually worked around.¹

After setup though, while using Ghostty, I had noticed a very strange warping of tooltips:

It also appeared that at least one other person had observed the problem and put in an issue, nearly a year before I noticed! Luckily I had not fully moved over to the tower yet, so it was easy to notice that the issue was not happening on my mini PC's AMD iGPU. As such, I just noted the issue's possible Nvidia relation and moved on.

With some time to look at it now after a month a half later, I was interested to see what the actual issue turned out to be. If you are too, read on! This was about a day and a half of my life, so I figured having some sort of record of it was in my interest.

Background

This has actually been a long-standing issue within GTK and Nvidia drivers, it seems.² The issue was ultimately written off as an Nvidia issue and moved on from, but some folks remained persistent, and continued to track it, both there and in the Nvidia forums as well.³

Time has moved on from some of the issues - reportedly, more recent versions of GTK made some related dialog box stretching unobservable, and the Vulkan backend does not exhibit the same issues. However, for those using the OpenGL renderer (including Ghostty, which explicitly does not use Vulkan as of this writing), the tooltip issues persisted.

However, one other more recent and much more promising development - and the one that fixed this issue - was the advent of Nvidia's new dmabuf-based EGL external platform library, egl-wayland2.⁴

Root Cause (a.k.a., Form an Orderly Line Please)

To summarize the detail in the aforementioned GTK issue, there was eventually some back and forth with the Nvidia and the GNOME/GTK devs, which reveals some interesting details with regards to out-of-order execution and how hard it can sometimes be to get these things right. According to the conversation, it appears that resizes to a surface were happening while it was not current, leading to some incorrect assumptions and deferral of the actual resize until buffers were ultimately swapped (assuming that this also means a frame render in this case). This ultimately leads to the stretching/distortion.

Fun fact: tooltips are surfaces too! This may come as a surprise or not, depending on how into graphics programming you are, but pretty much everything is a surface, because it simplifies intermediate rendering; imagine how you can just render a small little graphic and then composite that to a larger area.

You can observe this with Ghostty in debug mode. This whole snippet is the lifetime of a tooltip surface from initial hover, quickly moving from one button to another (which causes a content change without the tooltip disappearing), and then letting the tooltip disappear. The resizes happen when the tooltip changes, and the destroy ultimately happens a short time after the tooltip is allowed to disappear.

Creating EGL context version 3.3 (debug:no, forward:no, legacy:no, es:no)
OpenGL version: 4.6 (core)
GLSL version: 4.60 NVIDIA
Max texture size: 32768
Enabled features (use GDK_GL_DISABLE env var to disable):
    debug: ✓
    base-instance: ✓
    buffer-storage: ✓
    external-objects: ✓
    external-objects-win32: ✗
Resizing EGL window to 135 32
Resizing EGL window to 99 32
Resizing EGL window to 135 32
Destroying EGL context

Incidentally, this was assumed to be a concurrency issue, but GTK does not thread these operations it seems - so this (seemingly) was purely an issue with ordering!

While this apparently had been fixed in the EGLStream driver, it seemed like the issue persisted until it became harder to track, due to GNOME moving over to Vulkan as previously mentioned.

As mentioned, egl-wayland2 does not have this issue either, so let's talk about how one can get fixes for this now.

Fixing (Using egl-wayland2)

As mentioned in the summary, it looks like egl-wayland2, the dmabuf-based external platform library, fixes this issue. It already seems to be included in the 590 driver, but since I have a Pascal GPU I had to go a different route.

This is easy enough for you to do if you use Arch because they are already packaging it. If you use Nix like me, you get to have some fun!

Nvidia has tagged v1.0.1 now (hence it being out of RC), so I have gone ahead and put in a pull request to add it to nixpkgs⁵ that can be used once merged. In the meantime though I'm just building locally out of my own configuration as it's pretty minimal. Here's my current configuration:

{
  ...
}:
let
  # The dmabuf-based EGL external platform driver
  egl-wayland2 = pkgs.callPackage ./egl-wayland2.nix { };
in
{
  config = {
    hardware.graphics.extraPackages = [ egl-wayland2 ];
    services.xserver.videoDrivers = [ "nvidia" ];
    # Note that the Pascal GPUs (like the GTX 1080) are on their way out in
    # terms of driver support. Additionally, the nixos-25.11 driver is
    # currently outdated and will not build on modern kernels (6.19 and
    # higher). So we just manually pin here (and will likely continue to do
    # so).
    #
    # We additionally deactivate the old EGLStream platform driver to force use
    # of the dmabuf driver (see below).
    hardware.nvidia = {
      open = false;
      package = config.boot.kernelPackages.nvidiaPackages.mkDriver {
        version = "580.126.18";
        sha256_64bit = "sha256-p3gbLhwtZcZYCRTHbnntRU0ClF34RxHAMwcKCSqatJ0=";
        sha256_aarch64 = "sha256-pruxWQlLurymRL7PbR24NA6dNowwwX35p6j9mBIDcNs=";
        openSha256 = "sha256-1Q2wuDdZ6KiA/2L3IDN4WXF8t63V/4+JfrFeADI1Cjg=";
        settingsSha256 = "sha256-QMx4rUPEGp/8Mc+Bd8UmIet/Qr0GY8bnT/oDN8GAoEI=";
        persistencedSha256 = "sha256-ZBfPZyQKW9SkVdJ5cy0cxGap2oc7kyYRDOeM0XyfHfI=";
        # Deactivate the EGLStream external platform library (egl-wayland).
        # While the README in egl-wayland2 claims that it will take priority,
        # and indeed the ICD is given a higher priority
        # (09_nvidia_wayland2.json), it still does not seem to prevent the old
        # driver from taking over. Not too sure why.
        #
        # This was validated empirically by observing that disabling the driver
        # by removing its ICD file below resulted in the correction of
        # https://github.com/ghostty-org/ghostty/discussions/5283.
        postInstall = ''
          rm $out/share/egl/egl_external_platform.d/10_nvidia_wayland.json
        '';
      };
    };
  };
}

The Nvidia driver snippet has been pulled from nixpkgs-unstable, you can see it there.

You can just replace the local callPackage with the actual in-repo driver once it lands, and otherwise just add the package locally as it's pretty small.

Note that despite the documentation saying otherwise, I could not observe fixes until I actually removed the reference to the old platform driver as shown in the configuration. So far though, things seem to be stable.

Conclusion

As mentioned in the footnotes, I'd imagine this won't need to be done forever, given that the driver is said to support drivers from 560 and above, so I'd imagine any issues with things like availability or driver co-existence will be sorted out eventually. Hopefully this serves you in the interim if you have a GPU that doesn't have it yet.

However, for pretty much everything outside of what I did for this writeup and my own fixes, I admit near total ignorance. Funny enough, I really only started using Wayland (moving on from X11 and i3) this year, let alone with an Nvidia card! I'm not too sure if there are plans to support older drivers, what that would look like, or what it actually currently looks like.

Finally, a thank you to all of the stakeholders that communicated on this issue over the years - community members, GTK developers, and Nvidia developers alike, as it made fixing this issue simply a matter of research!