isn't that what this is doing?

Good point, missed it. @dvratil any reason why it emits outputChanged and not modesChanged? Actually setModes emits both, so maybe indeed it is easier to just put modesChnaged there as well. I'm still curious why we need both.

There are properties that are related to the overall output state and will never change individually (e.g. id, type, name). Technically modes /may/ change independently of the output (it is possible to add modes in XRandR), but historically we did not support that, so modes were always coupled with the output state as well. I think this is the correct approach to fix a bug, but longterm someone should probably look into what happens when the outputChanged() signal is removed from here and from setModes() as there might be some code listening to it instead of modesChanged().