[wayland] Treat monitor physical width/height of 0 as invalid

[j-piecuch]

Description

This change prevents Kodi from using a physical size of the output where one of the dimensions is 0. Otherwise, we risk dividing by 0 e.g. in COutput::GetPixelRatioForMode().

Motivation and context

On my laptop, KWin reports the physical size of the built-in display as 790x0 mm. Kodi currently accepts such dimensions (it only checks for negative values) and it must lead to some bogus calculations down the road, as evidenced by corrupted rendering of images (see screenshot). The screenshot comes from my distro's Kodi package -- when I build Kodi myself (debug and release), it immediately crashes on a failed assertion (see below).

How has this been tested?

Without this PR, both debug and release builds of both master and Omega branches crash on a failed assertion:

kodi.bin: /home/kuba/projects/xbmc/xbmc/utils/MathUtils.h:68: int MathUtils::round_int(double): Assertion `x > static_cast<double>((int) (INT_MIN / 2)) - 1.0' failed.
zsh: IOT instruction (core dumped)  ./kodi.bin

With this PR, both debug and release builds of both master and Omega branches no longer crash due to the assertion and don't show the glitches.

What is the effect on users?

This change affects users whose Wayland compositor reports a monitor physical size with exactly 1 dimension equal to 0. For those users, this change should reduce rendering artifacts.

Screenshots (if appropriate):

Types of change

• Bug fix (non-breaking change which fixes an issue)
• Clean up (non-breaking change which removes non-working, unmaintained functionality)
• Improvement (non-breaking change which improves existing functionality)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that will cause existing functionality to change)
• Cosmetic change (non-breaking change that doesn't touch code)
• Student submission (PR was done for educational purposes and will be treated as such)
• None of the above (please explain below)

Checklist:

• My code follows the Code Guidelines of this project
• My change requires a change to the documentation, either Doxygen or wiki
• I have updated the documentation accordingly
• I have read the Contributing document
• I have added tests to cover my change
• All new and existing tests passed

[neo1973]

Sounds correct to me 👍

[fritsch]

Does this work for your video output? E.g. the fallback in place most likely assumes square pixels, right?
If not -> you could also set it to width x height, which would end up with square pixels also.

[j-piecuch]

Does this work for your video output?

Yes, this works for my laptop's built-in monitor (if that's what you mean).

E.g. the fallback in place most likely assumes square pixels, right?

There is no fallback for the physical size - each user of the physical size must handle the case where the size is empty, see COutput::GetDpiForMode() and COutput::GetPixelRatioForMode().
We could leverage the assumptions made by the above functions (i.e. square pixels and DPI of 96) to compute a fallback physical size, with the caveat that it would depend on the current resolution, unless we use the maximum resolution somehow.

If not -> you could also set it to width x height, which would end up with square pixels also.

Almost - you also need to take the default DPI of 96 into account.