SUMMARY I've found potentially undesirable behavior with ICC profiles. It seems that it's always loaded from the specified location in Display settings. I've added mine from the NAS, which causes two issues: 1) Whenever outside of home NAS is not available at boot, hence profile is not loaded 2) Field becomes unresponsive and new profile cannot be selected, when previous profile is not accessible I would assume that whatever icc file is specified it's copied somewhere, so it continues to be available, no matter the availability of the initial location (same can be said for cloud storage which may not be available at login time) STEPS TO REPRODUCE 1. Install ICC profile from network location 2. Make said location unavailable 3. Try to login and change ICC profile OBSERVED RESULT No ICC profile loaded (and field is empty) and cannot set to new profile because location is unavailable and whole Display settings window hangs. EXPECTED RESULT ...something else? I would say that hang should not occur and/or message should be displayed that previous ICC cannot be found? That should probable be shown as system-wide message (a pop up?) at the time it fails to load. But again, I'd expect the specified file to be copied to some location and used from there. SOFTWARE/OS VERSIONS Operating System: Fedora Linux 40 KDE Plasma Version: 6.0.2 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Kernel Version: 6.8.0-63.fc40.1.x86_64 (64-bit) Graphics Platform: Wayland Processors: 24 × AMD Ryzen 9 5900X 12-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: AMD Radeon RX 7900 XTX Manufacturer: Micro-Star International Co., Ltd. Product Name: MS-7C84 System Version: 1.0 ADDITIONAL INFORMATION
Copying the profile to a local directory (maybe to "~/.local/share/icc/" that colord uses) sounds like a reasonable request to me > Field becomes unresponsive and new profile cannot be selected, when previous profile is not accessible That's a surprise though, and doesn't happen on my PC
(In reply to Zamundaaa from comment #1) > Copying the profile to a local directory (maybe to "~/.local/share/icc/" > that colord uses) sounds like a reasonable request to me > > > Field becomes unresponsive and new profile cannot be selected, when previous profile is not accessible > That's a surprise though, and doesn't happen on my PC Yeah, copying it locally to .local sounds good. For the other, I'm not sure how you tested it, I have a /mnt/nas/<shares> configured as systemd mount and automount units, probably it's waiting for the time out, but I'm pretty sure I've waited specified 30s and it was still hanging
#2 is a bug that we should fix; please submit a separate bug report for that.
(In reply to Nate Graham from comment #3) > #2 is a bug that we should fix; please submit a separate bug report for that. I've created this BZ: https://bugs.kde.org/show_bug.cgi?id=485555 for the issue with existing profile, I guess we can keep this one as a RFE?
Indeed, this ticket becomes a request to copy the user-specified ICC profile to an internal, always-available location. Which, now that I think about it, would reduce or eliminate the need for Bug 485555. So we'll see which approach wins out.
(In reply to Nate Graham from comment #5) > Indeed, this ticket becomes a request to copy the user-specified ICC profile > to an internal, always-available location. Which, now that I think about it, > would reduce or eliminate the need for Bug 485555. So we'll see which > approach wins out. I have not extensively tested behavior, but I think **at least** a message is required on login if the existing profile cannot be loaded (deleted by user for example). Just because we copy it to the local destination, does not mean it won't become unavailable (I had a btrfs meltdown last year for the /home which is on a separate drive).