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

[Michael <confabulate@kintzios.com>]

[-- Attachment #1: Type: text/plain, Size: 5992 bytes --]

On Sunday, 25 August 2024 13:33:14 BST Alan Mackenzie wrote:
> Hello, Michael.
> 
> 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.


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


>         #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.  :-(


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


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


> [ .... ]
> 
> > 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.


> > Maybe I should try resetting the CMOS ram.

I'd be surprised if this has any effect on the displayed resolution.

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

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:

/usr/src/linux/Documentation/admin-guide/edid.rst


Another option to try in case it works with KMS:

video=HDMI-A-1:1920x1080@60D

To find what your card/port string is named as look at:

ls -la /sys/class/drm/* grep HDMI

or 

dmesg | grep Connector -A1

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]