Created attachment 160343 [details] OLED font rendering, notice the borders New OLED monitors don’t have either RGB nor RBG pixel settings. Right now, to give you an example, LG OLED gaming monitors have RWBG settings. This botched the way fonts are rendered on screen. See https://github.com/bp2008/BetterClearTypeTuner#issue-785450772 and https://github.com/microsoft/PowerToys/issues/25595#issue-1672314603 to see how people are trying to fix this in other platforms. And it seems it’s not only the font rendering, since images, vectors, and desktop components are rendered this way, too. STEPS TO REPRODUCE 1. Buy an LG OLED Gaming monitor 2. Cry OBSERVED RESULT Fonts are rendered uglier than in LCD monitors. Some color contrasts present some unexpected colors (yellow/orange over grey/black) EXPECTED RESULT Rendering should be akin to LCD monitors SOFTWARE/OS VERSIONS Windows: 11 (yes, it happens there too) Linux/KDE Plasma: latest in Arch (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
Created attachment 160344 [details] Same text rendered in an LCD screen.
Created attachment 160345 [details] Firefox favicon rendered in an OLED monitor
Created attachment 160346 [details] Same favicon rendered in an LCD monitor
KWin doesn't deal with font or icon rendering. Please redirect this feature request to FreeType and Firefox respectively
(In reply to Zamundaaa from comment #4) > KWin doesn't deal with font or icon rendering. Please redirect this feature > request to FreeType and Firefox respectively Regarding fonts: I agree, will talk with freetype and fontconfig. Regarding colors: I disagree, since this not only happens in firefox, but the whole desktop's colors. I've uploaded the same issue in the KDE settings window, to give you an example.
Created attachment 160803 [details] This is an option from the KDE Settings window in an LED screen, no issues.
Created attachment 160804 [details] This is an option from the KDE Settings window in an OLED screen, notice the extra pixel rendering to the left side
Created attachment 160805 [details] This is a button from the KDE Settings window in an LED screen, no issues.
Created attachment 160806 [details] This is a button from the KDE Settings window in an OLED screen, notice the extra pixels to the left
KWin still doesn't render icons... It doesn't render anything in the windows you see. There are some necessary changes to allow apps to handle this properly though. Here's a list of what needs to happen for this to be potentially supported: - the kernel needs some way of identifying displays with these special subpixel layouts, and it needs to pass that information to userspace - libdrm should be updated to add a value to the currently broken subpixel enum (https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/317) - Wayland needs to be updated to add a value to its subpixel enum - KWin needs to be updated to pass the subpixel enum from the kernel along to clients That's all the things that are relevant for KWin. If you want icons to be rendered with the subpixel layout in mind (idk if that's even a thing right now), then you also need to get Qt, GTK, Firefox, Chromium and whatever toolkit/application you're using to handle that. And for fonts ofc, FreeType as well as the projects using it need to be adjusted to support the subpixel layout.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/4303
(In reply to Zamundaaa from comment #10) > KWin still doesn't render icons... It doesn't render anything in the windows > you see. > > There are some necessary changes to allow apps to handle this properly > though. Here's a list of what needs to happen for this to be potentially > supported: > - the kernel needs some way of identifying displays with these special > subpixel layouts, and it needs to pass that information to userspace > - libdrm should be updated to add a value to the currently broken subpixel > enum (https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/317) > - Wayland needs to be updated to add a value to its subpixel enum > - KWin needs to be updated to pass the subpixel enum from the kernel along > to clients > > That's all the things that are relevant for KWin. If you want icons to be > rendered with the subpixel layout in mind (idk if that's even a thing right > now), then you also need to get Qt, GTK, Firefox, Chromium and whatever > toolkit/application you're using to handle that. And for fonts ofc, FreeType > as well as the projects using it need to be adjusted to support the subpixel > layout. Thanks for such a detailed answer! I'll close the ticket, then.(In reply to Zamundaaa from comment #10) > KWin still doesn't render icons... It doesn't render anything in the windows > you see. > > There are some necessary changes to allow apps to handle this properly > though. Here's a list of what needs to happen for this to be potentially > supported: > - the kernel needs some way of identifying displays with these special > subpixel layouts, and it needs to pass that information to userspace > - libdrm should be updated to add a value to the currently broken subpixel > enum (https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/317) > - Wayland needs to be updated to add a value to its subpixel enum > - KWin needs to be updated to pass the subpixel enum from the kernel along > to clients > > That's all the things that are relevant for KWin. If you want icons to be > rendered with the subpixel layout in mind (idk if that's even a thing right > now), then you also need to get Qt, GTK, Firefox, Chromium and whatever > toolkit/application you're using to handle that. And for fonts ofc, FreeType > as well as the projects using it need to be adjusted to support the subpixel > layout. Thank you for such a detailed answer. It's really overwhelming how many factors are involved for rendering into a monitor! I'll close the ticket, then. Or should I move/open it somewhere else?
(In reply to Álvaro M. from comment #12) > Thank you for such a detailed answer. It's really overwhelming how many > factors are involved for rendering into a monitor! You said it. Frankly I find it amazing that anything ever works at all.
Git commit 2541e3fbe07e74d7bae1b614f13579e9735b58f1 by Xaver Hugl. Committed on 08/08/2023 at 11:12. Pushed by zamundaaa into branch 'master'. backends/drm: don't assume we never get new subpixel types M +3 -3 src/backends/drm/drm_connector.cpp https://invent.kde.org/plasma/kwin/-/commit/2541e3fbe07e74d7bae1b614f13579e9735b58f1
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/4305
Git commit e4b2811f78691c2b727cdb61d533a29ddd802028 by Xaver Hugl. Committed on 08/08/2023 at 12:23. Pushed by zamundaaa into branch 'Plasma/5.27'. backends/drm: don't assume we never get new subpixel types (cherry picked from commit 2541e3fbe07e74d7bae1b614f13579e9735b58f1) M +3 -3 src/backends/drm/drm_connector.cpp https://invent.kde.org/plasma/kwin/-/commit/e4b2811f78691c2b727cdb61d533a29ddd802028
> I'll close the ticket, then. Or should I move/open it somewhere else? I think it would be reasonable to keep this open until the part that needs changing in KWin is done. Could you please attach the edid of your monitor here? You should be able to fetch it with something like cat /sys/class/drm/card0/card0-DP-1/edid > edid.bin (card number and connector name may need adjusting)
Created attachment 160830 [details] OLED EDID
Looks like your monitor doesn't actually say anything about the subpixel layout, which slightly complicates the issue
Created attachment 160870 [details] OLED EDID (from Windows, using CRU)
(In reply to Zamundaaa from comment #19) > Looks like your monitor doesn't actually say anything about the subpixel > layout, which slightly complicates the issue I got into windows and dumped the EDID (uploaded to the ticket), which seems to be parseable using https://people.freedesktop.org/~imirkin/edid-decode/ I think this also doesn't say it's RWBG (WOLED)?
Indeed. I know that Windows drivers already have data bases for other missing information in EDIDs, so presumably they "fix" the problem for subpixel layouts with that too... I guess we have one more reason to make such a data base ourselves as well.
*** Bug 474890 has been marked as a duplicate of this bug. ***