Hello, Michael. On Sun, Aug 25, 2024 at 16:31:54 +0100, Michael wrote: > On Sunday, 25 August 2024 13:33:14 BST Alan Mackenzie wrote: > > On Sat, Aug 24, 2024 at 20:36:11 +0000, Alan Mackenzie wrote: > > > On Sat, Aug 24, 2024 at 16:40:38 +0100, Michael wrote: > > > > On Saturday, 24 August 2024 14:25:31 BST Alan Mackenzie wrote: > > > > > On Sat, Aug 24, 2024 at 10:44:44 +0100, Michael wrote: > > [ .... ]
> > > > This reads like an unsuitable refresh rate problem. > Ah! I was wrong at my assumption - I had not understood the displayed > resolution was not the native/optimal monitor resolution. > > > I've read the "information" section from my monitor's adjustment panel. > > > It says 60 Hz. and 1920x1080 (on my current machine). On the new > > > machine, it reads 60 Hz., 2112x1016. This looks like being at the core > > > of the problem. 2112 / 1920 = 1.1 (more or less), i.e. 10% too many > > > pixels. > > > My monitor is ~52cm wide. 10% of this is the ~5cm. black strip at the > > > LHS of the monitor. > Right, for some reason the graphics core is not driving the monitor at the > appropriate (optimal) resolution. It doesn't in the BIOS settings display, either. There, it is also 2112x1116. (I think the "1016" from last night was a typo.) > > > Is there any convenient way I can display the current EDID information > > > block? > > Yes, there is: there is the package x11-misc/read-edid, which contains > > two utilities get-edid and parse-edid. Calling # get-edid | parse-edid > > produces, on my current machine: > > This is read-edid version 3.0.2. Prepare for some fun. > > Attempting to use i2c interface > > No EDID on bus 0 > > No EDID on bus 2 > > No EDID on bus 3 > > No EDID on bus 4 > > No EDID on bus 5 > > No EDID on bus 6 > > No EDID on bus 7 > > 1 potential busses found: 1 > > 256-byte EDID successfully retrieved from i2c bus 1 > > Looks like i2c was successful. Have a good day. > > Checksum Correct > > Section "Monitor" > > Identifier "SMB2430L" > > ModelName "SMB2430L" > > VendorName "SAM" > > # Monitor Manufactured week 13 of 2011 > > # EDID version 1.3 > > # Digital Display > > DisplaySize 520 290 > > Gamma 2.20 > > Option "DPMS" "true" > > Horizsync 30-81 > > VertRefresh 56-75 > > # Maximum pixel clock is 170MHz > > #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: 1600x1200, 60Hz > > #Not giving standard mode: 1680x1050, 60Hz > > #Not giving standard mode: 1152x864, 75Hz > > #Not giving standard mode: 1440x900, 75Hz > >From the above we can't tell if the monitor will work at 1920x1080@60Hz, but > according to the OEM specification sheet it should and the VertRefresh range > of 56-75 is broad enough to accommodate anything within it. Well the monitor's been working at that resolution since (according to the EDID) 2011. :-) > > #Extension block found. Parsing... > > Modeline "Mode 0" +hsync +vsync > > Modeline "Mode 1" +hsync +vsync > > Modeline "Mode 2" +hsync +vsync > > Modeline "Mode 3" +hsync +vsync > > Modeline "Mode 4" -hsync -vsync > > EndSection > Hmm ... no Modelines shown above and no preferred Mode provided. :-( Ah, I see from Dale's posts what the "Modeline"s are meant to be. I wonder why they're missing from my (somewhat old) monitor. > > .. On my new machine, it is almost identical, just using I2C bus 0, > > rather than 1. > > It is now clear that EDID contains not an optimal screen setting, but > > instead ranges (for example 56-75 Hz. screen refresh rate). > The ranges are indicative of what refresh rates the panel is capable of, for > different resolutions. As you say, of more concern is it does not provide an > optimal Mode. Yes. > > The question arises, what exactly puts the display into 1920x1080 > > 60Hz. at boot up time? Something must be chosing that resolution. > > I've tried grepping the kernel sources, but there are a lot lf > > "1920x1080"s there. > > :-( > You can try adding the correct video resolution at the kernel cmdline - see > below. Somehow I don't think that will work (which doesn't mean I won't try it). There is something in the motherboard which is throwing off the desired resolution by those extra 192 horizontal pixels, even in the BIOS. > > [ .... ] > > > My hypothesis at the moment is that something in the new machine is > > > wrongly pumping out 2112x1016 in place of 1980x1080 and this is > > > diminishing the size of (and reducing the quality of) the displayed > > > image. > Yes, from what you described this appears to be the case. > > > I think the EDID being received from the monitor and KVM-box are correct, > > > but that the BIOS is applying some "correction" to them, for some reason. > I'm not sure about this, look at the EDID output. The Modelines are > incomplete with no preferred resolution as per the OEM's specification. Yes, that's puzzling. But I'm pretty sure the monitor's display came up correctly when I first booted the machine last Monday. I think it was only after I started playing with it that it went wrong; that "playing with" was supplying the drm.edid_firmware kernel parameter. > > > Maybe I should try resetting the CMOS ram. > I'd be surprised if this has any effect on the displayed resolution. Something on my MB is adding in the spurious extra 192 pixels horizontally. > The EDID/DDC protocol expects a certain DC voltage (+5V). If this is not > provided as cleanly and uninterruptedly as expected, the initialisation and > communication between monitor & graphics card could go awry. Hence me > mumbling about avoiding adaptors and connectors which due to faults, poor > manufacture, dirt, oxidation, etc., could add resistance to the I2C wire > circuits. Of course the KVM itself may be interfering with what-ever EDID is > provided by the monitor itself. > Your approach to specify the resolution via an edid file should work, at > least > until it is deprecated from kernel 6.9.x onward and you have to build your > own > edid firmware file from the assembly source files in /usr/src/linux/tools/ > edid/. Oh dear! Yet more progress in the kernel. ;-( > You can enable CONFIG_DRM_LOAD_EDID_FIRMWARE in your kernel and add to the > kernel cmdline: > drm_kms_helper.edid_firmware=edid/edid/1920x1080.bin > Before you add the above, I'm not clear if I understand correctly from this > document, if first you have to run "make" in /usr/src/linux/tools/edid/ to > build the binary EDID blobs in your kernel image, or if they are built anyway > when you run make as part of building your kernel from source: The latter, I think. > /usr/src/linux/Documentation/admin-guide/edid.rst > Another option to try in case it works with KMS: > video=HDMI-A-1:1920x1080@60D I will try that now. I'm not very hopeful, I must admit. Just tried it - it didn't work. :-( But at least the videos still comes up as before. > To find what your card/port string is named as look at: > ls -la /sys/class/drm/* grep HDMI > or > dmesg | grep Connector -A1 -- Alan Mackenzie (Nuremberg, Germany).
