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
Am 23.04.2013 07:49, schrieb David Herrmann:
On Apr 23, 2013 6:38 AM, "Graeme Gill" wrote:
David Herrmann wrote:
Patch 3/3 parses the blob and keeps the parsed values. Why
should we keep the binary blob, too? If we need more EDID values, we
simply extend the parser?
This would seem to impl
Hi
On Apr 23, 2013 6:38 AM, "Graeme Gill" wrote:
>
> David Herrmann wrote:
>
> > If you want to keep the EDID blob, could you describe a specific
> > use-case?
>
> Taking a hash of it to identify a particular display.
>
> Implementing specific workarounds for displays where
> the built in parser
David Herrmann wrote:
> If you want to keep the EDID blob, could you describe a specific
> use-case?
Taking a hash of it to identify a particular display.
Implementing specific workarounds for displays where
the built in parser gives up.
Dealing with extensions to the EDID standard.
> Patch 3/
---
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;
Hi
On Sat, Apr 20, 2013 at 3:31 PM, Kai-Uwe Behrmann wrote:
> Am 20.04.2013 13:12, schrieb David Herrmann:
>
>> On Fri, Apr 19, 2013 at 9:19 PM, Kai-Uwe Behrmann wrote:
>>>
>>> Am 19.04.2013 21:12, schrieb David Herrmann:
>>>
Why do you keep the blob around all the time? Just free it in
>>>
Am 20.04.2013 13:12, schrieb David Herrmann:
On Fri, Apr 19, 2013 at 9:19 PM, Kai-Uwe Behrmann wrote:
Am 19.04.2013 21:12, schrieb David Herrmann:
Why do you keep the blob around all the time? Just free it in
create_output_for_connector() after you parsed it. If we somehow need
it later, we c
Hi
On Fri, Apr 19, 2013 at 9:19 PM, Kai-Uwe Behrmann wrote:
> Am 19.04.2013 21:12, schrieb David Herrmann:
>
>
>> Why do you keep the blob around all the time? Just free it in
>> create_output_for_connector() after you parsed it. If we somehow need
>> it later, we can always change it again. But
Am 19.04.2013 21:12, schrieb David Herrmann:
Why do you keep the blob around all the time? Just free it in
create_output_for_connector() after you parsed it. If we somehow need
it later, we can always change it again. But your patches don't depend
on it being around all the time so lets just fre
Hi
On Fri, Apr 19, 2013 at 5:02 PM, Richard Hughes wrote:
> ---
> 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/composi
---
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;
11 matches
Mail list logo