| Summary: | Color profiles should take into account monitor model and serial number | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | Neviril <nevineviril> |
| Component: | General | Assignee: | Krita Bugs <krita-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | wishlist | CC: | alvin, dimula73, grum999, info, info, tamtamy.tymona |
| Priority: | NOR | ||
| Version: | nightly build (please specify the git hash!) | ||
| Target Milestone: | --- | ||
| Platform: | Microsoft Windows | ||
| OS: | Microsoft Windows | ||
| Latest Commit: | https://invent.kde.org/graphics/krita/commit/054517cd8f42e0f4215f7eae2628428bc23b3370 | Version Fixed In: | |
| Sentry Crash Report: | |||
|
Description
Neviril
2019-05-13 14:57:44 UTC
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 |