DisplayCAL 3.8.1 - [Feature] Linux: Preliminary experimental Wayland support under GNOME 3 using colord


#1

hello ! for all who hardware calibrate their screen or want to … from the official changelog - https://displaycal.net/CHANGES.html

2019-05-18 15:11 (UTC) 3.8.1
DisplayCAL 3.8.1
Added in this release:

  >   [Feature] Linux: Preliminary experimental Wayland support under GNOME 3 using colord (requires ArgyllCMS 2.1 or newer as well). Caveats do apply:
        Window placement and ordering is completely up to the compositor under Wayland. There is generally no way for an application to place its own windows at specific relative locations or z-orders. As a result of this, the measurement window cannot stay always on top or be automatically centered. Extra care needs to be taken that other windows are not placed on top.
        Video card gamma table (videoLUT) access is handled by colord. Some functions like viewing current videoLUT contents may not be available.
        The measurement window color depth is limited to 8 bits per channel per pixel (but dithering is used to achieve a higher effective color depth).
        The measurement window may be subject to desktop-wide color management in upcoming versions of Wayland (although the display device is inhibited during measurements via the org.freedesktop.ColorManager.Device D-Bus API which should prevent this, and as a fallback a linear calibration sRGB profile is temporarily installed during measurements if the D-BUs API is unavailable, which should result in an identity transform, i.e. effectively no color management, as well as linear video card gamma tables).
        Application support for color management under Wayland via colord still seems to lacking (although the list may well be out-of-date).
        Only tested under GNOME 3 (Fedora 30, Ubuntu 19.04). Support for other desktop environments will need to be implemented separately until Wayland gains a color management and calibration/profiling protocol.
    [Feature] LG OLED 3D LUT format.

Changed in this release:

    [Enhancement] If the currently used ArgyllCMS version is not a standard version, but also not a beta, do not offer to switch to an installed official stable version if it's otherwise the same version number.
    [Enhancement] Include Quantum Dot LED (Samsung QLED Q9F) spectral sample colorimeter correction when importing for i1 Display Pro and ColorMunki Display (sourced from community colorimeter corrections database).
    [UI] Linux (Debian, Fedora, Ubuntu): Use wxPython Phoenix if installed.
    Prisma, Resolve: Set pattern generator background color to pattern color if using fullscreen patterns.

Fixed in this release:

    [Moderate] UnicodeDecodeError when a CCSS file contains unicode characters in the display device description (regression of a change in DisplayCAL 3.8 to use localized technology descriptions, SVN revision r5810).
    [Minor] APL calculation for Prisma and Resolve pattern generators was off by a few percent depending on pattern area and current pattern color.
    [Minor] Quick reporting on calibrated or uncalibrated display did not try to detect output levels if set to “Auto”.
    [Trivial] More gracefully deal with faulty tags in ICC profiles (fixes ICC profile information unhandled exception for colord-created profiles with malformed targ tags).
    [Trivial] [UI] Correctly update the audio button state on progress dialogs when changed on a previous window.
    [Cosmetic] [UI] Various minor potential rendering glitches.
    [Cosmetic] [UI] macOS (standalone application bundle): Splash screen did not animate.
    [Cosmetic] [UI] Linux: Add work-arounds for various Wayland-related wxPython rendering quirks and bugs (e.g. spacing around windows, popup menu placement).
    [Trivial] Linux: Try to work around sporadic colord profile installation quirks (“The profile was not added in time”).

Phasing out 0install support. While the 0install version of DisplayCAL (which was originally introduced as a replacement for the long-defunct Autopackage system under Linux) has had its uses, the low distribution (around 6%) of 0install versus the standalone version does no longer warrant the additional time and work needed to maintain this separate deployment path.
0install support is thus being phased out starting with DisplayCAL 3.7.2 and following releases, which are only available as “standalone” installations. Windows and macOS users will be updated automatically to the standalone version. Linux users should switch to a standalone package at their earliest convenience.
There will be a transition period of a few months during which old 0install-based DisplayCAL versions will continue to run, but afterwards the respective online infrastructure will be decommissioned.

ok so you don’t know what color calibration is or WHY would you want to do it to your screen in the first place (trust me if you get it wrong the first time you will probably be so confused and annoyed that you’ll never touch it again - that’s how bad it can get - but if you get it right - you’ll be blown away - the advantages are numerous for both consumers and creators )

oh you tought - software freedom and privacy/security are hard to understand - wait till you get into color theory :smiley:

so here is a good primer into it - for DisplayCal ofc (not the proprietary software that comes with the hardware calibrators themselves :sunglasses:)


Librem display osd feature request - brightness and RGB controls for hardware calibration
Librem 15v4 battery life realistic time
#2

i understand it’s still experimental but can someone please tell me if this is currently working on the Librem 5 or will i need to wait to see for myself when i get my order delivered ?