SUMMARY A discussion on #Krita on IRC relatively to a bug in the color profile->display association revealed a larger background problem of associating a color profile to a "screen number". Screen numbers are not fixed: they can change depending on which is the primary display, number of displays connected and what display outputs are enabled on the graphics card at any given time. On the other hand, monitor model and serial number are fixed. It's important to take into account some sort of unique identifier, as the calibration (and associated color profile) of two or more physically identical displays will likely not be identical, as personal experience also revealed after coming across identical displays with noticeably different factory colors even with the same display settings from the OSD. The Krita developer involved in the discussion pointed out that there doesn't seem to be a way of getting the screenNumber of a QScreen, that QDesktopWidget is also pretty much obsolete and doesn't really work well under high dpi, and that some broken displays might not not have the proper serial number in their EDID info. SOFTWARE/OS VERSIONS Windows: Windows 10 64-bit 1809 ADDITIONAL INFORMATION Information valid as of the latest nightly build from Jenkins at the time of writing (git 1f648b3).
By the way, I just ran `qtdiag` on Windows and it gives an empty string for manufacturer/model/serial number. Turns out they aren't implemented for Windows (and also macOS it seems)... should I say I'm not surprised. They can still be implemented, but at the end there needs to be a fallback in case those strings are really not available. So what we probably need are: 1. A way to generate an unique key for a monitor (probably by manufacturer/model/serial no.). 2. Somehow a fallback mapping to be used when the unique key doesn't work? Or would it be better to have Krita just ask the user to confirm the display profile mapping on startup and whenever the connected screens are changed (but only if the user have set a custom profile)?
*** Bug 412608 has been marked as a duplicate of this bug. ***
In the duplicate bug report there is a suggestion to use the size of the display in pixels > Getting an extra hint under "Screen" to identify the monitors on this interface. (eg. can be the geometry@position: eg. 1920x1080@0,0 and 1440x900@1920,0, or device name) as a hint when assigning profiles. It will be extra useful if: - the qtdiag returns empty string, so the display model etc. is not known, - the user has several displays of the same manufacturer and model name (probably bought in bunk, often seen in companies).
This commit has been made in response to bug : https://invent.kde.org/graphics/krita/-/commit/77f6562d503686816cb728122dfdaa1bb0168aff It changes the "Screen X" text to something that should include resolution and either model or manufacturer (manufacturer, if the model is empty). The information provided is kind of very varied depending on the display and manufacturer so it's difficult to judge which part of the information is the most useful, and I tried to make it short. I guess it could still be improved by ensuring all of the information Krita has access to is displayed, but - maybe it's already helpful?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
The colour profile setting is still based on the index of the screen as in `QApplication::screens()`. Say you close the lid of your laptop and switch to an external monitor, the colour profile for the wrong monitor will be used.
Do you think we could assume that displays with the exact same strings for [all information we could get from Qt screen] are the same and can use the same color profile? I could make it use all the model information etc. as a key in configuration, but that information is so random that I'm a bit scared to use it. Though, it looks like using the index is not much better either. So I guess the model (+all others) string would be better. Is that what you had in mind? It seems to make sense for me.
I think Qt still haven't implemented the code to retrieve the display model/serial number for Windows (don't know about macOS). The only available information on Windows - the name - is in the form of `\\.\DISPLAY1` which I am unable to find documentation on whether it is assigned in a deterministic way... but at least it shouldn't change from just closing the laptop lid, unlike the list index which definitely changes.
*** Bug 466068 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/1768
Hi Wanted to test last Krita Next and Plus on windows. krita-5.1.5 (e0453bf87f) krita-5.2.0 (6128ba9453) Krita process start in an endless loop Running krita.com from cmd.exe, I get this message printed in a loop: > calculateMonitorNameToInfo: cannot join monitor name and display info via display id: name: \\.\DISPLAY1 -> id: \\?\DISPLAY#DEFAULT_MONITOR#4&8B487E3&0&UID0#{E6F07B5F-EE97-4A90-B076-33F57BF4EAA7} Could it be related to this bug? and MR 1768? Note: my windows 10 runs in a virtual machine (I use it just to execute krita to test if my plugins are working on windows...) Grum999
Git commit 054517cd8f42e0f4215f7eae2628428bc23b3370 by Agata Cacko. Committed on 15/05/2023 at 14:09. Pushed by tymond into branch 'master'. Fix color profiles being assigned to screens by indexes Before this commit, Krita assigned color profiles to screens based on screen indexes, which apparently can change (see the bug report). This commit introduces "screen string identifier" which is a concatenation of multiple screen properties like manufacturer, serial number, resolution etc. (Note that especially on Windows, any of those properties might be empty strings). Related: bug 412608, bug 412943 M +36 -1 libs/ui/kis_config.cc M +2 -0 libs/ui/kis_config.h https://invent.kde.org/graphics/krita/commit/054517cd8f42e0f4215f7eae2628428bc23b3370
Hi, grum999! This patch should fix the issue: https://invent.kde.org/szaman/qtbase/commit/1300d28165436c389aa4820d3a24d8a4510566e1 If everything goes well, the problem should go with the next nightly builds
Hi Dmitry Tested krita-nightly-x64-5.2.0-prealpha-b91d20e6a6 (build #2099, 2023-05-18@10.18am) on my Windows VM Problem is still here: krita stay stucked in a loop to display "...cannot join monitor name..." message :-( Grum999