Bug 483700

Summary:	ICC profiles are always loaded from specified location, which breaks when that location is temporarily unavailable
Product:	[Plasma] KScreen	Reporter:	Gurenko Alex <agurenko>
Component:	common	Assignee:	kscreen-bugs-null <kscreen-bugs-null>
Status:	CONFIRMED ---
Severity:	normal	CC:	nate, xaver.hugl
Priority:	NOR	Keywords:	qt6
Version First Reported In:	6.0.2
Target Milestone:	---
Platform:	Other
OS:	Linux
See Also:	https://bugs.kde.org/show_bug.cgi?id=485555
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Gurenko Alex 2024-03-15 18:55:52 UTC

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

Comment 1 Zamundaaa 2024-03-15 19:13:31 UTC

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

Comment 2 Gurenko Alex 2024-03-15 23:50:17 UTC

(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

Comment 3 Nate Graham 2024-04-10 17:52:31 UTC

#2 is a bug that we should fix; please submit a separate bug report for that.

Comment 4 Gurenko Alex 2024-04-14 17:56:09 UTC

(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?

Comment 5 Nate Graham 2024-04-14 22:20:21 UTC

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.

Comment 6 Gurenko Alex 2024-04-15 08:38:00 UTC

(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).