HDMI 1.3 has a standard optional way for display devices such as TVs to signal back the input latency through EDID called "auto-lip-sync". This is intended for A/V receivers that pass through the video to the TV but play back the audio to adjust the audio playback delay to match the delay of the TV, as TVs tend to have several frames of input latency. Apparently HDMI 2.0 introduces an additional dynamic way to signal latency which does not use EDID. By exposing this in kscreen, applications could determine the approximate input latency of the screen they're currently running on, and adjust their audio delay accordingly if the audio isn't already being adjusted by the playback setup. Other uses could include games asking the user to change their TV setting if the reported latency is very high, or accurate syncing of external ambient lighting to video playback. This has very little real-world usability right this moment, but could come in handy for multimedia people to tinker with.
KScreen is not a framework or applications to receive screen information, it's a tool for screen setup. We've actually moved several applications away from using kscreen because we don't want to concentrate kscreen on these use-cases, but make the case of setting up screens better. While libsync may be useful to applications, kscreen would be the wrong tool for the job, apps that need it (and there's I think zero overal with kscreen's current users) would be better of querying the HDMI interface directly. I value the suggestions, and I don't want to dismiss is, but it wouldn't make kscreen better to add this here.