unity-settings-daemon crashes on start with SIGABRT if xrandr provides two displays with the same name

-- Symptoms --

I am experiencing this bug after a recent upgrade to Ubuntu 16.04, with unity-settings-daemon 15.04.1+16.04.20160209.

unity-settings-daemon always fails to start (leaving me with a quasi-functional desktop); when run from a command-line, it simply outputs:

    **
    ERROR:gsd-rr-config.c:661:gsd_rr_config_load_current: assertion failed: (gsd_rr_config_match (config, config))
    Aborted

and crashes with SIGABRT. This is 100% reproducible on my system.

I have investigated the cause of this crash, and I can provide a patch that solves this bug. I do not know whether I shall help fixing this bug here, or if should I work with the upstream directly, a word of advice in this matter would be very appreciated.

-- Bug analysis and proposed solution --

The mentioned assertion fails even though it compares the same configuration with itself. What gsd_rr_config_match does internally is that it takes each output from a configuration one by one, and searches - by name - for a matching output in the other config. If the search fails, or the found output does not match the one from first config, the gsd_rr_config_match check fails.

Because of that, this check should never fail when comparing a configuration to itself, with the exception of one (presumably rare) care. It happens that, for my multi-monitor setup, libxrandr reports that there are two different outputs that share the same name "DP-1". In this case, the gsd_rr_config_match fails, because when searching for a matching output named "DP-1", it will return the same output both times, and therefore one pair will be not matching (the find_output function returns the first output that matches requested name).

Therefore it appears that comparing configurations by checking whether outputs with matching names are equivalent may be wrong, because the output names are not guaranteed to be unique. I propose to modify both configuration comparing procedures (gsd_rr_config_match and gsd_rr_config_equal) so that they compare outputs matching them by their ids, which will always be unique due to their nature. Since the find_output function (which takes an output name as an argument) is only used by these two comparing functions, it makes sense to modify it so that it takes an output id as an argument instead.

This is a valid solution, because in this case even if output names happen to repeat, the output ids will be used to distinguish between them, and gsd_rr_config_match will no longer incorrectly fail. Also, the proposed change will never cause a configuration comparing function to return true where it would otherwise not, because each two outputs with a different name will always have a different id as well.

I attach to this bug report a patch that implements the proposed changes. Applying this patch entirely fixed the described symptoms on my machine.