Display Calibration and Audio Equalizer for Dom0 ?

289 views
Skip to first unread message

kalle

unread,
Sep 1, 2016, 10:51:24 AM9/1/16
to qubes-users
how can I calibrate my display in qubes ?
my display is quite yellow

what good program should I install into qubes, dom0 to calibrate it ?


is there any good audio equalizer like dell waves maxx audio & windows sound settings, that modifies
the sound output ?

like virtual surround, noise cancellation, bass/trebble modifier...

Connor Page

unread,
Sep 2, 2016, 6:49:41 PM9/2/16
to qubes-users
I have calibrated my yellow screen using argyllcms. I don't attach usb devices to dom0 so installed it in sys-usb as well. used https://encrypted.pcode.nl/blog/2013/11/24/display-color-profiling-on-linux/ as a rough guide. to get the calibration done you just need to run dispcal and then transfer the calibration file to dom0. then test it with "dispwin xxx.cal" in dom0. if happy, create an autostart item with that command (probably, using the full path to the calibration file) and you're done.

I went further and created an icc profile for use in firefox and photo software. note that some displays use proprietory colour-mixing algorithms so Linux tools may be ineffective with them :( (e.g., pentile matrix on some very high resolution screens)

Zrubi

unread,
Oct 28, 2016, 7:19:56 AM10/28/16
to Connor Page, qubes-users
On 09/03/2016 12:49 AM, Connor Page wrote:
> I have calibrated my yellow screen using argyllcms.
> I don't attach usb devices to dom0 so installed it in sys-usb as well.
> used https://encrypted.pcode.nl/blog/2013/11/24/display-color-profiling-on-linux/ as a rough guide.
> to get the calibration done you just need to run dispcal and then transfer the calibration file to dom0.
> then test it with "dispwin xxx.cal" in dom0. if happy, create an autostart item with that command (probably,
> using the full path to the calibration file) and you're done.

I just started to experiment with display color correction things.

I wonder how it is workig in Qubes because as far as i know:

- the display profile is used only the programs are aware of icc profiles.

- the X server runs in dom0, the apps are in AppVMs - but no
communication about display prifiles (colord) because of the qubes gui
protocol.

> I went further and created an icc profile for use in firefox and photo software.
If no colord is runnin in an appvm, how they apply your prifile then?
You just manually configure all of the icc profile aware apps??


Can you please describe in more details what and how you achieved?

Thanks.


--
Zrubi

signature.asc

Zrubi

unread,
Nov 2, 2016, 12:55:50 PM11/2/16
to qubes...@googlegroups.com, Marek Marczykowski-Górecki
On 10/28/2016 01:19 PM, Zrubi wrote:
> On 09/03/2016 12:49 AM, Connor Page wrote:
>> I have calibrated my yellow screen using argyllcms.
>> I don't attach usb devices to dom0 so installed it in sys-usb as well.
>> used https://encrypted.pcode.nl/blog/2013/11/24/display-color-profiling-on-linux/ as a rough guide.
>> to get the calibration done you just need to run dispcal and then transfer the calibration file to dom0.
>> then test it with "dispwin xxx.cal" in dom0. if happy, create an autostart item with that command (probably,
>> using the full path to the calibration file) and you're done.
>
> I just started to experiment with display color correction things.
>
> I wonder how it is workig in Qubes because as far as i know:
>
> - the display profile is used only the programs are aware of icc profiles.
>
> - the X server runs in dom0, the apps are in AppVMs - but no
> communication about display prifiles (colord) because of the qubes gui
> protocol.
>

@Marek:
Do you have any idea what to look for in order to be able to calibrate
my screen under Qubes?

What I already tried:

- the standard gnome color management tools runned in (sys-usb)
But it is complaining that there is no display to calibrate.

running the same calibration software directly complains about there is
no colord available (masked)

(gcm-calibrate:1459): Gcm-WARNING **: failed to connect to colord: Error
calling StartServiceByName for org.freedesktop.ColorManager:
GDBus.Error:org.freedesktop.systemd1.UnitMasked: Unit colord.service is
masked.



- diplayCal is happy with the dummy display seen by the AppVM, and do
not depend on colord - but it fails on some X calls(?)

Debug: window wxComboBox(0x561c58c3a230, ) lost focus even though it
didn't have it
X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 42 (X_SetInputFocus)



Or I should connect the calibration device to dom0 and start the
calibration from dom0?
(Also noted that there is no colord running, so I may have to apply the
profile viea diplaycal cli)


Thanks.


--
Zrubi

signature.asc

Marek Marczykowski-Górecki

unread,
Nov 2, 2016, 2:28:10 PM11/2/16
to Zrubi, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, Nov 02, 2016 at 05:55:37PM +0100, Zrubi wrote:
> On 10/28/2016 01:19 PM, Zrubi wrote:
> > On 09/03/2016 12:49 AM, Connor Page wrote:
> >> I have calibrated my yellow screen using argyllcms.
> >> I don't attach usb devices to dom0 so installed it in sys-usb as well.
> >> used https://encrypted.pcode.nl/blog/2013/11/24/display-color-profiling-on-linux/ as a rough guide.
> >> to get the calibration done you just need to run dispcal and then transfer the calibration file to dom0.
> >> then test it with "dispwin xxx.cal" in dom0. if happy, create an autostart item with that command (probably,
> >> using the full path to the calibration file) and you're done.
> >
> > I just started to experiment with display color correction things.
> >
> > I wonder how it is workig in Qubes because as far as i know:
> >
> > - the display profile is used only the programs are aware of icc profiles.
> >
> > - the X server runs in dom0, the apps are in AppVMs - but no
> > communication about display prifiles (colord) because of the qubes gui
> > protocol.
> >
>
> @Marek:
> Do you have any idea what to look for in order to be able to calibrate
> my screen under Qubes?

I have no idea how such software works... Especially at which stage
calibration is applied. Is it something that application does
"internally", or adjust display driver options?

> What I already tried:
>
> - the standard gnome color management tools runned in (sys-usb)
> But it is complaining that there is no display to calibrate.
>
> running the same calibration software directly complains about there is
> no colord available (masked)

Try unmasking colord (systemctl unmask should do).

> (gcm-calibrate:1459): Gcm-WARNING **: failed to connect to colord: Error
> calling StartServiceByName for org.freedesktop.ColorManager:
> GDBus.Error:org.freedesktop.systemd1.UnitMasked: Unit colord.service is
> masked.
>
>
>
> - diplayCal is happy with the dummy display seen by the AppVM, and do
> not depend on colord - but it fails on some X calls(?)
>
> Debug: window wxComboBox(0x561c58c3a230, ) lost focus even though it
> didn't have it
> X Error of failed request: BadMatch (invalid parameter attributes)
> Major opcode of failed request: 42 (X_SetInputFocus)

Strange...

> Or I should connect the calibration device to dom0 and start the
> calibration from dom0?
> (Also noted that there is no colord running, so I may have to apply the
> profile viea diplaycal cli)
>
>
> Thanks.
>
>




- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYGjA2AAoJENuP0xzK19csta0H/3gzSmBCwRg/XRsUl+R0LDLU
0BA9pOHVDYzVL4pcSeqkmV3fr1WghRaBM6x6qQ/YjNDD3UJTCqg0RlKgBg6Rb1Z2
8GKQIb8ydwH6CbFOaHjzESx7ltE3yQ/E6X2v9EgZj4XDIDA0qLRFl4M+h7TWk/Kh
e5wup2M6R7o3jPofMlZJi2F8uIp5W3wMGZWBE+4ImLWKjmXrTNNh1u4/eOOHfi3K
j3rkvqyzPmXs1j9LttHoizm2rDljKOYFe5Yj976WmXwA441ZdJFb57APWnruLRh1
Z1dJ/fKuwcmUW/Ch1cZqgIA57bv7dkcrByUUk/1bcvWBRM8OzNRx4WISQ//NyVw=
=8E8F
-----END PGP SIGNATURE-----

Zrubi

unread,
Nov 3, 2016, 7:01:22 AM11/3/16
to Marek Marczykowski-Górecki, qubes...@googlegroups.com
On 11/02/2016 07:28 PM, Marek Marczykowski-Górecki wrote:

> I have no idea how such software works... Especially at which stage
> calibration is applied.

The gonme frontend will apply the resulted profile at the end - if
started from the gnome-control-center.
It will gonna fail - as it is not even see any calibration aware device.
(but this is maybe because of the missing colord)

The other GUI (displaycal) is just create a profile, and the user has a
choice to use (apply) it from a CLI, or whatever.

> Is it something that application does
> "internally", or adjust display driver options?

Apps can use the (colord provided) profiles in our own. In the same time
it can be apply X server wise by modifying the graphics driver output
via LUT curvers.

of course that means that the later have to be done in the GUI domain -
which is currently dom0

For the best results we would need both. But in case of Qubes that would
means:
- apply the profile globally in dom0 (or GUI domain)
- provide (the same) profile in VMs via colord


The current issue is to create a profile without attaching the
calibration device to dom0.
Even the profile creating is tricky because those calibration software
may try to apply the result but at lest needs to create an app window
which is:
- always on top
- always in focus
- shown on all desktop
- prevents screen blank/lock

Those thing should be only be able to achieve by dom0 (GUI domain)
The real strange thing that it was able to pup a window with most of the
features above - but then crashed. The last error message was the result
of that crash.

The calibration itself ir really simple that window will switch colors,
and the calibrating device (placed over that window) measuring the
actual shown colors, and the "difference" goes to the resulting profile
to get correct colors when applied.

You can read a more detailed (and probably more accurate) writing about
this here:
https://displaycal.net/#concept


>> running the same calibration software directly complains about there is
>> no colord available (masked)
>
> Try unmasking colord (systemctl unmask should do).

I assumed that colord is masked for a reason by Qubes devs.
Because in a default feadora colord is up and running by default.

Will try to unmask it - but not hoping too much.



As I writing this I see no real chance to make it work without plugging
the calibration device to dom0. - but let me know if you have any idea.


--
Zrubi

signature.asc

Zrubi

unread,
Nov 3, 2016, 7:13:43 AM11/3/16
to qubes...@googlegroups.com
On 11/03/2016 12:01 PM, Zrubi wrote:

> The current issue is to create a profile without attaching the
> calibration device to dom0.
> Even the profile creating is tricky because those calibration software
> may try to apply the result but at lest needs to create an app window
> which is:
> - always on top
> - always in focus
> - shown on all desktop
> - prevents screen blank/lock

And forget to mention that it will also try to set the screen brightness
to maximum before the calibration process starts.

> Those thing should be only be able to achieve by dom0 (GUI domain)
> The real strange thing that it was able to pup a window with most of the
> features above - but then crashed. The last error message was the result
> of that crash.


--
Zrubi

signature.asc

Marek Marczykowski-Górecki

unread,
Nov 3, 2016, 2:51:39 PM11/3/16
to Zrubi, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Really is all that needed? I'd guess you need to have the window visible
during calibration only, which means it should be ok to manually switch
it to fullscreen (from titlebar menu) for that time only. As for the
brightness - is it ok to set it manually?

> Those thing should be only be able to achieve by dom0 (GUI domain)
> The real strange thing that it was able to pup a window with most of the
> features above - but then crashed. The last error message was the result
> of that crash.
>
> The calibration itself ir really simple that window will switch colors,
> and the calibrating device (placed over that window) measuring the
> actual shown colors, and the "difference" goes to the resulting profile
> to get correct colors when applied.

If the software do not need to change any video driver properties during
the process, it should be ok to run it in the VM.
Of course in practice calibration software may not like those
constrains...

> You can read a more detailed (and probably more accurate) writing about
> this here:
> https://displaycal.net/#concept
>
>
> >> running the same calibration software directly complains about there is
> >> no colord available (masked)
> >
> > Try unmasking colord (systemctl unmask should do).
>
> I assumed that colord is masked for a reason by Qubes devs.
> Because in a default feadora colord is up and running by default.

It's masked mostly to save some RAM.

> Will try to unmask it - but not hoping too much.
>
> As I writing this I see no real chance to make it work without plugging
> the calibration device to dom0. - but let me know if you have any idea.



- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYG4c5AAoJENuP0xzK19cs7wcH/AxJO4RTfX2IEE4j/cyQTX7v
E8ZbC3ED7NM+4sloTXkHodyoPTSZmmSOj4SyNeD7Feid4DC7lyPedgCOOWVks6ZD
Fy64HwfK+GImzaZXKzqxXuqmfo6TAvVZFxw0CBUQm/pXP/xTTIvULM5sb0DmH+M7
bub6Mcsfvu8fxANwcwmtr7fRUVxf3kg5dldrqHjCI2AHaaRM4gEaoeywMONlhSiI
yaR32RhDUSg6pnywlV8phueiuvXlsGAd2f4Q7XCq5oS3ZgOI+iOC+C9hgHZtEbsy
uDmb/QBUEd2Ekj/RqPSNIkcn+HSW4uNuEApMkqDwAgo03mPMagEUwPZtZ6xj2bE=
=eEgn
-----END PGP SIGNATURE-----

Achim Patzner

unread,
Nov 3, 2016, 3:30:24 PM11/3/16
to qubes...@googlegroups.com
Am 03.11.2016 um 19:51 schrieb Marek Marczykowski-Górecki:
> Really is all that needed? I'd guess you need to have the window visible
> during calibration only, which means it should be ok to manually switch
> it to fullscreen (from titlebar menu) for that time only. As for the
> brightness - is it ok to set it manually?

If you take a closer look at the W540's hand rest area you'll notice a
small camera-like device. This is a built-in colorimeter. The Windows
software coming with it is about the worst piece of "I have to ignore
all kinds of security" trash I've ever seen. It is running as "local
system" in order to control screen brightness and turn the screen
on/interdict sleep while the lid is closed in order to run. I can't
really imagine anyone really wanting to use it (considering the fact
that the Windows software is carrying about 100MB into your system,
parts of it having more privileges than Administrator – who needs that
much stuff for calculationg a color profile using specialized hardware?).

So yes, the software seems to need those rights (including modifying
screen brightness during measurement, at least in the case of Lenovo).

> Of course in practice calibration software may not like those
> constrains...

I would bet on it. Maybe Zrubi can bribe you with 5kg of assorted
chocolate to try it yourself (some years ago this
https://www.amazon.de/Toblerone-Jumbo-1er-Pack-4-5/dp/B004INT01A used to
be quite good currency to convince developers).



Achim

Zrubi

unread,
Nov 4, 2016, 5:06:59 AM11/4/16
to Marek Marczykowski-Górecki, qubes...@googlegroups.com
On 11/03/2016 07:51 PM, Marek Marczykowski-Górecki wrote:

> Really is all that needed? I'd guess you need to have the window visible
> during calibration only, which means it should be ok to manually switch
> it to fullscreen (from titlebar menu) for that time only. As for the
> brightness - is it ok to set it manually?

Theoretically yes, setting up those things manually should be enough -
but the actual software simply not designed to this case.

> If the software do not need to change any video driver properties during
> the process, it should be ok to run it in the VM.
> Of course in practice calibration software may not like those
> constrains...

Just found out that some test during an 'accurate' (long) calibration
process do want to modify (apply the half baked profile) driver settings
and checking the results, then make modification and checking it again.
Doing this till find the best results.

So calibrating from a Qubes AppVM seems to be a dead end.

(but I still in a hope for a calibrated display - it is really needed if
you want to work on photographs - like I do)

Already tried to lower the security bar and attached the device to dom0,
and run the calibration there. The software is running fine, however
applying the resulted (or any other pre definde/test) profile seems not
working as expected. (no effect seen)

Work in progress in this part....

--
Zrubi

signature.asc

Connor Page

unread,
Nov 4, 2016, 8:51:20 AM11/4/16
to qubes-users, conp...@gmail.com
On Friday, 28 October 2016 12:19:56 UTC+1, Laszlo Zrubecz wrote:
> On 09/03/2016 12:49 AM, Connor Page wrote:
> > I have calibrated my yellow screen using argyllcms.
> > I don't attach usb devices to dom0 so installed it in sys-usb as well.
> > used https://encrypted.pcode.nl/blog/2013/11/24/display-color-profiling-on-linux/ as a rough guide.
> > to get the calibration done you just need to run dispcal and then transfer the calibration file to dom0.
> > then test it with "dispwin xxx.cal" in dom0. if happy, create an autostart item with that command (probably,
> > using the full path to the calibration file) and you're done.
>
> I just started to experiment with display color correction things.
>
> I wonder how it is workig in Qubes because as far as i know:
>
> - the display profile is used only the programs are aware of icc profiles.

Some window managers do this too.


>
> - the X server runs in dom0, the apps are in AppVMs - but no
> communication about display prifiles (colord) because of the qubes gui
> protocol.

True. There's even no display object to have profile attributes, so colord is useless.


>
> > I went further and created an icc profile for use in firefox and photo software.
> If no colord is runnin in an appvm, how they apply your prifile then?
> You just manually configure all of the icc profile aware apps??
>

Yes and no. ICC profiles consist of two parts, vcgt and colour correction. vcgt is used by X server to set gamma and white point. it can be produced separately ("calibration file"), and loaded by dispwin in dom0. this corrects tint and sets midtones as you need them (gamma).
when calibration is working then you can create a colour correction matrix for the specific rendering intent you're going to use in icc aware applications. that matrix can be saved as an icc profile for vms and manually selected in apps. that profile should be used only with the calibration file that was loaded when creating the icc profile. as I use only one display and at a specific brightness setting then there's no need to change settings anymore. when re-calibration is due then files can just be overwritten with new ones.


>
> Can you please describe in more details what and how you achieved?

follow the guide I referenced above and remember to transfer the calibration file to dom0 and apply it there before proceeding. the settings in the guide are rather crude but for a first pass they're ok. if it works for you then you can try higher quality settings.
>
> Thanks.
>
>
> --
> Zrubi

Connor Page

unread,
Nov 4, 2016, 6:32:40 PM11/4/16
to qubes-users, conp...@gmail.com
On Friday, 28 October 2016 12:19:56 UTC+1, Laszlo Zrubecz wrote:

> Can you please describe in more details what and how you achieved?
>

Found this in bash history backup:

dispcal -H -y l -R
(this is to adjust the brightness to the recommended level)

dispcal -v -m -y l -q l -t 6500 -g 2.2 lenovo_6500_22
(this creates the calibration file with selected quality, white point and gamma. inspect the file, transfer it to dom0 and apply with dispwin <filename>.cal )

targen -v -d 3 -G -f 128 lenovo_6500_22
(creates a set of patches,you can change the number of patches)

dispread -v -N -H -y l -k lenovo_6500_22.cal lenovo_6500_22
(shows patches and measures them)

colprof -v -D "Lenovo Yoga 2 40% 6500K 2.2" -C "2016 CP" -q m -a G -n c lenovo_6500_22
(generates an ICC profile, try that, see if you need to tweak settings to improve it)


The Gnome calibration tool uses the same utilities as above but it doesn't know that the calibration curves don't get applied in a vm. It should work in dom0 with direct access to USB and X server though. In any case don't forget to apply the calibration file in dom0!

Hope this helps.

Manuel Amador (Rudd-O)

unread,
Nov 4, 2016, 10:04:14 PM11/4/16
to qubes...@googlegroups.com
On 11/02/2016 06:28 PM, Marek Marczykowski-Górecki wrote:
>
> > @Marek:
> > Do you have any idea what to look for in order to be able to calibrate
> > my screen under Qubes?
>
> I have no idea how such software works... Especially at which stage
> calibration is applied. Is it something that application does
> "internally", or adjust display driver options?

I believe it tweaks the gamma of the X server?

--
Rudd-O
http://rudd-o.com/

Manuel Amador (Rudd-O)

unread,
Nov 4, 2016, 10:06:29 PM11/4/16
to qubes...@googlegroups.com
Looks like we need a calibration VM!

(It would be nice if these VM operations could be included in Qubes OS.
You need to calibrate your display? An icon in the System submenu will
walk you through it! It's totally doable with Qubes RPC — but the
software needs to be written for the purpose!)

--
Rudd-O
http://rudd-o.com/

Zrubi

unread,
Nov 9, 2016, 8:08:56 AM11/9/16
to qubes...@googlegroups.com, Marek Marczykowski-Górecki
On 11/04/2016 10:06 AM, Zrubi wrote:

> Just found out that some test during an 'accurate' (long) calibration
> process do want to modify (apply the half baked profile) driver settings
> and checking the results, then make modification and checking it again.
> Doing this till find the best results.
>
> So calibrating from a Qubes AppVM seems to be a dead end.
>
> (but I still in a hope for a calibrated display - it is really needed if
> you want to work on photographs - like I do)
>
> Already tried to lower the security bar and attached the device to dom0,
> and run the calibration there. The software is running fine, however
> applying the resulted (or any other pre definde/test) profile seems not
> working as expected. (no effect seen)
>
> Work in progress in this part....
>

Connecting the calibration device directly to dom0, and installing the
required software packages (gnome-color-manager) was allow me to
calibrate my display under Qubes :)

However I got different results on different devices:
- Dell E6430:
The color manager see tha LCD panel as a color manageable device,
clibration runs fine, but - for some reason - I have to apply the color
profile manually to take it's effects.

- Lenovo T450
I do not even see the LCD panel in color manager :(
It is working on Fedora 23, 24, and RedHat 7.2 on the same device.
However I'm not sure if I was configuring something or this is a "Qubes
default" issue.

Applying the color profile is half of the job, next part is to provide
the same profile for AppVMs.
Here I'm stuck a bit because I would need to make the DUMMY display
(provided by Qubes) as a color managed device. Then I would be able to
"apply" the same profile. Here the apply only would means that colord
can provide that profile to the colord aware applications. (Firefox,
Eog, Darktable in my case)

@Marek: Any idea how to achieve this?

Without this I still getting better colors overall - but the real color
management is only achievable if the apps are using the same profile.

For now I can configure apps (at least Darktable for sure) to use my
color profile manually.


(BTW: I'm about to create a "color management in Qubes" documentation soon)


--
Zrubi


signature.asc

Connor Page

unread,
Nov 9, 2016, 12:31:33 PM11/9/16
to qubes-users
darktable and firefox can use a defined profile without colord. the profile has to be in a specific place and selected as the display profile (with colord option switched off). for firefox the full path to the profile should be entered in some property that I don't remember exactly right now but it starts with "gfx". the rendering intent and colour management mode is set there as well. those are documented by Mozilla, you need to google what those codes actually mean.

I never found the time to write my own guide but I could possibly review or contribute to yours. sorry I can't be more specific as I'm travelling without my qubes laptop now.

Zrubi

unread,
Nov 10, 2016, 6:14:31 AM11/10/16
to Connor Page, qubes-users
On 11/09/2016 06:31 PM, Connor Page wrote:
> darktable and firefox can use a defined profile without colord. the profile has to be in a specific place and selected as the display profile (with colord option switched off)

Yeah, that's what I called the "manual way".

But in general it would be more convenient to just let colord do it's work.

--
Zrubi

signature.asc

Marek Marczykowski-Górecki

unread,
Nov 10, 2016, 6:51:43 AM11/10/16
to Zrubi, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, Nov 09, 2016 at 02:08:46PM +0100, Zrubi wrote:
> Applying the color profile is half of the job, next part is to provide
> the same profile for AppVMs.
> Here I'm stuck a bit because I would need to make the DUMMY display
> (provided by Qubes) as a color managed device. Then I would be able to
> "apply" the same profile. Here the apply only would means that colord
> can provide that profile to the colord aware applications. (Firefox,
> Eog, Darktable in my case)
>
> @Marek: Any idea how to achieve this?

Maybe our dummy X driver should provide some properties/capabilities for
this? Adding some placeholder functions shouldn't be a problem (if that
would be enough) - as soon as someone would find which one.

> Without this I still getting better colors overall - but the real color
> management is only achievable if the apps are using the same profile.
>
> For now I can configure apps (at least Darktable for sure) to use my
> color profile manually.
>
>
> (BTW: I'm about to create a "color management in Qubes" documentation soon)

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYJF9LAAoJENuP0xzK19csNSwH/1hCT2HWWznuFE1iWWyuGnBZ
mHBfjhG9qCl4PKAJcQRePIO+hvqMuzwLsra7MwUrApaAJFBbTC+iAdSUbTqjKdcn
oO9Dy6rOvPwNeIbdvpcJ4KU/2rM/lZIUXH5TGRfc76prNaNywmAIDQWIJDkpdfhG
7Cf5GRd/3hP4sh1xasWaEuVc0MJ4bIvL/8hPr1bbv4XdH/Xl3wy5fWVTo4cdiCt2
KurTAlQ7pYc1iUbMYnY1Ot4y+qVGBbQtH1B+bOSeiQzjDHGf4/y2e+i4LheAK+aU
7SkowKbgwO8AGewXlZHmVE8bcQjyqA9xaehYSBabea03Ox1CiSj+X6U/kTxo/ao=
=zNH6
-----END PGP SIGNATURE-----

Connor Page

unread,
Nov 11, 2016, 1:29:39 PM11/11/16
to qubes-users
the filename of the colour profile .icc-file is stored in the X atom _ICC_PROFILE. perhaps, if that is available then the correct profile can be selected by gnome settings manager which currently says there are no colour managed devices in vms. I think colord service would need to be enabled as well. darktable should work then out of box.

Chris Laprise

unread,
Nov 11, 2016, 3:11:06 PM11/11/16
to Marek Marczykowski-Górecki, Zrubi, qubes...@googlegroups.com
On 11/10/2016 06:51 AM, Marek Marczykowski-Górecki wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Wed, Nov 09, 2016 at 02:08:46PM +0100, Zrubi wrote:
>> Applying the color profile is half of the job, next part is to provide
>> the same profile for AppVMs.
>> Here I'm stuck a bit because I would need to make the DUMMY display
>> (provided by Qubes) as a color managed device. Then I would be able to
>> "apply" the same profile. Here the apply only would means that colord
>> can provide that profile to the colord aware applications. (Firefox,
>> Eog, Darktable in my case)
>>
>> @Marek: Any idea how to achieve this?
> Maybe our dummy X driver should provide some properties/capabilities for
> this? Adding some placeholder functions shouldn't be a problem (if that
> would be enough) - as soon as someone would find which one.

>
>> Without this I still getting better colors overall - but the real color
>> management is only achievable if the apps are using the same profile.

I think this assertion should be verified before using time and
resources on this. At best, it seems like a requirement for a
rarely-needed feature. Display calibration is a hardware driver issue
and I'm using it just fine with KDE in dom0. When I print, the color
gamut and cast matches what I see in the appVM window quite well.

I also think we should avoid pushing details that identify hardware into
domUs.

No doubt, calibration for /printers/ is something to be handled in
domUs, but that's because printer drivers operate there.

Chris
Reply all
Reply to author
Forward
0 new messages