dvratil added inline comments. INLINE COMMENTS
> amantia wrote in output.cpp:583-585 > 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()`. REPOSITORY R110 KScreen Library REVISION DETAIL https://phabricator.kde.org/D17657 To: amantia, dvratil Cc: davidedmundson, plasma-devel, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
