Identifying specific monitors by their EDID about grobi

[fd0]

Nice idea, I also have it on my TODO list.

[He-Ro]

I actually have started to work on it in my fork https://github.com/He-Ro/grobi/tree/add-edid it currently extracts the information and stores it. Now I am looking to change the yaml config parsing, which seems to be a little more involved than I thought because of downwards compatability. My current idea is to replace the simple strings with dictionaries so the following config

rules:
  - name: Desktop
    outputs_connected: [HDMI2, eDP1]

could become

rules:
  - name: Desktop
    outputs_connected:
      - name: HDMI2
        edid: 00ffffff…
      - eDP1

But now the elements in the outputs_connected list can either be a dictionary or a string, for which I need to implement a custom Unmarshaler. Will have a look at it next week.

[fd0]

I'd recommend extracting the relevant infos from the EDID (really easy to do), display manufacturer, model, serial number. https://en.wikipedia.org/wiki/Extended_Display_Identification_Data#Enhanced_EDID_.28E-EDID.29

The EDID is also exposed via sysfs: find /sys/devices/ -name edid

Most is just ASCII text, you can check with xxd.

[He-Ro]

My internal laptop monitor's edid looks like this:

00000000: 00ff ffff ffff ff00 0dae b114 0000 0000  ................
00000010: 0c19 0104 951f 1178 02ff 3592 5552 9529  .......x..5.UR.)
00000020: 2550 5400 0000 0101 0101 0101 0101 0101  %PT.............
00000030: 0101 0101 0101 b43b 804a 7138 3440 503c  .......;.Jq84@P<
00000040: 6800 34ad 1000 0018 0000 00fe 004e 3134  h.4..........N14
00000050: 3048 4345 2d45 4141 0a20 0000 00fe 0043  0HCE-EAA. .....C
00000060: 4d4e 0a20 2020 2020 2020 2020 0000 00fe  MN.         ....
00000070: 004e 3134 3048 4345 2d45 4141 0a20 00a2  .N140HCE-EAA. ..

As a user I would not know which part of it is the serial number and which part the manufacturer.
So my question is, how would the user be supposed to know these values to put them into his or her config? Or are there already tools to display them?
I used the whole edid, because in my mind it is easier to obtain for a user, e.g. with xrandr --props.
Another possible way could be, that grobi reports these values (manufacturer, serial number, …) and the user can copy them from there.

So that is my reasoning for using the whole edid. If you still like the separation more, then I can implement that, but I would first like to understand how the user obtains that information in order to use it in his or her configuration file.

[fd0]

Hm, I'd rather have grobi print the EDID information in the correct format.

FYI: I'd also like to replace the hard to use YAML config with something better, e.g. HCL.

[He-Ro]

In HCL you want to use their Parse method and iterate over the generated parse tree, do I understand that correctly? Otherwise using Unmarshal again does not solve the problem of different possible values.

Thinking about it again, as this is a breaking change anyway one could just introduce the new format completely and then it should be possible to use Unmarshal again.

I will play around with it and report back.

[fd0]

That's one possibility, the other is to use https://github.com/mitchellh/mapstructure

I find these articles helpful, although I did not find the time yet to play around with HCL:
http://jen20.com/2015/09/07/using-hcl-part-1.html
http://jen20.com/2015/09/08/using-hcl-part-2.html

[fd0]

FYI, I've switched the repo to the idiomatic Go repo layout, and ditched gb.