But, isn’t the calibration dependent from OS and Driver version?
Like that it isn’t possible to use a calibration from windows, on linux.
afaik that’s not the case
I will give it a try and I’ll post the results, thanks!
Btw, I wonder when will it be available a more stable and “official” solution to this problem.
Please take following comments with care as I’m not into this topic.
Maybe it is a more general permission problem, which effects all different kind of USB devices under Ubuntu/Debian.
E.g. I struggled with permission problems as well on Debian 10 and the i1Studio from xrite.
Setting an udev rule did it in my case:
in /etc/udev/
I added 90-xlite-color_cal.rules
with following content
SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="0765", ATTR{idProduct}=="6008", TAG+="uaccess"
(updated according to @darix comment below)
You can find out the attributes idVendor and idProcduct of your device with
sudo dmesg after you plugged in the spyderX. Maybe a restart is needed after setting this rule.
dont use groups. use TAG+="uaccess" which will add an ACL for your locally logged in user on plug in.
a much saner rule. groups like “plugdev” are no longer preferred.
1 Like
Thanks for the hint!
With this hint I found this at the Debian Wiki:
https://wiki.debian.org/USB/GadgetSetup
I guess this will be similar for Ubuntu and other distributions.
I’ve tried the live you linked but I got the same error. Maybe it isn’t related to the flatpak sandbox:
14:11:21,675 DisplayCAL: Starting interaction with subprocess
14:11:24,933 Number of patches = 3
14:11:24,942 Setting up the instrument
14:11:24,943 usb_open_port: open ‘/dev/bus/usb/001/004’ config 1 failed (-1) (Permissions ?)
14:11:24,943 usb_open_port: open ‘/dev/bus/usb/001/004’ config 1 failed (-1) (Permissions ?)
14:11:24,943 dispread: Error - new_disprd failed with ‘Instrument Access Failed’
14:11:24,944
14:11:24,945 DisplayCAL: Reached EOF (OK)
14:11:25,046 dispread exitcode: 1
14:11:25,046 …aborted.
14:11:25,054 DisplayCAL: Uninhibited org.gnome.SessionManager
Would this trick work even with a flatpak app inside its sandbox?
With the udev rule this way, it works from the flatpak!!!
Thank you very much guys!!
Hoping that there will be some stable workaround for everyone asap.
2 Likes
I must be missing something. I just ran display cal today, no issues whatsoever, running Manjaro XFCE and a Spyder5. I’m not usually this lucky…
Yes, it works out of the box on Manjaro. I’ve been running Manjaro for a couple of years now, since it was recommended to me in one of the posts on this site. I occasionally have some small headaches when I upgrade due to my NVIDIA graphics card setup, but overall it is very flexible and give access to the Arch linux repositories which provide a huge range of packages.
Hey Matt- wanted to thank you for setting up the Zoom session after the technical problems on Jitsu. Saved the day!
I’m still asking myself why such a very nice and unique piece of work is being buried by its author by just refusing any help from the community !!! DisplayCAL is being removed by all Linux distributions… This is depressing !
3 Likes
But I think it also reflects the open source/Linux worlds lack of awareness or interest in color that they are not prepared to bundle DisplayCAL’s dependencies to keep it available. The Wayland color situation underlines this lack of interest in color usability, even in the face of the disruption caused by wide gamut displays and HDR. Color management should be as integral to a modern user facing computer system as mouse/trackpad/touch support.
4 Likes
keeping old python versions alive forever is not an option. in all seriousness.
2 Likes
In all seriousness, users don’t care about how old software is, they just need the functionality they need. If you remove it for (what to them seem like) theological reasons, then they will have no choice but to switch to something that does do what they need, such as MSWindows or Mac.
I think these statements reflect lack of awareness or interest in the purpose of distributions and the effort put into keeping the ecosystem secure. There’s a huge (largely voluntary) effort in keeping this things working. And e.g. debian wasn’t unaware, neither was the community here. They were offering to port to python3 well ahead of removing it, but Florian turned the offer down. The problem here is clearly the bus factor: A project that is widely depended upon, but only a single person takes care of. If that person lacks the time (as is the case here for a long time), things go downhill. The circumstances here were especially bad, because if a maintainer is roundly refusing to cooperate and the project is important enough, a fork usually happens (like with e.g. syncthing-gtk, which I’d consider much less “important”) - however here a respected and responsive maintainer actively turned help down, but did not deliver himself (where again, there’s no criticism intended for the latter, you can’t demand anything from a volunteer dev - more readiness to accept help would have been nice, and still is).
3 Likes
Distro’s that curate their own versions of user applications suck IMHO. They’ve held back Linux since its inception. They create a mountain of work for themselves and also disenfranchise the application writers and end users by disconnecting them, cutting off feedback and support, and slowing down releases. Instead of working hard on comprehensive, standardized and stable ABI’s, Distro’s fall back on patching and recompiling applications to “keep things working”. There’s a reason 90% of people use MSWindows, and it comes down to application availability, and that comes down to ABI’s.
Perhaps what they lack is a stable platform to write applications on. Trying to force them to re-write perfectly good code is bound to wear them down, and assuming this can be “fixed” by diluting their authorship of their code is making an assumptions about the nature of the project that may not be true.
A highly technical and specialized application is much less likely to survive a fork than simpler or more broadly used software for which commercial entities are prepared to throw paid developers at. My impression is that Florian is quite busy with other work (something I completely get - giving code away doesn’t pay the bills!), and on the DisplayCAL front is a good way through some sort of re-write, and abandoning that to re-work the current code is not a terrible attractive prospect.
2 Likes
Sure thing, that’s a stance to take (and one that many agree with). Then I don’t see what the problem is though - just don’t use the sucky distros respectively their sucky user application offerings. You can use distros that follow other schemes (I forgot what it was called, but there’s one that provides all dependencies with every package) or you can use any stable distro and get your user applications another way (snap, appimage, flatpak, compile, …).
Anyone complaining about that is just not using the stable offerings. Stay e.g. on debian LTS and you will keep python2 for another 3 years (4 years after python itself stopped supporting python2).
No-one is forcing anyone to rewrite. Again, all python3 ports that the original maintainer decried as “impossible” (which Florian doesn’t do) I followed have been ported successfully by third-parties. And I honestly don’t understand what you mean by “diluting authorship”.
And again: I get how porting to python3 is ugly, boring work, and I get even more how one might not have the time because of bills and life in general. Even more reason why I would expect it to be a welcome prospect, to have the ugly, boring stuff (move status quo from 2 to 3) get done for you, so that the expert can focus on what matters (color, architecture, …).
I think your idea of API’s rather differs to mine. A small example - there’s no way to install a driver to a new USB device on Linux without having to hack udev permission files. MSWindows has this solved (in an ugly way) with .ini files, Android has this covered with device_filter.xml and OS X doesn’t have the problem at all.