I can make changes in the amdgpu module. However, it won't be a 'clean' code, and I won't be able to test the results.
who can use Linux but not windows? Share your Linux setup
aticonfig is old and isn't used anymore. The driver in use for pretty much everyone is amdgpu. Sometimes you can set an option in GRUB but generally it's still a work-in-progress, doesn't even easily have the ability to change the colour space away from RGB and colour depth changes seem mostly to be between 30 and 24 bits. So dithering is probably present.
It'll probably get there someday, but not soon unless you're using Windows.
Don't spend a lot of time on this, it's not ready for what you want.
- Edited
Sunspark swaywm has setting foreach output to set render bit depth though
https://man.archlinux.org/man/sway-output.5
Even for subpixel layout…
- Edited
''''''''''''''
- Edited
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.
- Edited
,,,,,,,,,,,
- Edited
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.
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.
- Edited
.............
- Edited
Have you looked at Intel VTune? Note: may not work with ARC.
No, I haven't tried it yet. I'll take a look, thanks for the link.
FBC and DRRS don't look good
It seems like the folks at Intel decided to complicate things for kernel developers with all this functionality
- Edited
.................
- Edited
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.
- Edited
............
- Edited
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
- Edited
...
@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.
- Edited
Unfortunately, I can't offer much advice on Nvidia graphics cards.
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.
- Edited
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.