• OS
  • who can use Linux but not windows? Share your Linux setup

bluetail I think the bit depth as set in the driver still has relevance

moonpie I want more context.

I think dithering is enabled per display based on EDID traits https://en.wikipedia.org/wiki/Extended_Display_Identification_Data. It would be great if we could query the status.
Might be wrong, but that would imply there are couple of assumptions made…

I have BenQ XL2546K, XL2566K, and an old LG 24GM79G. On my now sold M1 Mac with the LG, I noticed a fine screen pattern. On my PC with a 6950XT, it's similar but only up close. I suspect it's dithering. The BenQ displays don't show this on the 6950XT but have poor colors on the M1 Mac. I think the LG might be 6-bit with 2-bit FRC. Specs show BenQ has this too, but it's less noticeable. I also see banding on the BenQ, likely due to a limited color gamut.

WhisperingWind Thank you for that guide. Reading it I was able to compile a Linux Kernel on my Debian notebook that has Intel's dithering successfully disabled. The dithering was just spatial (not temporal) and didn't seem to cause obvious issues, at least not on static images, but who knows if it contributed to eye strain over time when watching scrolling/moving content. Time will tell.

I wonder if there is a faster way to have the source code changes apply other than to compile a new Kernel though. My poor notebook compiled for hours with loud fan noise. Does anyone know if we could shorten the process? If we want to modifiy the distro's own Kernel, I think we would have to repeat the change every time a new Kernel shows up in the distro's package manager. Which could become annoying fast if compiling takes that long each time.

    KM

    In this case, a package with a pre-compiled kernel can be put together and shared for easy installation, so users won't have to go through the hassle of compiling it themselves. However, different Linux distributions may have different package managers, library sets, and system components, which could affect the compatibility of the package. This task might require quite a bit of time and effort, as I would need to build, test, and maintain multiple packages for various distributions and possibly different kernel versions.

    Currently, there don't seem to be other options besides manually building the kernel, since changes are needed in the source code of the i915 module. Distributing this module separately isn't feasible either, as it's closely linked to a specific kernel version.

    moonpie

    Compression (FBC) is present, but as I understand it, it should be lossless (?) and not strain the eyes.

    My hardware doesn't support DRRS, so I couldn't read the DRRS status report.

    moonpie I don't think this is 100% the case, since I have 8th gen laptop (ThinkPad T480) where "Display Refresh Rate Switching" is an option in the 2017 drivers control panel. It pretty much has the same effect when enabled -- dynamically switching between 48/60hz with no obvious transition.

    Also, multiple eDP panels I've connected to the laptop (including ones as old as 2014) have both 48 and 60hz modes reported in the EDID. So features that are pretty similar to this seem to have been around for a while

    @WhisperingWind is there a chance to disable dithering in nvidia cards too? Besides the nvidia-x-server which can control dithering, I feel there is another layer of dithering that can't disabled.

      3 months later

      WhisperingWind You can set 8 bits with the command:

      xrandr --output HDMI-1 --set "max bpc" 8

      moonpie sudo cat /sys/kernel/debug/dri/1/i915_display_info

      Run that command to find out if dithering is even on.

      I thought I would migrate the latter discussion over here (out of the ditherig.exe topic). This is the MacBook Pro model with the "Intel Iris Pro 5200 Graphics " only. By default on Xubuntu, I get:

      xubuntu@xubuntu:~$ sudo cat /sys/kernel/debug/dri/1/i915_display_info | grep -i dither
      	pipe src=2880x1800+0+0, dither=no, bpp=24
      	pipe src=0x0+0+0, dither=no, bpp=0
      	pipe src=0x0+0+0, dither=no, bpp=0

      After xrandr --output eDP-1 --set "max bpc" 6, now I get:

      xubuntu@xubuntu:~$ sudo cat /sys/kernel/debug/dri/1/i915_display_info | grep -i dither
      	pipe src=2880x1800+0+0, dither=yes, bpp=18
      	pipe src=0x0+0+0, dither=no, bpp=0
      	pipe src=0x0+0+0, dither=no, bpp=0

      So maybe I wasn't crazy when I thought it felt worse after switching to 6-bit color. It seems bizarre to me that reducing the color depth would cause the driver to enable dithering. I must be missing some piece here.

      Here are the full (original, 8bpc) details.

        macsforme

        The driver (module) responsible for the operation of Intel graphics cards in Linux enables dithering in 6-bit mode. In 8+ bit modes, dithering is absent. This driver (module) is part of the Linux kernel.

        Previously, I created a fix that disables dithering in 6-bit mode on Linux. To apply this fix, you need to compile the kernel. Instructions can be found here: https://github.com/WhisperingWindLinux/Guides/blob/main/README.md.

        I used this guide to compile the kernel in Linux Mint Cinnamon on MacBook 13" 2017. After installing the custom kernel, my Wi-Fi stopped working. The problem with Wi-Fi was solved for me by the very first answer in this thread https://askubuntu.com/questions/55868/installing-broadcom-wireless-drivers.

        The command format for installing a driver to fix a problem with Wi-Fi:

        sudo apt install <PACKAGE_NAME>
        sudo apt install linux-firmware

        Where <PACKAGE_NAME> can be found in the "BROADCOM WIRELESS TABLE" table. For my MacBook 13" 2017, I installed the package firmware-b43-installer.

        The Bluetooth wasn't working either, but I didn't try to fix this issue since, even in 6-bit mode, the screen causes me discomfort. Perhaps the problem is related to the fact that the display is wide gamut. Such displays rarely work for me.

        moonpie Does 8bit work?

        The Intel driver natively reports 8-bit color ("bpp=24") and no dithering. When X is set to 8-bit color via xrandr, as @WhisperingWind pointed out, the Intel driver still reports 8-bit color and no dithering. Only after setting X to 6-bit color via xrandr does the Intel driver report 6-bit color ("bpp=18") and dithering enabled.

        Similar to when StillColor first came out and we were evaluating various color depths on macOS, one thing I still fail to comprehend is how a 6-bit framebuffer can be dithered into 8-bit (or even 6-bit + FRC) display output. It seems to me that the color data is just not there. The 6-bit colors would have to be non-aligned to true 6-bit increments, or there would have to be post-processing of some kind added on. (But still, based on what? And why? Driver-based smoothing of some kind?)

        I plan to mess with recompiling the kernel after I can set up the base operating system in a more permanent setup versus using a live USB or temporary installation partition. I'm very curious if this 2015 Retina MacBook Pro display can be made stable/comfortable under any conditions. Huge thanks to @WhisperingWind for the insights and guidance so far.

          dev