Re: [PATCH 2/2] Move the EDID parsing to its own file
Graeme Gill wrote: Bill Spitzak wrote: The Y of the primaries can be used as alternative method of specifying the whitepoint. (convert the 3 Yxy colors to XYZ, add them, then convert back to Yxy and the xy is the whitepoint, I think). Correct, but this assumes the display is perfectly additive. Real world ones mightn't be, so Yxy or XYZ x RGBW does provide extra information. I suppose that is possible if the primaries and whitepoint were all Yxy triples, because that provides 12 degrees of freedom. However I have always seen them specified as xy pairs thus giving 8 degrees of freedom, which is less than the 9 degrees of freedom from three Yxy triples. Also non-additiveness is usually considered a second step after conversion to additive primaries. I have doubts it can be specified by just one extra point in the color space. I think the reason rgb sets are specfied as 4 pairs of xy (the three primaries and the whitepoint) instead of 3 triples is to remove the arbitrary multiplier that makes there be 9 numbers instead of 8. A lot of display folk are very chromaticity diagram oriented - they are used to just specifying xy, and it's nice to have the white point be explicit so you can more easily check what the white point color temperature is. xy of the whitepoint does define the color temperature. Possibly you are thinking of X and Z? ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 2/2] Move the EDID parsing to its own file
Bill Spitzak wrote: > The Y of the primaries can be used as alternative method of specifying the > whitepoint. (convert the > 3 Yxy colors to XYZ, add them, then convert back to Yxy and the xy is the > whitepoint, I think). Correct, but this assumes the display is perfectly additive. Real world ones mightn't be, so Yxy or XYZ x RGBW does provide extra information. > I think the reason rgb sets are specfied as 4 pairs of xy (the three > primaries and the whitepoint) > instead of 3 triples is to remove the arbitrary multiplier that makes there > be 9 numbers instead of 8. A lot of display folk are very chromaticity diagram oriented - they are used to just specifying xy, and it's nice to have the white point be explicit so you can more easily check what the white point color temperature is. Graeme Gill. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 2/2] Move the EDID parsing to its own file
The Y of the primaries can be used as alternative method of specifying
the whitepoint. (convert the 3 Yxy colors to XYZ, add them, then convert
back to Yxy and the xy is the whitepoint, I think).
I think the reason rgb sets are specfied as 4 pairs of xy (the three
primaries and the whitepoint) instead of 3 triples is to remove the
arbitrary multiplier that makes there be 9 numbers instead of 8.
Richard Hughes wrote:
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 be more useful than a custom type. If
it stays as Yxy, then colord can use it without having to do a:
var2->Y = 1.0;
var2->x = var1->x;
var2->y = var1->y;
...every time.
Richard
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 2/2] Move the EDID parsing to its own file
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 be more useful than a custom type. If
it stays as Yxy, then colord can use it without having to do a:
var2->Y = 1.0;
var2->x = var1->x;
var2->y = var1->y;
...every time.
Richard
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 2/2] Move the EDID parsing to its own file
Am 02.05.2013 23:33, schrieb Richard Hughes:
---
src/Makefile.am | 2 +
src/compositor-drm.c | 180 +--
src/compositor.c | 21 ++
src/compositor.h | 5 ++
src/edid.c | 175 +
src/edid.h | 48 ++
6 files changed, 254 insertions(+), 177 deletions(-)
create mode 100644 src/edid.c
create mode 100644 src/edid.h
+ /* get primaries and whitepoint */
+ edid->primary_red.Y = 1.0f;
+ edid->primary_red.x = edid_decode_fraction(data[0x1b],
edid_get_bits(data[0x19], 6, 7));
+ edid->primary_red.y = edid_decode_fraction(data[0x1c],
edid_get_bits(data[0x19], 5, 4));
+ edid->primary_green.Y = 1.0f;
+ edid->primary_green.x = edid_decode_fraction(data[0x1d],
edid_get_bits(data[0x19], 2, 3));
+ edid->primary_green.y = edid_decode_fraction(data[0x1e],
edid_get_bits(data[0x19], 0, 1));
+ edid->primary_blue.Y = 1.0f;
+ edid->primary_blue.x = edid_decode_fraction(data[0x1f],
edid_get_bits(data[0x1a], 6, 7));
+ edid->primary_blue.y = edid_decode_fraction(data[0x20],
edid_get_bits(data[0x1a], 4, 5));
+ edid->whitepoint.Y = 1.0f;
+ edid->whitepoint.x = edid_decode_fraction(data[0x21],
edid_get_bits(data[0x1a], 2, 3));
+ edid->whitepoint.y = edid_decode_fraction(data[0x22],
edid_get_bits(data[0x1a], 0, 1));
+
+#ifndef _WESTON_EDID_H_
+#define _WESTON_EDID_H_
+
+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 .
kind regards
Kai-Uwe
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 2/2] Move the EDID parsing to its own file
---
src/Makefile.am | 2 +
src/compositor-drm.c | 180 +--
src/compositor.c | 21 ++
src/compositor.h | 5 ++
src/edid.c | 175 +
src/edid.h | 48 ++
6 files changed, 254 insertions(+), 177 deletions(-)
create mode 100644 src/edid.c
create mode 100644 src/edid.h
diff --git a/src/Makefile.am b/src/Makefile.am
index d33ebc5..1e8965c 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -18,6 +18,8 @@ weston_SOURCES = \
log.c \
compositor.c\
compositor.h\
+ edid.c \
+ edid.h \
filter.c\
filter.h\
screenshooter.c \
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index e4a1919..c507e72 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -29,7 +29,6 @@
#include
#include
-#include
#include
#include
#include
@@ -136,24 +135,6 @@ struct drm_fb {
void *map;
};
-struct drm_color_Yxy {
- double Y;
- double x;
- double y;
-};
-
-struct drm_edid {
- char eisa_id[13];
- char monitor_name[13];
- char pnp_id[5];
- char serial_number[13];
- struct drm_color_Yxy whitepoint;
- struct drm_color_Yxy primary_red;
- struct drm_color_Yxy primary_green;
- struct drm_color_Yxy primary_blue;
- double gamma;
-};
-
struct drm_output {
struct weston_output base;
@@ -161,7 +142,6 @@ struct drm_output {
int pipe;
uint32_t connector_id;
drmModeCrtcPtr original_crtc;
- struct drm_edid edid;
int vblank_pending;
int page_flip_pending;
@@ -1529,146 +1509,6 @@ drm_output_fini_pixman(struct drm_output *output)
}
static void
-edid_parse_string(const uint8_t *data, char text[])
-{
- int i;
- int replaced = 0;
-
- /* this is always 12 bytes, but we can't guarantee it's null
-* terminated or not junk. */
- strncpy(text, (const char *) data, 12);
-
- /* remove insane chars */
- for (i = 0; text[i] != '\0'; i++) {
- if (text[i] == '\n' ||
- text[i] == '\r') {
- text[i] = '\0';
- break;
- }
- }
-
- /* ensure string is printable */
- for (i = 0; text[i] != '\0'; i++) {
- if (!isprint(text[i])) {
- text[i] = '-';
- replaced++;
- }
- }
-
- /* if the string is random junk, ignore the string */
- if (replaced > 4)
- text[0] = '\0';
-}
-
-#define EDID_DESCRIPTOR_ALPHANUMERIC_DATA_STRING 0xfe
-#define EDID_DESCRIPTOR_DISPLAY_PRODUCT_NAME 0xfc
-#define EDID_DESCRIPTOR_DISPLAY_PRODUCT_SERIAL_NUMBER 0xff
-#define EDID_OFFSET_DATA_BLOCKS0x36
-#define EDID_OFFSET_LAST_BLOCK 0x6c
-#define EDID_OFFSET_PNPID 0x08
-#define EDID_OFFSET_SERIAL 0x0c
-
-static int
-edid_get_bit(int in, int bit)
-{
- return (in & (1 << bit)) >> bit;
-}
-
-static int
-edid_get_bits(int in, int begin, int end)
-{
- int mask = (1 << (end - begin + 1)) - 1;
- return (in >> begin) & mask;
-}
-
-static double
-edid_decode_fraction(int high, int low)
-{
- double result = 0.0;
- int i;
-
- high = (high << 2) | low;
- for (i = 0; i < 10; ++i)
- result += edid_get_bit(high, i) * pow(2, i - 10);
- return result;
-}
-
-static int
-edid_parse(struct drm_edid *edid, const uint8_t *data, size_t length)
-{
- int i;
- uint32_t serial_number;
-
- /* check header */
- if (length < 128)
- return -1;
- if (data[0] != 0x00 || data[1] != 0xff)
- return -1;
-
- /* decode the PNP ID from three 5 bit words packed into 2 bytes
-* /--08--\/--09--\
-* 7654321076543210
-* |\---/\---/\---/
-* R C1 C2 C3 */
- edid->pnp_id[0] = 'A' + ((data[EDID_OFFSET_PNPID + 0] & 0x7c) / 4) - 1;
- edid->pnp_id[1] = 'A' + ((data[EDID_OFFSET_PNPID + 0] & 0x3) * 8) +
((data[EDID_OFFSET_PNPID + 1] & 0xe0) / 32) - 1;
- edid->pnp_id[2] = 'A' + (data[EDID_OFFSET_PNPID + 1] & 0x1f) - 1;
- edid->pnp_id[3] = '\0';
-
- /* get native gamma */
- if (data[0x17] == 0xff)
- edid->gamma = -1.0;
- else
- edid->gamma = (data[0x17] + 100.0) / 100.0;
-
- /* get primaries and whitepoint */
- edid->primary_red.Y = 1.0f;
- edid->primary_red.x = edid_decode_fraction(data[0x1b],
