Nvidia G960M would suggest a laptop, and so it might have dual GPUs: a discrete Nvidia GPU and a more power-efficient iGPU integrated to the main CPU. This is called an "Optimus" configuration with Nvidia. These have historically been a bit awkward to handle in Linux and in particular in Debian, but Debian 11 fortunately has new enough components that Optimus support should be fairly smooth now.
Your Xorg.0.log confirms that you indeed have dual GPUs:
[ 10944.179] (II) modeset(0): glamor X acceleration enabled on Mesa Intel(R) HD Graphics 530 (SKL GT2) ... [ 10944.204] (II) NVIDIA(G0): NVIDIA GPU NVIDIA GeForce GTX 960M (GM107-A) at PCI:1:0:0
But only the Intel iGPU's modeset driver is currently detecting a connected display.
[ 10944.189] (II) modeset(0): EDID for output eDP-1 ... [ 10944.190] (II) modeset(0): LG Display [ 10944.190] (II) modeset(0): LP156WF6-SPK1 ... [ 10944.195] (II) modeset(0): Output eDP-1 connected ... [ 10944.195] (II) modeset(0): Output eDP-1 using initial mode 1920x1080 +0+0
The Nvidia driver fails to find any displays connected to the Nvidia GPU, and is defaulting to a virtual screen size of 640x480:
[ 10944.204] (II) NVIDIA(G0): Validated MetaModes: [ 10944.204] (II) NVIDIA(G0): "NULL" [ 10944.204] (II) NVIDIA(G0): Virtual screen size determined to be 640 x 480 [ 10944.204] (WW) NVIDIA(G0): Unable to get display device for DPI computation.
In my experience, some window manager effects that use screen dimming may cause flickering with some Intel iGPU models, if your configuration uses the old intel iGPU driver rather than the newer kernel-based modesetting driver for the iGPU. But since your log indicates you're already using the modesetting X11 driver, that's not the source of your flickering issue.
Your active GPU is currently the Intel HD Graphics 530, which includes some microcontroller components with their own loadable firmware files. Those microcontrollers are known as:
- Display MicroController (DMC), responsible for saving and restoring the display engine state, when transitioning between low-power and normal states.
- Graphics microcontroller (GuC), also related to power management and fast GPU context switching.
- HEVC/H.265 microcontroller (HuC), dedicated to HEVC/H.265 video codec operations.
Flickering makes me think that perhaps something related to GPU power management or context switching is not happening as quickly as it should, which might be caused by missing DMC or GuC firmwares. Make sure you have the firmware-misc-nonfree package from the non-free section of the Debian 11 repository installed: it includes all the necessary firmware files for your Intel iGPU.
To make sure the firmware actually gets downloaded, you might want to add a few module parameters for the i915 module that drives the Intel iGPU. Create file /etc/modprobe.d/i915.conf with the following contents:
options i915 modeset=1 enable_guc=2
Since the use of the GuC microcontroller in Linux is still somewhat experimental, these options instruct the driver to use only a minimal set of known-safe operations.
After adding this configuration snippet, run update-initramfs -u so that the added options will be included in initramfs, as the i915 driver is typically loaded very early in the boot process.
If the laptop hardware does not include a multiplexer to switch outputs between the GPUs (known as muxless Optimus), then each display connection will be hardwired to a particular GPU. In this configuration, you can still use both GPUs, but display data must sometimes be transferred from one GPU to the other (known as "PRIME Render Offload" or "reverse PRIME" depending on transfer direction).
More details on Debian Wiki: https://wiki.debian.org/NVIDIA%20Optimus#PRIMEOffload
If your laptop's hardware does include a multiplexer, it should be controllable using Linux's VGA Switcheroo subsystem. On muxless systems, you can also use this to completely power down the Nvidia GPU when you know you won't need it, and/or you need to minimize battery power consumption.
Usually on laptops with the muxless Optimus hardware setup, the laptop's integrated display will be hardwired to the iGPU, to allow minimizing the battery power usage when no external display is connected and there is no need for high-performance 3D graphics.
My work laptop has a configuration that is pretty similar to yours, so here's a few tips on use of Optimus on Debian 11.
This is not related to your flickering issue, but in order to prepare your X11 server to use both GPUs in either PRIME or reverse-PRIME configuration, you might need to add a configuration snippet as /etc/X11/xorg.conf.d/20-optimus.conf:
Section "Screen" Identifier "DefaultScreen" GPUDevice "Nvidia dGPU" Device "Intel iGPU" EndSection Section "Device" Identifier "Intel iGPU" Driver "modesetting" BusID "PCI:0:2:0" EndSection Section "Device" Identifier "Nvidia dGPU" Driver "nvidia" BusID "PCI:1:0:0" EndSection
After this addition (and restarting the X11 server or rebooting), your xrandr --listproviders should list two providers (i.e. two GPU drivers), and your configuration should be ready for PRIME or reverse-PRIME operations.
For PRIME (i.e. Nvidia-boosted graphics on laptop's internal screen), just set the following two environment variables for any program that needs high-performance graphics:
__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia
For reverse-PRIME (using the displays connected through the Nvidia GPU to extend your current desktop configuration), you would need to run two commands:
xrandr --setprovideroutputsource 1 0 # tell Nvidia to accept display data from Intel xrandr --auto # autodetect displays on now-available Nvidia display outputs
(Please don't post images of text unless the problem is about display rendering of text: such images can be problematic for people with vision issues, and won't usually provide any more information over copying and pasting the actual text with a code block formatting added.)
A "transparent blob" sounds like it might be an air bubble under a privacy shield, anti-glare film or similar. If so, that would be a physical issue and would have nothing to do with the GPU or its drivers. If you use the desktop environment's screenshot tool, does it capture the blob or not?
If the blob is not visible in screenshots, then it might be an air bubble under the display's surface film or some other physical issue in the actual display panel. If it is visible, it might indicate a GPU driver bug or a fault in the display memory responsible for the location of the blob.
