Created attachment 134510 [details]
Xfce start menu rendered wrong on the affected machine

Created attachment 134511 [details]
Xfce start menu rendered right on one of my other machines

Created attachment 134512 [details]
KeepassXC scaled wrong on the affected machine

Created attachment 134513 [details]
KeepassXC scaled right on one of my other machines

Created attachment 134514 [details]
qTox scaled wrong on the affected machine

I doubt this is a driver issue, have you tried adjusting the DPI setting in xfce settings tool?

Yes, I have. This is one of the first things I tried to fix the problem. But it makes no sense to me that this could be the problem as only qTox is affected now. KeepassXC used to be, but after a while it wasn't anymore, without me doing anything special.

I also thought some files might be corrupted. But I recently moved the arch linux install on the affected machine (all my machines are running up to date arch linux) to a new hard drive and the Qt, qTox and KeepassXC packages have all been upgraded a few times since so I'm pretty sure if somehow there were corrupted files they should all have been overwritten by now. I moved the install from a true hardware RAID-1 array that did not fail which makes it also pretty unlikely there were bad sectors or something anyway.

Yes, I have. This is one of the first things I tried to fix the problem. But it makes no sense to me that this could be the problem as only qTox is affected now. KeepassXC used to be, but after a while it wasn't anymore, without me doing anything special.

I also thought some files might be corrupted. But I recently moved the arch linux install on the affected machine (all my machines are running up to date arch linux) to a new hard drive and the Qt, qTox and KeepassXC packages have all been upgraded a few times since so I'm pretty sure if somehow there were corrupted files they should all have been overwritten by now. I moved the install from a true hardware RAID-1 array that did not fail which makes it also pretty unlikely there were bad sectors or something anyway.

Please attach the Xorg log file and the output of xrandr. At least from the affected machine, optionally also from an unaffected one.

Created attachment 134530 [details]
Xorg log on the affected machine

Created attachment 134531 [details]
Xorg log of an unnaffected machine

Created attachment 134532 [details]
xrandr output on the affected machine

Created attachment 134533 [details]
xrandr output on the same unaffected machine

I also tried to swap the system RAM modules in different slots on the motherboard in case there is something wrong with one of the RAM modules but that did not change anything. But maybe that does nothing anyway because of ASLR.

attachment 134531 [details] (aka "unaffected machine")

[    25.049] (II) RADEON(0): Setting screen physical size to 869 x 285

attachment 134530 [details] (aka "affected machine")

[    29.662] (II) Quirked EDID physical size to 0x0 cm
                                                ^^^
That might affect DPI computation, no?

It looks like the monitor connected to the HDMI-0 output doesn't accurately report its display size, resulting in about ~300 DPI being reported via RandR. The Xorg radeon driver isn't actively involved in how clients / toolkits adjust their rendering according to this (or even in how it's reported to them).

I just plugged the affected machine on the monitor of the unaffected machine, and qTox is scaled like it should. So I guess the monitor (Samsung P2770HD) has issues with it's EDID. Should I go file a bug report somewhere so a workaround be added for this monitor? However the start menu icon is still rendered incorrectly, so it's a separate issue.

(In reply to Deposite Pirate from comment #17)
> So I guess the monitor (Samsung P2770HD) has issues with it's EDID. Should I go
> file a bug report somewhere so a workaround be added for this monitor?

I guess a quirk would have to be somewhere in the X server. Reassigning to RandR for now.


> However the start menu icon is still rendered incorrectly, so it's a separate
> issue.

Please file a separate report about that.

(In reply to Michel Dänzer from comment #18)
> I guess a quirk would have to be somewhere in the X server. Reassigning to
> RandR for now.

I saw the Linux kernel has some EDID quirks for various monitors defined in "drivers/gpu/drm/drm_edid.c" and it seems there's some monitors that have the same problem in there. The thing is, I don't know if the P2770HD just reports no physical size at all or if it reports it in a format that Xorg doesn't expect (i.e. cm instead of mm as there are quirks for that kind of thing in the aforementioned linux kernel source file). I downloaded some tools to read the EDID and it seems the DisplaySize is wrong as the P2770HD's manual says it's "597.89 mm (H) X 336.31 mm(V)"
 (https://www.manualslib.com/manual/201704/Samsung-Syncmaster-P2770hd.html?page=65#manual).

---
$ sudo parse-edid < edid 
Checksum Correct

Section "Monitor"
	Identifier "SyncMaster"
	ModelName "SyncMaster"
	VendorName "SAM"
	# Monitor Manufactured week 31 of 2009
	# EDID version 1.3
	# Digital Display
	DisplaySize 160 90
	Gamma 2.20
	Option "DPMS" "false"
	Horizsync 26-81
	VertRefresh 24-75
	# Maximum pixel clock is 230MHz
	#Not giving standard mode: 1152x864, 75Hz
	#Not giving standard mode: 1280x800, 60Hz
	#Not giving standard mode: 1280x960, 60Hz
	#Not giving standard mode: 1280x1024, 60Hz
	#Not giving standard mode: 1440x900, 60Hz
	#Not giving standard mode: 1440x900, 75Hz
	#Not giving standard mode: 1600x1200, 60Hz
	#Not giving standard mode: 1680x1050, 60Hz

	#Extension block found. Parsing...
I only know about extension blocks of type 02h. PLEASE email me!
Something strange happened. Please contact the author,
Matthew Kern at <pyrophobicman@gmail.com>
---

Having had no reply on the Linux kernel bug tracker about adding a quirk for my monitor I forgot about this for a while. But recently I stumbled on a tutorial that explains how to edit the EDID with a hex editor. The EDID for the VGA output reports the correct display size (but somehow even with the correct display size the scaling is still wrong). So I edited the HDMI EDID with the display size values of the VGA EDID and fixed the checksum. Then I used the new drm.edid_firmware= boot option in Linux 4.15 to load the edited HDMI EDID. Now Xorg reports:

[    38.005] (II) RADEON(0): Setting screen physical size to 508 x 285

But xrandr still reports

HDMI-0 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 160mm x 90mm

Unsurprisingly the scaling is still wrong. It seems like xrandr is bypassing the fixed HDMI EDID loaded by Linux and still using the bad one from the monitor. But what's even weirder is that the scaling shouldn't be wrong when using the VGA output since the VGA EDID reports the correct display size. Where is xrandr getting it's display size from?

I was hoping xorg-server 1.20 was going to fix this, but no such luck.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/235.