Hash: SHA256

On Thu, Nov 03, 2016 at 12:01:08PM +0100, Zrubi wrote:
> 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

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

> 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?
Version: GnuPG v2


You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to