Re: [gentoo-user] New machine: Contents of display are offset around 2 inches from the left hand side.

[Alan Mackenzie <acm@muc.de>]

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).