On 13 January 2017 at 14:56, Florian Höch wrote:
> .. also guarantee that nothing else will be shown on that specific output
FWIW, I'd be fine just displaying a color swatch on the entire screen
with no window decorations; the only reason we use a composited window
in gnome-color-manager is so th
On 21 December 2016 at 09:14, Pekka Paalanen wrote:
> I suggest that compositors use the CMS you have spent so much time and
> effort perfecting, and you start with the assumption that they will not
> or cannot do so. Why?
I think lcms2 is fine to use; it's widely used in other projects,
tested,
On 20 December 2016 at 07:22, Graeme Gill wrote:
> Or be prepared to re-visit Wayland's fundamental design decisions
> if they turn out to be based on a false premise.
I don't think that's fair. I think Wayland is the opportunity to upset
the status quo with color management and do correctly what
On 15 January 2015 at 14:40, Olivier Fourdan wrote:
> "ocms" is taken from the container now (that was the casting error), so no
> need for the lookup from cms as we already have it.
Ohh of course, makes sense.
Signed-off-by: Richard Hughes
Pekka, can you pull this into maste
On 8 January 2015 at 14:40, Olivier Fourdan wrote:
> This is because of a cast error, the type of container should be
> "cms_output" and not "cms_colord".
Good catch!
> - ocms = g_hash_table_lookup(cms->devices, device_id);
> - if (!ocms) {
> - weston_log("colord: faile
On 13 October 2014 18:40, Niels Ole Salscheider
wrote:
> - Attach a false-color ICC profile to the surface
> +const unsigned char icc_profile[798] =
Hey, looks really good. Are you using a channel-swapped test profile?
If so, there are example profiles in
/usr/share/color/icc/colord/SwappedRedAnd
On 31 March 2014 12:13, Kai-Uwe Behrmann wrote:
> In many cases a client is not remotely able to compute per output
> regions without much information about scaling, positioning, (warping?)
To explain a little here, different outputs need different ICC
profiles (and thus a different color table)
On 31 March 2014 08:46, Pekka Paalanen wrote:
> how much data can an ICC profile be?
Printer profiles can be several megabytes in size, but display
profiles (what will be seen here) are usually in the 20-30kb size
range.
> Also, what if a client has several surfaces all with the same ICC
> profi
On 17 December 2013 08:17, Kristian Høgsberg wrote:
> We made it to Dec 16th and it's time to put out an alpha release and
> start winding down the feature work
Awesome news, but a few little typos:
http://wayland.freedesktop.org/releases.html
"""
The 1.3.91 version of Wayland and Weston was rel
On 2 December 2013 03:24, Michel Dänzer wrote:
> No colour management is fine, but a 16bpp gamma ramp (let alone an 8bpp
> palette) just doesn't look very good in 32bpp. :)
If you can tell me how to adjust the color depth of the console I can
probably rustle up a patch to just set a linear ramp a
On 13 July 2013 07:13, Kristian Høgsberg wrote:
> We have a 1.2.0 release of Wayland and Weston:
Awesome news. Builds now available for Fedora Rawhide and Fedora 19.
Richard.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lis
On 19 June 2013 03:52, John Kåre Alsaker wrote:
> Here is my current color management protocol for Wayland clients. The
> basic idea is that the compositor sends two color spaces to the
> clients.
If we back up a little first, what's the problem we're trying to solve?
* We already have the ICC p
This also fixes a compile warning when building the tarball.
---
src/cms-colord.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/cms-colord.c b/src/cms-colord.c
index af6b5fa..6056407 100644
--- a/src/cms-colord.c
+++ b/src/cms-colord.c
@@ -127,6 +127,7 @@ stati
---
src/cms-colord.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/cms-colord.c b/src/cms-colord.c
index 33f23b2..af6b5fa 100644
--- a/src/cms-colord.c
+++ b/src/cms-colord.c
@@ -478,7 +478,7 @@ colord_cms_output_destroy(gpointer data)
WL_EXPORT int
module_init(struct
\
+ cms-helper.h
+endif
endif
BUILT_SOURCES =\
diff --git a/src/cms-colord.c b/src/cms-colord.c
new file mode 100644
index 000..33f23b2
--- /dev/null
+++ b/src/cms-colord.c
@@ -0,0 +1,550 @@
+/*
+ * Copyright © 2013 Richard Hug
On 10 May 2013 18:05, Kristian Høgsberg wrote:
> With a few changes... there were a few crashers in here, some of which
> I triggered because I happen to have both eDP1 and LVDS output
> sections in my weston.ini.
Right, I didn't hit this as I only had:
[output]
name=LVDS1
icc_profile=/usr/share
.c
@@ -0,0 +1,134 @@
+/*
+ * Copyright © 2013 Richard Hughes
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and
+ * its documentation for any purpose is hereby granted without fee, provided
+ * that the above copyright notice appear in all copies and that both that
+
On 4 May 2013 00:16, Kai-Uwe Behrmann wrote:
>> +struct weston_edid_color_Yxy {
>> + double Y;
>> + double x;
>> + double y;
>> +};
> Why is the Y value set when it is all about primaries. No one will ever use
> that other than for assuming 1.0 .
I assumed a standard type would
On 3 May 2013 11:53, Pekka Paalanen wrote:
>> + o->set_gamma(o, size, red, red, red);
> Three times red? :-)
Good catch, thanks.
>> + p = calloc(sizeof(struct weston_color_profile), 1);
> Calloc arguments are swapped.
All fixed.
>> + weston_cms_destroy_profile(output->color_profile
har *make, *model, *serial_number;
+ struct weston_edid_info edid;
uint32_t subpixel;
uint32_t transform;
@@ -766,6 +768,9 @@ weston_output_update_zoom(struct weston_output *output,
uint32_t type);
void
weston_output_update_matrix(struct weston_output *output);
void
of compositor-drm since other
> backends can provide EDIDs too.
>
>
> On Thu, May 2, 2013 at 10:38 PM, Richard Hughes wrote:
>>
>> This code was originally written by Soren Sandmann
>> and was
>> found here: http://people.gnome.org/~ssp/randr/edid-parse.c
This code was originally written by Soren Sandmann and was
found here: http://people.gnome.org/~ssp/randr/edid-parse.c
The code has been in use in gnome-settings-daemon for a couple of years now and
is used to generate an Auto-EDID ICC profile if the screen has not been profiled
with a calibratio
\
screenshooter-server-protocol.h \
screenshooter-protocol.c\
diff --git a/src/cms-static.c b/src/cms-static.c
new file mode 100644
index 000..69671a3
--- /dev/null
+++ b/src/cms-static.c
@@ -0,0 +1,211 @@
+/*
+ * Copyright © 2013 Richard Hughes
+ *
+ * Permission to use, copy, m
On 2 May 2013 13:49, Kai-Uwe Behrmann wrote:
> Why will come a need for a CMS to read hardcoded names from the config file?
Well, colord won't, but not everybody wants/needs colord, e.g. on an
embedded display where a color profile is never likely to change. For
this case I've added a cms-static
In the future the CMS plugins will need to read the config file and setup a list
of hardcoded names to ICC profiles.
---
src/compositor-drm.c | 11 ---
src/compositor.c | 1 +
src/compositor.h | 1 +
3 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/src/compositor-dr
---
src/compositor-drm.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 857aeed..db4db33 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -21,6 +21,10 @@
* CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
+#
---
src/compositor-drm.c | 24
src/compositor.h | 7 +++
2 files changed, 31 insertions(+)
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index c8016cd..857aeed 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -545,6 +545,27 @@ drm_output
---
src/compositor.c | 2 ++
src/compositor.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/src/compositor.c b/src/compositor.c
index 0214eed..c1acd50 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -3076,6 +3076,7 @@ weston_output_init(struct weston_output *output, struct
weston_
---
src/compositor.c | 3 +++
src/compositor.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/src/compositor.c b/src/compositor.c
index 693df2c..0214eed 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -2906,6 +2906,8 @@ weston_output_destroy(struct weston_output *output)
{
On 30 April 2013 16:37, Rob Bradford wrote:
> I'm not sure whether libunique will ever lose it's X calls. The project
> is long dead and has been replaced by GApplication/GtkApplication.
Agreed. Midori needs to port to GApplication or loose the libunique dep.
Richard.
___
olord.c
@@ -0,0 +1,440 @@
+/*
+ * Copyright © 2013 Richard Hughes
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and
+ * its documentation for any purpose is hereby granted without fee, provided
+ * that the above copyright notice appear in all copies and that both th
r-protocol.h \
diff --git a/src/cms.c b/src/cms.c
new file mode 100644
index 000..1acc680
--- /dev/null
+++ b/src/cms.c
@@ -0,0 +1,106 @@
+/*
+ * Copyright © 2013 Richard Hughes
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and
+ * its documentation
At the moment we're only extracting interesting strings. We have to be quite
careful parsing the EDID data, as vendors like to do insane things.
The original EDID parsing code was written by me for gnome-color-manager.
---
src/compositor-drm.c | 149 +++
will allow us to do per-output color transforms
to automatically convert from a defined color space to the output space.
All suggestions and recommendations have been implemented from past reviews.
Richard Hughes (3):
Extract and parse the EDID when outputs are added
Add initial color
On 24 April 2013 12:42, Emilio Pozuelo Monfort wrote:
> This is exposed in the weston SDK (compositor.h is a public header). This
> patch
> breaks the ABI, but I don't think we have promised to keep it stable for now.
I didn't know we offered any king of ABI/API stability in Weston. If
we do, we
On 23 April 2013 16:37, Rob Bradford wrote:
> When I read the commit message I wondered "why does he need a serial"
> for the wl_output. I was of course thinking about the wayland use of
> "serial" as a sequence number.
Ooops, my bad.
> Are you intending to expose this through the wayland protoc
On 23 Apr 2013 16:36, "Rob Bradford" wrote:
> Please can you clarify what I think this statement implies. That is that
> you are certifying that you have the rights to license this code under
> the MIT license as carried by Weston.
Correct, i.e. I read the VESA EDID specification document. :)
Ric
On 23 April 2013 08:32, Kai-Uwe Behrmann wrote:
> Client side parsing is a different issue indeed. However the patch author
> mentioned in the initial post GNOME CMS alias colord as a plugin inside the
> Weston CMS. So other possible CMS plugins like Argyll and Oyranos have
> different requirement
At the moment we're only extracting interesting strings. We have to be quite
careful parsing the EDID data, as vendors like to do insane things.
The original EDID parsing code was written by me for gnome-color-manager.
---
src/compositor-drm.c | 166 +++
---
src/compositor-drm.c | 1 +
src/compositor.h | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 61ef97e..a454676 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -1522,6 +1522,7 @@ create_output_for_connect
---
src/compositor-drm.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index da1ba79..61ef97e 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -139,6 +139,7 @@ struct drm_output {
int pipe;
At the moment we're only extracting interesting strings. We have to be quite
careful parsing the EDID data, as vendors like to do insane things.
The original EDID parsing code was written by me for gnome-color-manager.
---
src/compositor-drm.c | 139 +++
At the moment we're only extracting interesting strings. We have to be quite
careful parsing the EDID data, as vendors like to do insane things.
The original EDID parsing code was written by me for gnome-color-manager.
Richard Hughes (1):
Extract and parse the EDID when outputs are added
At the moment we're only extracting interesting strings. We have to be quite
careful parsing the EDID data, as vendors like to do insane things.
The original EDID parsing code was written by me for gnome-color-manager.
---
src/compositor-drm.c | 166 +++
---
src/compositor-drm.c | 1 +
src/compositor.h | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 61ef97e..a454676 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -1522,6 +1522,7 @@ create_output_for_connect
---
src/compositor-drm.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index da1ba79..61ef97e 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -139,6 +139,7 @@ struct drm_output {
int pipe;
e on the other. They probably need
detailed review for correctness/coding style as this is code ported
from GNOME.
Comments welcome, thanks.
(resending, as Jonas didn't want attachments)
Richard Hughes (3):
Extract the EDID blob when adding a DRM output
Add a 'serial' property on
At the moment weston doesn't know anything about EDID blobs. To make
the CMS functionality complete we have to tell the CM the display
attributes, e.g. make, model and serial. This allows us to show
something nice in the calibration UI, and also allows us to match a
specific _display_ to the color
On 16 April 2013 04:28, Kristian Høgsberg wrote:
> I'll send out an update tomorrow with plans, ideas and schedule for
> the 1.2 release, but for now I just want to get the 1.1 tarballs out
> there.
In case anyone finds this useful, I've built this for Fedora Rawhide
and as an update to Fedora 19
I've rebased my cms patches from 1.0.6 to master/1.1.0. Two patches
attached. I've been testing them using gnome-color-manager, but you
can equally do something like:
colormgr device-add-profile
/org/freedesktop/ColorManager/devices/weston_drm_0
/org/freedesktop/ColorManager/profiles/icc_4b416c56c
On 5 April 2013 20:23, Thomas Daede wrote:
> Color correction is most important for artists doing work in something
> like the GIMP. Programs like this (as of GIMP 3.0, at least) generally
> work in higher bit depths
For GIMP I was going to just allow the app to opt-out a sub-surface
from any kin
On 5 April 2013 09:53, Richard Hughes wrote:
> * GLib really wants to return all signals (colord_device_changed_cb)
> on the main thread, not on the thread that's running the loop.
As discussed on IRC, it seems I was wrong. I've attached both patches
(v6) for review. I've
On 4 April 2013 17:11, John Kåre Alsaker wrote:
> You should remove the destroy and user_data fields from weston_color_profile.
Fixed.
> weston_cms_create_profile and weston_cms_load_profile should just
> return a pointer to weston_color_profile.
Fixed.
> Plugins should just exit if compositor
On 4 April 2013 21:30, Matthias Clasen wrote:
> Just ftr (and without actually looking at the patch): glib signals
> don't need an event loop, they're entirely synchronous.
Right, but in this case the event is coming from the GDBus thread,
which I assume is g_idle_add'ing the signal it back to th
On 4 April 2013 19:52, Bill Spitzak wrote:
> These gamma ramps are an attempt to simulate a color conversion from some
> color space (sRGB?) to the color space of the output device.
Not really, the gamma ramps just affect the gamma response and the
display whitepoint. You can't do color gamut map
On 4 April 2013 19:08, Bill Spitzak wrote:
> Are clients supposed to tell the compositor what color space their buffer
> is, and the compositor then converts to the output's color space as part of
> the compositing step?
At the moment I'm just implementing the calibration state setting,
i.e. sett
On 4 April 2013 19:21, Kai-Uwe Behrmann wrote:
> Parsing of ICC profiles inside weston is not nice. That would be better
> abstracted out to lay inside the CMS plugins. Those CMS plugins can link
> against lcms or whatever CMM they prefere.
Well, we could certainly add some abstraction to get 3 a
On 4 April 2013 07:58, John Kåre Alsaker wrote:
> The weston_color_manager struct could lose the state field
All fixed in the newest patchset, thanks for your detailed review.
> I don't see a GLib event loop, so I'm curious to how the signals work.
As discussed on IRC, I've used a thread fo
I've attached three patches for comments and review. I'm a GLib
programmer at heart, so please be kind if I've made huge obvious
architectural mistakes :)
Patch 1 adds the framework code, patch 2 adds the ability to load CMS
modules, and patch 3 adds a CMS module written for colord. With those
thr
On 3 April 2013 13:56, Graeme Gill wrote:
> A callback makes sense if this is essentially event driven. How is the
> responder (ie. CMM) registered ?
At the moment I've just got a:
[core]
cms=colord.so
in weston.ini with the .so object setting vfuncs of a
weston_color_manager struct. It's all v
On 2 April 2013 02:42, Kristian Høgsberg wrote:
> So for something like weston, where we store our configuration in
> weston.ini, I'd expect that we add a config key to set the gamma (is
> this just a number like what xgamma takes? or one for red, green and
> blue?) per output in weston.ini. So w
On 2 April 2013 12:10, Kai-Uwe Behrmann wrote:
> Querying a CMM for a monitor profile is top down. Most people understand a
> CMM (Colour Matching Modul) to do context preparation
Right, sorry for being unclear. In this instance I was referring to a
CMM being Oyranos or colord. I myself tried to
On 2 April 2013 12:10, Kai-Uwe Behrmann wrote:
> Am 02.04.2013 11:24, schrieb Richard Hughes:
>
>> On 2 April 2013 06:45, Graeme Gill wrote:
>>>
>>> The display's ICC profile will also be stored in the _ICC_PROFILE atom,
>>> to make it available
On 2 April 2013 11:11, John Kåre Alsaker wrote:
> My planned approach was to make colord and Oyranos plugins for Weston.
Sure, I'd be really keen on helping with this. Is there any
documentation on the plugin interface? Also, bear in mind I'm keeping
half and eye on the "full fat" gnome-shell imp
On 2 April 2013 06:45, Graeme Gill wrote:
> The display's ICC profile will also be stored in the _ICC_PROFILE atom,
> to make it available to the display client, so that color can be adjusted
> appropriately for that display. Using XRandR it will/should
> also be set in an output property.
There'
On 2 April 2013 02:42, Kristian Høgsberg wrote:
> All the KMS interactions happens in src/compositor-drm.c. As you say,
> the end result should be calling drmModeCrtcSetGamma(), but what's the
> input?
The user selected ICC profile which contain the gamma curves.
> We don't have protocol for c
krh mentioned in a G+ post that I should add to weston functionality
to set the output gamma ramps for color calibration. Does anyone have
any ideas on where I should start? I'm familiar with color stuff, but
the Weston internals confuse me somewhat. I need to be a position
where I can call drmMode
Currently in GNOME we set the display calibration state using
XRRSetCrtcGamma. This allows us to do a 2D lookup and correct the
device gamma and optionally change the native display temperature. I'm
wondering how we should be doing this using wayland / weston. I
appreciate we'll be doing the advanc
On 5 December 2012 14:32, Pekka Paalanen wrote:
> One of the most important use cases is a video player in a window. It
> has XRGB or ARGB window decorations, usually the video content in YUV,
> and possibly an ARGB overlay for subtitles etc. Currently, the client
> has to color-convert the video,
69 matches
Mail list logo
