https://bugs.kde.org/show_bug.cgi?id=416201
--- Comment #6 from Fabian Vogt <fab...@ritter-vogt.de> --- (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. -- You are receiving this mail because: You are watching all bug changes.
