(Assigning this to @codeanticode since it's not official API…)

Two years later and I've now run into this issue on Processing 3.5.3 on Linux.

Please make textureSampling an official part of the API so we can rely on it when writing interesting shaders.

noSmooth(); seems to make scaled up images draw using nearest neighbor, but only on the JAVA2D renderer, with no indication of the difference in P2D, which may not be related, but probably should be fixed.

((PGraphicsOpenGL) g).textureSampling(2); does however make things get drawn with nearest neighbor on Linux Mint for me though.

@scudly Just randomly flew by here. I read your forum post
Just a guess : Your shader Problem looks from this far away more like an Anti-Aliasing issue, make your own reserach. Hardware multisampling technigues such as MSAA can be handy, so check your Linux settings, you also can multisample direct in your shader

   // antialiasing - https://www.shadertoy.com/view/tslGz7
   const int AA = 2;
    for (int jj = 0; jj < AA; jj++)
        for (int ii = 0; ii < AA; ii++) {

            vec2 q = fragCoord.xy + vec2(float(ii), float(jj)) / float(AA);
            vec2 st = (2. * q - iResolution.xy) / min(iResolution.x, iResolution.y);
        };
            
    col = col / float(AA * AA);

The other case is: Some default (behind the scenes) processing render settings can cause some weird results when using shaders, see here #1272 (comment)

Good Luck

FIXED! Or at least hacked around.

In the Linux NVIDIA X Server Settings application, under Antialiasing Settings, I set Anisotropic Filtering to Override Application Setting, leaving the slider at 1x. Along with textureSampling(2), the incorrect interpolation I was getting goes away and my images now look the same on Linux as they do on Windows and Android.

Now we just have to get Processing to do whatever it is that that setting is doing.