Using kwin_wayland in a QEMU VM with virtio-gpu, the reported physical size is 0/0 as there is no EDID specified. This leads to some applications having completely broken output as the calculated logical DPI is QPair(inf,inf). If an invalid EDID is found, the physical size should be calculated using 96PPI as fallback.
Or does Qt need to change to not ignore a bad physical size and assume 96? Projectors typically have no physical size.
(In reply to David Edmundson from comment #1) > Or does Qt need to change to not ignore a bad physical size and assume 96? > Projectors typically have no physical size. X fakes the physical size of the screen itself already (except using the proprietary nvidia driver). IMO reporting a size of 0x0 is always wrong.
Interestingly Qt has a fallback path to handle platforms not handling physical size. QSizeF QPlatformScreen::physicalSize() const { static const int dpi = 100; return QSizeF(geometry().size()) / dpi * qreal(25.4); } Though our Qt wayland QPA doesn't use that as it thinks it has a physical size. I don't disagree with what you're saying, but I'm not 100% convinced either that it's right to "lie" to the applications. I'm going to email wayland-devel and get an official answer and go with that.
(In reply to David Edmundson from comment #3) > Interestingly Qt has a fallback path to handle platforms not handling > physical size. > > QSizeF QPlatformScreen::physicalSize() const > { > static const int dpi = 100; > return QSizeF(geometry().size()) / dpi * qreal(25.4); > } > > Though our Qt wayland QPA doesn't use that as it thinks it has a physical > size. > > I don't disagree with what you're saying, but I'm not 100% convinced either > that it's right to "lie" to the applications. > I'm going to email wayland-devel and get an official answer and go with that. I should add that the most severe issues were encountered with Xwayland, i.e. "kate -platform xcb". The window was just a 1px by 10px line and there were QPainter errors printed... QT_FONT_DPI=96 or Xft.dpi: 96 fixed that. In a Plasma Wayland session, QT_WAYLAND_FORCE_DPI variable is always set anyway, so there it wouldn't make any difference by default.
>I'm going to email wayland-devel and get an official answer and go with that. I did this, I got two replies saying it should be the client: https://gitlab.freedesktop.org/wayland/wayland/blob/3a05d94dc25c0e6386fa5efd27885ceb0dc48396/protocol/wayland.xml#L2463 > Xft.dpi: 96 fixed that. Which means from a Qt POV it's only logical DPI with a problem, not DPI. We should be doing that anyway. It's analogous to the QT_WAYLAND_FORCE_DPI as we have a separate scaling. At least that's means we can fix something on the plasma side without needing Qt. I shall chase up on that.
(In reply to David Edmundson from comment #5) > >I'm going to email wayland-devel and get an official answer and go with that. > > I did this, I got two replies saying it should be the client: > https://gitlab.freedesktop.org/wayland/wayland/blob/ > 3a05d94dc25c0e6386fa5efd27885ceb0dc48396/protocol/wayland.xml#L2463 > > > Xft.dpi: 96 fixed that. > > Which means from a Qt POV it's only logical DPI with a problem, not DPI. > > We should be doing that anyway. It's analogous to the QT_WAYLAND_FORCE_DPI > as we have a separate scaling. At least that's means we can fix something on > the plasma side without needing Qt. I shall chase up on that. Yes, I encountered this issue only because of a bug (which suddenly disappeared two rebuilds later) which prevented krdb from running during login. So is it expected that the X screen and monitor physical size is 0x0 in those cases? At least Xorg (except the prop. Nvidia driver) fake the physical screen (not monitor) size to result in 96dpi as it's meaningless in multi-monitor environments.
> which prevented krdb from running during login. Ah cool. So from a typical end user POV it's a non-issue? >So is it expected that the X screen and monitor physical size is 0x0 in those cases? It is certainly clarified that the wl_output should be 0 and we shouldn't change things at a wayland level. That doesn't mean xwayland couldn't do a bodge at an xwayland level. Either as a patch in xwayland, or passing an explicit -dpi 96 as an arg when we start XWayland
(In reply to David Edmundson from comment #7) > > which prevented krdb from running during login. > > Ah cool. So from a typical end user POV it's a non-issue? Unless kcm_style/krdb fails mysteriously again, yes. > >So is it expected that the X screen and monitor physical size is 0x0 in those cases? > > It is certainly clarified that the wl_output should be 0 and we shouldn't > change things at a wayland level. > > That doesn't mean xwayland couldn't do a bodge at an xwayland level. > > Either as a patch in xwayland, or passing an explicit -dpi 96 as an arg when > we start XWayland I just tried -dpi 192, didn't seem to have an effect here. So I guess a patch is necessary...
In some cases the physical size is unknown and the wayland spec says that it's okay to pass 0 physical size, I don't think that calculating a fallback dpi would be correct. Xwayland apps seem to behave well when kwin sends 0x0 physical size, and native wayland clients should handle 0 physical size. As it was pointed out above, Qt has a fallback already.