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

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

[Alan Mackenzie]

Hello, Gentoo.

Thanks to everybody who helped me get my video going in the other thread.

I've now got a more puzzling problem:  Every time I boot up my new
machine, the 1920x1080 pixel display is offset by around 2 inches from
the left hand side (and aroun 1 cm from the top).  It still appears to be
1920x1080 pixels (more precisely, 240 columns x 67 lines of 16x8
characters), but it's not filling the screen.

The screen itself is attached to a KVM box, and it works just fine on the
old machine.  So it's not the physical display which is at fault.  It's
an around 10 year old Samsung digital monitor, not some ancient CRT, or
anything like that.  It's interface is a DVI cable.

I seem to remember it filled the screen when it was new (on Monday).

Part of my efforts to make the video work (see other thread) involved
giving the kernel the drm.edid_firmware parameter.  This parameter is
intended to compensate for the display/KVM box/whatever failing to supply
the correct EDID information to the PC.  One of the settings I tried
involved the offsets from the left and top mentioned above.  But somehow
they seem to have got stuck in the machine.  It seems the BIOS has saved
the offsets in the CMOS or something.  I don't know how to undo these
saved settings.

Would somebody please help me on this, too.

Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Michael]

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

On Thursday, 22 August 2024 17:54:19 BST Alan Mackenzie wrote:
> Hello, Gentoo.
> 
> Thanks to everybody who helped me get my video going in the other thread.
> 
> I've now got a more puzzling problem:  Every time I boot up my new
> machine, the 1920x1080 pixel display is offset by around 2 inches from
> the left hand side (and aroun 1 cm from the top).  It still appears to be
> 1920x1080 pixels (more precisely, 240 columns x 67 lines of 16x8
> characters), but it's not filling the screen.
> 
> The screen itself is attached to a KVM box, and it works just fine on the
> old machine.  So it's not the physical display which is at fault.  It's
> an around 10 year old Samsung digital monitor, not some ancient CRT, or
> anything like that.  It's interface is a DVI cable.
> 
> I seem to remember it filled the screen when it was new (on Monday).
> 
> Part of my efforts to make the video work (see other thread) involved
> giving the kernel the drm.edid_firmware parameter.  This parameter is
> intended to compensate for the display/KVM box/whatever failing to supply
> the correct EDID information to the PC.  One of the settings I tried
> involved the offsets from the left and top mentioned above.  But somehow
> they seem to have got stuck in the machine.  It seems the BIOS has saved
> the offsets in the CMOS or something.  I don't know how to undo these
> saved settings.
> 
> Would somebody please help me on this, too.
> 
> Thanks!

I must have missed the other thread where you had to feed to the kernel an  
drm.edid_firmware file.  Assuming the file is still available and built in the 
kernel as firmware, then the problem could well have to do with the DVI cable.  
It may be worth unplugging and replugging it.

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

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

[Alan Mackenzie]

Hello, Michael.

On Thu, Aug 22, 2024 at 22:44:47 +0100, Michael wrote:
> On Thursday, 22 August 2024 17:54:19 BST Alan Mackenzie wrote:
> > Hello, Gentoo.

> > Thanks to everybody who helped me get my video going in the other thread.

> > I've now got a more puzzling problem:  Every time I boot up my new
> > machine, the 1920x1080 pixel display is offset by around 2 inches from
> > the left hand side (and aroun 1 cm from the top).  It still appears to be
> > 1920x1080 pixels (more precisely, 240 columns x 67 lines of 16x8
> > characters), but it's not filling the screen.

> > The screen itself is attached to a KVM box, and it works just fine on the
> > old machine.  So it's not the physical display which is at fault.  It's
> > an around 10 year old Samsung digital monitor, not some ancient CRT, or
> > anything like that.  It's interface is a DVI cable.

> > I seem to remember it filled the screen when it was new (on Monday).

> > Part of my efforts to make the video work (see other thread) involved
> > giving the kernel the drm.edid_firmware parameter.  This parameter is
> > intended to compensate for the display/KVM box/whatever failing to supply
> > the correct EDID information to the PC.  One of the settings I tried
> > involved the offsets from the left and top mentioned above.  But somehow
> > they seem to have got stuck in the machine.  It seems the BIOS has saved
> > the offsets in the CMOS or something.  I don't know how to undo these
> > saved settings.

> > Would somebody please help me on this, too.

> > Thanks!

> I must have missed the other thread where you had to feed to the kernel an  
> drm.edid_firmware file.

Sorry, I phrased that badly.  As part of the other problem I tried using
drm.edid_firmware, but I didn't mention it in that thread.

> Assuming the file is still available and built in the kernel as
> firmware, ....

I used one of the stock options, drm.edid_firmware=edid/1920x1080.bin.
There's something in the kernel that recognises these 6 or 7 "file names"
and uses the built in EDID blocks for them rather than reading from
/lib/firmware.

But the source code for these has things like XOFFSET parameters, so I'm
thinking that one of these took effect and "got stuck", somehow.

> .... then the problem could well have to do with the DVI cable.  It may
> be worth unplugging and replugging it.

I tried pulling the cable (whilst switched on) and replacing it.  This
didn't help (but doesn't seem to have done any damage, either ;-).

I haven't tried anything desperate, like clearing the CMOS, yet.

I've sent a support request to the manufacturers, MSI, which they will
hopefully answer some time next week.  In the mean time, I'll just have
to carry on intalling/configuring Gentoo with a nasty black stripe on my
screen.

I'm a bit fed up with all of this.  It's a new machine, but the
motherboard, an MSI B650 Tomahawk Wifi, has been around a fair while and
bugs in its BIOS ought to have been fixed by now.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Dale]

Alan Mackenzie wrote:
> Hello, Michael.
>
> On Thu, Aug 22, 2024 at 22:44:47 +0100, Michael wrote:
>> On Thursday, 22 August 2024 17:54:19 BST Alan Mackenzie wrote:
>>> Hello, Gentoo.
>>> Thanks to everybody who helped me get my video going in the other thread.
>>> I've now got a more puzzling problem:  Every time I boot up my new
>>> machine, the 1920x1080 pixel display is offset by around 2 inches from
>>> the left hand side (and aroun 1 cm from the top).  It still appears to be
>>> 1920x1080 pixels (more precisely, 240 columns x 67 lines of 16x8
>>> characters), but it's not filling the screen.
>>> The screen itself is attached to a KVM box, and it works just fine on the
>>> old machine.  So it's not the physical display which is at fault.  It's
>>> an around 10 year old Samsung digital monitor, not some ancient CRT, or
>>> anything like that.  It's interface is a DVI cable.
>>> I seem to remember it filled the screen when it was new (on Monday).
>>> Part of my efforts to make the video work (see other thread) involved
>>> giving the kernel the drm.edid_firmware parameter.  This parameter is
>>> intended to compensate for the display/KVM box/whatever failing to supply
>>> the correct EDID information to the PC.  One of the settings I tried
>>> involved the offsets from the left and top mentioned above.  But somehow
>>> they seem to have got stuck in the machine.  It seems the BIOS has saved
>>> the offsets in the CMOS or something.  I don't know how to undo these
>>> saved settings.
>>> Would somebody please help me on this, too.
>>> Thanks!
>> I must have missed the other thread where you had to feed to the kernel an  
>> drm.edid_firmware file.
> Sorry, I phrased that badly.  As part of the other problem I tried using
> drm.edid_firmware, but I didn't mention it in that thread.
>
>> Assuming the file is still available and built in the kernel as
>> firmware, ....
> I used one of the stock options, drm.edid_firmware=edid/1920x1080.bin.
> There's something in the kernel that recognises these 6 or 7 "file names"
> and uses the built in EDID blocks for them rather than reading from
> /lib/firmware.
>
> But the source code for these has things like XOFFSET parameters, so I'm
> thinking that one of these took effect and "got stuck", somehow.
>
>> .... then the problem could well have to do with the DVI cable.  It may
>> be worth unplugging and replugging it.
> I tried pulling the cable (whilst switched on) and replacing it.  This
> didn't help (but doesn't seem to have done any damage, either ;-).
>
> I haven't tried anything desperate, like clearing the CMOS, yet.
>
> I've sent a support request to the manufacturers, MSI, which they will
> hopefully answer some time next week.  In the mean time, I'll just have
> to carry on intalling/configuring Gentoo with a nasty black stripe on my
> screen.
>
> I'm a bit fed up with all of this.  It's a new machine, but the
> motherboard, an MSI B650 Tomahawk Wifi, has been around a fair while and
> bugs in its BIOS ought to have been fixed by now.
>


I'm going to add a tidbit of info here.  Might relate, might not.  On my
old system and my new system, I installed the sys-kernel/linux-firmware
package.  During the install of that package, a file magically appeared
in /boot named amd-uc.img and when I run grub to create the config file,
it sees and adds that the same as it does a init thingy and kernel for
booting.  I think a few months ago the way firmware works changed.  I
think there is a news item.  Maybe. 

Even if you don't use init thingys, you might could use that file the
linux-firmware package creates.  Maybe you can put that in your kernel
and include it inside the kernel.  Then when you update your kernel,
just include the newer file the package provides in /boot. 

I have everything but /var on / partition now.  Still, I use a init
thingy even tho I may not need it anymore.  If nothing else, it may need
to apply that firmware file either currently or at some point in the
future.  I don't know if the init thingy is needed for that either tho. 
I just know I can boot. ;-) 

If nothing else, that may give you a idea, about something I really
don't understand completely.  o_O  LOL 

Dale

:-)  :-) 

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

[Jack]

On 2024.08.23 12:21, Alan Mackenzie wrote:
> I'm a bit fed up with all of this.  It's a new machine, but the
> motherboard, an MSI B650 Tomahawk Wifi, has been around a fair while  
> and
> bugs in its BIOS ought to have been fixed by now.

Just because the latest available BIOS might have fixed a problem does  
not mean the physical mobo you bought actually has the latest BIOS  
installed.  Have you checked, just to be compulsively certain?

I say that because not too many years ago, I bought an MSI mobo and  
Ryzen CPU (from the same vendor) and I ended up having to buy (eBay) an  
older CPU just to boot the machine so I could update the BIOS to one  
which could handle the new CPU, because the installed BIOS was too old.

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

[Dale]

Jack wrote:
> On 2024.08.23 12:21, Alan Mackenzie wrote:
>> I'm a bit fed up with all of this.  It's a new machine, but the
>> motherboard, an MSI B650 Tomahawk Wifi, has been around a fair while and
>> bugs in its BIOS ought to have been fixed by now.
>
> Just because the latest available BIOS might have fixed a problem does
> not mean the physical mobo you bought actually has the latest BIOS
> installed.  Have you checked, just to be compulsively certain?
>
> I say that because not too many years ago, I bought an MSI mobo and
> Ryzen CPU (from the same vendor) and I ended up having to buy (eBay)
> an older CPU just to boot the machine so I could update the BIOS to
> one which could handle the new CPU, because the installed BIOS was too
> old.
>
>


When I built my new rig, one of the first things I did after making sure
it wasn't bad out of the box, update the BIOS.  Mine was like 2 or 3
versions behind.  It booted and all but I did update anyway, just to
prevent weirdness later.  Turns out I had enough weirdness with a old
monitor so I needed to rid myself of some for sure. 

I might add, I had to do the same thing on my old system when I first
built it.  I'm not sure on my very first rig.  I think newer mobos will
update now even without a CPU.  At least mine seems claims that anyway. 

Dale

:-)  :-) 

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

[Alan Mackenzie]

Hello, Dale.

On Fri, Aug 23, 2024 at 13:44:36 -0500, Dale wrote:
> Jack wrote:
> > On 2024.08.23 12:21, Alan Mackenzie wrote:
> >> I'm a bit fed up with all of this.  It's a new machine, but the
> >> motherboard, an MSI B650 Tomahawk Wifi, has been around a fair while and
> >> bugs in its BIOS ought to have been fixed by now.

> > Just because the latest available BIOS might have fixed a problem does
> > not mean the physical mobo you bought actually has the latest BIOS
> > installed.  Have you checked, just to be compulsively certain?

> > I say that because not too many years ago, I bought an MSI mobo and
> > Ryzen CPU (from the same vendor) and I ended up having to buy (eBay)
> > an older CPU just to boot the machine so I could update the BIOS to
> > one which could handle the new CPU, because the installed BIOS was too
> > old.




> When I built my new rig, one of the first things I did after making sure
> it wasn't bad out of the box, update the BIOS.  Mine was like 2 or 3
> versions behind.  It booted and all but I did update anyway, just to
> prevent weirdness later.  Turns out I had enough weirdness with a old
> monitor so I needed to rid myself of some for sure. 

With my current system (from 2017), I bought a new Ryzen processor and
MB just as soon as I could find somebody with stock to sell.  The MB was
in a disgusting state, not being fit for its purpose.  It crashed
withing two minutes of booting up, just in the BIOS.  Its programmers
were clearly working to a deadline, rather than to QA structures.
Thankfully, I knew to update the BIOS, which I did, after which the
system ran more or less stably.  Except for that bug in the early Ryzen
chips which led to a sporadic segfault when building software.  I could
have swapped the processor for a debugged one, but with all the hassle
of taking my new machine to pieces again, I never got round to it.

I've not made the same mistake with my newest system - although there's
a new generation of AMD chips just out, I've stuck with the previous
generation, hoping I'll not need to go through the same palaver again.

Though it's looking like there's at least one bug in my MB.  :-(  Maybe
I'm going to have to update its BIOS anyway.  But we'll see what MSI's
technical support say to my support request, first.

> I might add, I had to do the same thing on my old system when I first
> built it.  I'm not sure on my very first rig.  I think newer mobos will
> update now even without a CPU.  At least mine seems claims that anyway. 

I believe that is the case, yes.  Hopefully, they'll update even with a
CPU installed.  ;-)

> Dale

> :-)  :-) 

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Michael]

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

On Friday, 23 August 2024 17:21:42 BST Alan Mackenzie wrote:
> Hello, Michael.
> 
> On Thu, Aug 22, 2024 at 22:44:47 +0100, Michael wrote:

> > Assuming the file is still available and built in the kernel as
> > firmware, ....
> 
> I used one of the stock options, drm.edid_firmware=edid/1920x1080.bin.
> There's something in the kernel that recognises these 6 or 7 "file names"
> and uses the built in EDID blocks for them rather than reading from
> /lib/firmware.
> 
> But the source code for these has things like XOFFSET parameters, so I'm
> thinking that one of these took effect and "got stuck", somehow.

I am not sure a modern BIOS would get stuck as you're describing.  I think the 
MoBo will detect any graphics chips connected to it, in this case your 
integrated APU graphics chip, and the graphics chip will in turn prompt for 
any connected display hardware.  In this case your monitor should respond and 
send the EDID data to the graphics chip, which will adjust its signal to what 
the monitor requires.


> > .... then the problem could well have to do with the DVI cable.  It may
> > be worth unplugging and replugging it.
> 
> I tried pulling the cable (whilst switched on) and replacing it.  This
> didn't help (but doesn't seem to have done any damage, either ;-).

I normally power off peripherals, except for USB devices, before I disconnect/
reconnect cables.  Especially legacy IRQ connected kit which is not hot-
swappable - e.g. PS/2 connectors.  Modern systems don't have such issues, but 
I'm used to taking this precaution.  :-p


> I haven't tried anything desperate, like clearing the CMOS, yet.
> 
> I've sent a support request to the manufacturers, MSI, which they will
> hopefully answer some time next week.  In the mean time, I'll just have
> to carry on intalling/configuring Gentoo with a nasty black stripe on my
> screen.

Instead of resetting the firmware and losing all your MoBo settings, you'd be 
better off to flash the latest firmware on the MoBo.  UEFI MoBo firmware 
usually offers the option to back up your settings first.   MSI support would 
probably ask you to do this and reset all settings anyway, before they deal 
with any issues.

Do you still get this offset problem if you remove the KVM switch and connect 
the monitor directly to the MoBo?

What may be happening is the KVM causes some distortion to the signal 
amplitude/frequency, which the monitor interprets as an offset.  You could try 
to tweak this by feeding a bespoke EDID to the kernel, but sometimes a simple 
cable swap or operating the KVM a few times can cure it.


> I'm a bit fed up with all of this.  It's a new machine, but the
> motherboard, an MSI B650 Tomahawk Wifi, has been around a fair while and
> bugs in its BIOS ought to have been fixed by now.

Well, we don't know if this is caused by a MoBo firmware bug, although the 
quality of firmware often leaves much to be desired.

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

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

[Michael]

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

On Friday, 23 August 2024 19:27:58 BST Dale wrote:

> I'm going to add a tidbit of info here.  Might relate, might not.  On my
> old system and my new system, I installed the sys-kernel/linux-firmware
> package.  During the install of that package, a file magically appeared
> in /boot named amd-uc.img 

This is the CPU microcode for AMD CPUs:

https://wiki.gentoo.org/wiki/AMD_microcode

> and when I run grub to create the config file,
> it sees and adds that the same as it does a init thingy and kernel for
> booting.  I think a few months ago the way firmware works changed.  I
> think there is a news item.  Maybe. 
> 
> Even if you don't use init thingys, you might could use that file the
> linux-firmware package creates.  Maybe you can put that in your kernel
> and include it inside the kernel.  Then when you update your kernel,
> just include the newer file the package provides in /boot. 

It can be built in the kernel, or added to the initramfs if you use one.


> If nothing else, that may give you a idea, about something I really
> don't understand completely.  o_O  LOL 
> 
> Dale
> 
> :-)  :-) 

The CPU OEMs occasionally release microcode updates to address CPU instruction 
bugs, but for modern CPUs you're more likely to obtain a timely microcode 
patch by updating your MoBo's firmware.

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

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

[Alan Mackenzie]

Hello, Michael.

On Sat, Aug 24, 2024 at 10:44:44 +0100, Michael wrote:
> On Friday, 23 August 2024 17:21:42 BST Alan Mackenzie wrote:
> > On Thu, Aug 22, 2024 at 22:44:47 +0100, Michael wrote:

> > > Assuming the file is still available and built in the kernel as
> > > firmware, ....

> > I used one of the stock options, drm.edid_firmware=edid/1920x1080.bin.
> > There's something in the kernel that recognises these 6 or 7 "file names"
> > and uses the built in EDID blocks for them rather than reading from
> > /lib/firmware.

> > But the source code for these has things like XOFFSET parameters, so I'm
> > thinking that one of these took effect and "got stuck", somehow.

> I am not sure a modern BIOS would get stuck as you're describing.  I think the 
> MoBo will detect any graphics chips connected to it, in this case your 
> integrated APU graphics chip, and the graphics chip will in turn prompt for 
> any connected display hardware.  In this case your monitor should respond and 
> send the EDID data to the graphics chip, which will adjust its signal to what 
> the monitor requires.

That's the theory, yes, but in practice it's not quite working.

> > > .... then the problem could well have to do with the DVI cable.  It may
> > > be worth unplugging and replugging it.

> > I tried pulling the cable (whilst switched on) and replacing it.  This
> > didn't help (but doesn't seem to have done any damage, either ;-).

> I normally power off peripherals, except for USB devices, before I disconnect/
> reconnect cables.  Especially legacy IRQ connected kit which is not hot-
> swappable - e.g. PS/2 connectors.  Modern systems don't have such issues, but 
> I'm used to taking this precaution.  :-p

Me too, usually.  ;-)

> > I haven't tried anything desperate, like clearing the CMOS, yet.

> > I've sent a support request to the manufacturers, MSI, which they will
> > hopefully answer some time next week.  In the mean time, I'll just have
> > to carry on intalling/configuring Gentoo with a nasty black stripe on my
> > screen.

> Instead of resetting the firmware and losing all your MoBo settings, you'd be 
> better off to flash the latest firmware on the MoBo.  UEFI MoBo firmware 
> usually offers the option to back up your settings first.   MSI support would 
> probably ask you to do this and reset all settings anyway, before they deal 
> with any issues.

I think you're right, there.  Unless I've already got the latest firmware
installed (the form to fill in for MSI asked for the firmware version,
which I gave).

> Do you still get this offset problem if you remove the KVM switch and connect 
> the monitor directly to the MoBo?

I tried that, but got no display signal at all.  Maybe I had the wrong
cable plugged into the wrong socket, but I don't think so.  There's a
veritable rats' nest of cables behind my PCs which is moderately
difficult to get to.  I was able to shut the machine down by logging in
as root blind, and typing shutdown -h now, so the machine defintely came
up.

With the new PC connected up through the KVM switch (and also an
HDMI->DVI adapter) I'm still getting the 5cm. gap at the LH side of the
screen.  I've installed X and xfce, and that displays poorly, with lots
of flickering, shimmering colour threads through the display.  I suspect
my HDMI->DVI adapter may be broken.  The display goes blank for several
seconds then comes back again several times a minute.  I saw something
like this when I booted KDE from the live-CD a few days ago to see the
firmware files needed.

It's worth noting that my display was also imperfect when I plugged
laptops into it a couple of years back, but not so bad as my xfce is now.

> What may be happening is the KVM causes some distortion to the signal 
> amplitude/frequency, which the monitor interprets as an offset.  You could try 
> to tweak this by feeding a bespoke EDID to the kernel, but sometimes a simple 
> cable swap or operating the KVM a few times can cure it.

Maybe, but it's all digital, not analog, isn't it?  I remember tweaking
timings in .xinit for CRT monitors (a tedious job, indeed), but surely an
EDID signal is either going to be read by the OS correctly, or not at
all?

I've already tried swapping the cables to the KVM box, this achieving
nothing.

> > I'm a bit fed up with all of this.  It's a new machine, but the
> > motherboard, an MSI B650 Tomahawk Wifi, has been around a fair while and
> > bugs in its BIOS ought to have been fixed by now.

> Well, we don't know if this is caused by a MoBo firmware bug, although the 
> quality of firmware often leaves much to be desired.

We don't know, no, so I have to guess so as to come up with tests to try.
;-)  The firmware on this MB fails to save the boot order when I put the
DVD drive at the start, in front of the NVMEs (which are still called
"hard drives").  Thus the BIOS isn't perfect.

I'm still pretty sure that when I booted the machine for the first time,
the display was correct.  In particular, I remember noticing the offset
after I tried booting with the drm.edid_firmware kernel parameter for the
first time.

I think I should try to update the firmware, and see if that clears the
problem.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Michael]

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

On Saturday, 24 August 2024 14:25:31 BST Alan Mackenzie wrote:
> On Sat, Aug 24, 2024 at 10:44:44 +0100, Michael wrote:

> > Instead of resetting the firmware and losing all your MoBo settings, you'd
> > be better off to flash the latest firmware on the MoBo.  UEFI MoBo
> > firmware usually offers the option to back up your settings first.   MSI
> > support would probably ask you to do this and reset all settings anyway,
> > before they deal with any issues.
> 
> I think you're right, there.  Unless I've already got the latest firmware
> installed (the form to fill in for MSI asked for the firmware version,
> which I gave).
> 
> > Do you still get this offset problem if you remove the KVM switch and
> > connect the monitor directly to the MoBo?
> 
> I tried that, but got no display signal at all.  Maybe I had the wrong
> cable plugged into the wrong socket, but I don't think so.  There's a
> veritable rats' nest of cables behind my PCs which is moderately
> difficult to get to.  I was able to shut the machine down by logging in
> as root blind, and typing shutdown -h now, so the machine defintely came
> up.

Hmm ... normally you would have a display coming up, if your PC is indeed 
connected to the monitor.  This would be the first thing I would try to make 
sure I can get a correct display.  :-/


> With the new PC connected up through the KVM switch (and also an
> HDMI->DVI adapter) I'm still getting the 5cm. gap at the LH side of the
> screen.  I've installed X and xfce, and that displays poorly, with lots
> of flickering, shimmering colour threads through the display.  I suspect
> my HDMI->DVI adapter may be broken.  The display goes blank for several
> seconds then comes back again several times a minute.  I saw something
> like this when I booted KDE from the live-CD a few days ago to see the
> firmware files needed.

This reads like an unsuitable refresh rate problem.


> It's worth noting that my display was also imperfect when I plugged
> laptops into it a couple of years back, but not so bad as my xfce is now.
> 
> > What may be happening is the KVM causes some distortion to the signal
> > amplitude/frequency, which the monitor interprets as an offset.  You could
> > try to tweak this by feeding a bespoke EDID to the kernel, but sometimes
> > a simple cable swap or operating the KVM a few times can cure it.
> 
> Maybe, but it's all digital, not analog, isn't it?  I remember tweaking
> timings in .xinit for CRT monitors (a tedious job, indeed), but surely an
> EDID signal is either going to be read by the OS correctly, or not at
> all?

Yes, the processing is digital, but the noise on the wire may not be.  I've 
seen an LED monitor randomly coming up with a lot of distortion on console or 
DM (SDDM), everything flickering and double image/shading, only for the 
display to reset perfectly when a Plasma desktop is launched, or after the PC 
is rebooted.  If the handshake between the card and the monitor is incorrect 
when hardware is initialised, then you'll need a reset of sorts to start again 
with the correct EDID parameters.


> I've already tried swapping the cables to the KVM box, this achieving
> nothing.
> 
> > > I'm a bit fed up with all of this.  It's a new machine, but the
> > > motherboard, an MSI B650 Tomahawk Wifi, has been around a fair while and
> > > bugs in its BIOS ought to have been fixed by now.
> > 
> > Well, we don't know if this is caused by a MoBo firmware bug, although the
> > quality of firmware often leaves much to be desired.
> 
> We don't know, no, so I have to guess so as to come up with tests to try.
> ;-)  The firmware on this MB fails to save the boot order when I put the
> DVD drive at the start, in front of the NVMEs (which are still called
> "hard drives").  Thus the BIOS isn't perfect.
> 
> I'm still pretty sure that when I booted the machine for the first time,
> the display was correct.  In particular, I remember noticing the offset
> after I tried booting with the drm.edid_firmware kernel parameter for the
> first time.

I expect, but don't know, the embedded kernel drm.edid_firmware codes offer 
some default resolution sizes and refresh rates.  If your monitor prefers e.g. 
59Hz as opposed to a default of 60Hz, you could experience the problems you 
describe above.  I was thinking if you can get a correct display coming up 
with the monitor connected directly to the graphics port, then you can capture 
the EDID reported by the monitor and feed this to the kernel as an EDID file 
instead.


> I think I should try to update the firmware, and see if that clears the
> problem.

The latest firmware is 7D75v1J and was released very recently.  It deals with 
a security issue too, so it's advisable using this version sooner or later:

https://www.msi.com/Motherboard/MAG-B650-TOMAHAWK-WIFI/support

Besides trying the latest firmware, some other things to try:

1. Use a cable with the appropriate connectors at each end.  No KVM, no 
intermediate adaptors, no extensions, nothing-in-between.  Then add one thing 
at a time to see what makes a difference.

2. Try reseting the monitor itself.  Usually there is some OSD menu to adjust 
monitor settings, see if there is a 'Reset Display' or similar option.

3. Check if the monitor display corrects itself by playing with refresh rates 
using xrandr/xorg.conf/desktop GUI Display settings after you launch xfce.

4. You should not have to do this, but if the KVM consistently throws out the 
offset then check if the monitor OSD has a screen adjustment submenu to tweak 
the screen viewport and shift it to fit the monitor.

Let's hope one of these things delivers a working display for you.  :-)

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

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

[Alan Mackenzie]

Hello again, Michael.

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:

> > > Instead of resetting the firmware and losing all your MoBo settings, you'd
> > > be better off to flash the latest firmware on the MoBo.  UEFI MoBo
> > > firmware usually offers the option to back up your settings first.   MSI
> > > support would probably ask you to do this and reset all settings anyway,
> > > before they deal with any issues.

> > I think you're right, there.  Unless I've already got the latest firmware
> > installed (the form to fill in for MSI asked for the firmware version,
> > which I gave).

> > > Do you still get this offset problem if you remove the KVM switch and
> > > connect the monitor directly to the MoBo?

> > I tried that, but got no display signal at all.  Maybe I had the wrong
> > cable plugged into the wrong socket, but I don't think so.  There's a
> > veritable rats' nest of cables behind my PCs which is moderately
> > difficult to get to.  I was able to shut the machine down by logging in
> > as root blind, and typing shutdown -h now, so the machine defintely came
> > up.

> Hmm ... normally you would have a display coming up, if your PC is indeed 
> connected to the monitor.  This would be the first thing I would try to make 
> sure I can get a correct display.  :-/

I also tried (a day or two ago) sticking the HDMI->DVI adapter into my
current PC's graphic card's HDMI slot.  I also got no signal this way.
(My current PC has a graphic card with both DVI and HDMI slots on it.)
Maybe there's something very close to tolerance somewhere, somehow, that
my HDMI->DVI adapter is somehow pushing out of tolerance.  Or something
like that.

> > With the new PC connected up through the KVM switch (and also an
> > HDMI->DVI adapter) I'm still getting the 5cm. gap at the LH side of the
> > screen.  I've installed X and xfce, and that displays poorly, with lots
> > of flickering, shimmering colour threads through the display.  I suspect
> > my HDMI->DVI adapter may be broken.  The display goes blank for several
> > seconds then comes back again several times a minute.  I saw something
> > like this when I booted KDE from the live-CD a few days ago to see the
> > firmware files needed.

> This reads like an unsuitable refresh rate problem.

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.

Is there any convenient way I can display the current EDID information
block?

> > It's worth noting that my display was also imperfect when I plugged
> > laptops into it a couple of years back, but not so bad as my xfce is now.

> > > What may be happening is the KVM causes some distortion to the signal
> > > amplitude/frequency, which the monitor interprets as an offset.  You could
> > > try to tweak this by feeding a bespoke EDID to the kernel, but sometimes
> > > a simple cable swap or operating the KVM a few times can cure it.

> > Maybe, but it's all digital, not analog, isn't it?  I remember tweaking
> > timings in .xinit for CRT monitors (a tedious job, indeed), but surely an
> > EDID signal is either going to be read by the OS correctly, or not at
> > all?

> Yes, the processing is digital, but the noise on the wire may not be.  I've 
> seen an LED monitor randomly coming up with a lot of distortion on console or 
> DM (SDDM), everything flickering and double image/shading, only for the 
> display to reset perfectly when a Plasma desktop is launched, or after the PC 
> is rebooted.  If the handshake between the card and the monitor is incorrect 
> when hardware is initialised, then you'll need a reset of sorts to start again 
> with the correct EDID parameters.

I've tried to reset the monitor via its adjustment panel, but I don't
think I managed the final step.  In any case, the monitor just carried on
as before.

> > I've already tried swapping the cables to the KVM box, this achieving
> > nothing.

> > > > I'm a bit fed up with all of this.  It's a new machine, but the
> > > > motherboard, an MSI B650 Tomahawk Wifi, has been around a fair while and
> > > > bugs in its BIOS ought to have been fixed by now.

> > > Well, we don't know if this is caused by a MoBo firmware bug, although the
> > > quality of firmware often leaves much to be desired.

> > We don't know, no, so I have to guess so as to come up with tests to try.
> > ;-)  The firmware on this MB fails to save the boot order when I put the
> > DVD drive at the start, in front of the NVMEs (which are still called
> > "hard drives").  Thus the BIOS isn't perfect.

> > I'm still pretty sure that when I booted the machine for the first time,
> > the display was correct.  In particular, I remember noticing the offset
> > after I tried booting with the drm.edid_firmware kernel parameter for the
> > first time.

> I expect, but don't know, the embedded kernel drm.edid_firmware codes offer 
> some default resolution sizes and refresh rates.  If your monitor prefers e.g. 
> 59Hz as opposed to a default of 60Hz, you could experience the problems you 
> describe above.  I was thinking if you can get a correct display coming up 
> with the monitor connected directly to the graphics port, then you can capture 
> the EDID reported by the monitor and feed this to the kernel as an EDID file 
> instead.

That's not possible at the moment as the monitor is only DVI (or VGA),
and the new machine is HDMI or DisplayPort.

> > I think I should try to update the firmware, and see if that clears the
> > problem.

> The latest firmware is 7D75v1J and was released very recently.  It deals with 
> a security issue too, so it's advisable using this version sooner or later:

> https://www.msi.com/Motherboard/MAG-B650-TOMAHAWK-WIFI/support

Yes, I "updated" the firmware, even though it was already on that latest
version.  It didn't help.

> Besides trying the latest firmware, some other things to try:

> 1. Use a cable with the appropriate connectors at each end.  No KVM, no 
> intermediate adaptors, no extensions, nothing-in-between.  Then add one thing 
> at a time to see what makes a difference.

Not something I have at the moment, but I could try to get one next week.

> 2. Try reseting the monitor itself.  Usually there is some OSD menu to adjust 
> monitor settings, see if there is a 'Reset Display' or similar option.

I found this, but couldn't work out how to press the final GO button.

> 3. Check if the monitor display corrects itself by playing with refresh rates 
> using xrandr/xorg.conf/desktop GUI Display settings after you launch xfce.

I'll need to look into this.

> 4. You should not have to do this, but if the KVM consistently throws out the 
> offset then check if the monitor OSD has a screen adjustment submenu to tweak 
> the screen viewport and shift it to fit the monitor.

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.

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.
Maybe I should try resetting the CMOS ram.

> Let's hope one of these things delivers a working display for you.  :-)

Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Alan Mackenzie]

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.

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

> 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

        #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

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

[ .... ]

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

> 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.
> Maybe I should try resetting the CMOS ram.

> > Let's hope one of these things delivers a working display for you.  :-)

> Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Dale]

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.
>> 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.
>> 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
>
>         #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
>
> ..  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
> 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.
> :-(
>
> [ .... ]
>
>> 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.
>> 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.
>> Maybe I should try resetting the CMOS ram.
>>> Let's hope one of these things delivers a working display for you.  :-)
>> Thanks!


Just for giggles, I emerged that package and ran that command on my
system.  All my monitors are running at 1920 x 1080.  However, this is
my output. 


root@Gentoo-1 / # get-edid | parse-edid
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 1
No EDID on bus 2
No EDID on bus 4
No EDID on bus 5
2 potential busses found: 3 6
Will scan through until the first EDID is found.
Pass a bus number as an option to this program to go only for that one.
256-byte EDID successfully retrieved from i2c bus 3
Looks like i2c was successful. Have a good day.
Checksum Correct

Section "Monitor"
        Identifier "LS32B30"
        ModelName "LS32B30"
        VendorName "SAM"
        # Monitor Manufactured week 13 of 2024
        # EDID version 1.3
        # Digital Display
        DisplaySize 160 90
        Gamma 2.20
        Option "DPMS" "true"
        Horizsync 30-84
        VertRefresh 48-75
        # Maximum pixel clock is 180MHz
        #Not giving standard mode: 1280x720, 60Hz
        #Not giving standard mode: 1280x800, 60Hz
        #Not giving standard mode: 1280x1024, 60Hz
        #Not giving standard mode: 1440x900, 60Hz
        #Not giving standard mode: 1600x900, 60Hz
        #Not giving standard mode: 1680x1050, 60Hz
        #Not giving standard mode: 1152x864, 75Hz

        #Extension block found. Parsing...
        Modeline        "Mode 7" +hsync +vsync
        Modeline        "Mode 0" +hsync +vsync
        Modeline        "Mode 1" 148.500 1920 2008 2052 2200 1080 1084
1089 1125 +hsync +vsync
        Modeline        "Mode 2" 74.250 1280 1390 1420 1650 720 725 730
750 +hsync +vsync
        Modeline        "Mode 3" 148.500 1920 2448 2492 2640 1080 1084
1089 1125 +hsync +vsync
        Modeline        "Mode 4" 74.250 1280 1720 1760 1980 720 725 730
750 +hsync +vsync
        Modeline        "Mode 5" 27.027 720 736 798 858 480 489 495 525
-hsync -vsync
        Modeline        "Mode 6" 27.000 720 732 796 864 576 581 586 625
-hsync -vsync
        Modeline        "Mode 8" -hsync -vsync
        Modeline        "Mode 9" -hsync -vsync
        Modeline        "Mode 10" +hsync +vsync
        Option "PreferredMode" "Mode 7"
EndSection
root@Gentoo-1 / #


Even tho my monitor is working fine, no winking in a while now, the
resolution it is running at isn't listed either.  I might also add, I
have three monitors connected but only one is seen by that command. 

I'm wondering if there is something wonky with that program.  I'd expect
the resolution it is currently running at to be listed.  Given it is
not, I'd call that odd.  Or wonky.  ;-)  I might add, there is some
differences so it is seeing something.  It's not just spitting out the
same info no matter what. 

Odd. 

Dale

:-)  :-) 

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

[Michael]

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

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

[Michael]

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

On Sunday, 25 August 2024 14:53:21 BST Dale wrote:
> Alan Mackenzie wrote:

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

[Snip ...]
> Just for giggles, I emerged that package and ran that command on my
> system.  All my monitors are running at 1920 x 1080.  However, this is
> my output. 
> 
> 
> root@Gentoo-1 / # get-edid | parse-edid
> 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 1
> No EDID on bus 2
> No EDID on bus 4
> No EDID on bus 5
> 2 potential busses found: 3 6
> Will scan through until the first EDID is found.
> Pass a bus number as an option to this program to go only for that one.
> 256-byte EDID successfully retrieved from i2c bus 3
> Looks like i2c was successful. Have a good day.
> Checksum Correct
> 
> Section "Monitor"
>         Identifier "LS32B30"
>         ModelName "LS32B30"
>         VendorName "SAM"
>         # Monitor Manufactured week 13 of 2024
>         # EDID version 1.3
>         # Digital Display
>         DisplaySize 160 90
>         Gamma 2.20
>         Option "DPMS" "true"
>         Horizsync 30-84
>         VertRefresh 48-75
>         # Maximum pixel clock is 180MHz
>         #Not giving standard mode: 1280x720, 60Hz
>         #Not giving standard mode: 1280x800, 60Hz
>         #Not giving standard mode: 1280x1024, 60Hz
>         #Not giving standard mode: 1440x900, 60Hz
>         #Not giving standard mode: 1600x900, 60Hz
>         #Not giving standard mode: 1680x1050, 60Hz
>         #Not giving standard mode: 1152x864, 75Hz
> 
>         #Extension block found. Parsing...
>         Modeline        "Mode 7" +hsync +vsync
>         Modeline        "Mode 0" +hsync +vsync
>         Modeline        "Mode 1" 148.500 1920 2008 2052 2200 1080 1084
> 1089 1125 +hsync +vsync
>         Modeline        "Mode 2" 74.250 1280 1390 1420 1650 720 725 730
> 750 +hsync +vsync
>         Modeline        "Mode 3" 148.500 1920 2448 2492 2640 1080 1084
> 1089 1125 +hsync +vsync
>         Modeline        "Mode 4" 74.250 1280 1720 1760 1980 720 725 730
> 750 +hsync +vsync
>         Modeline        "Mode 5" 27.027 720 736 798 858 480 489 495 525
> -hsync -vsync
>         Modeline        "Mode 6" 27.000 720 732 796 864 576 581 586 625
> -hsync -vsync
>         Modeline        "Mode 8" -hsync -vsync
>         Modeline        "Mode 9" -hsync -vsync
>         Modeline        "Mode 10" +hsync +vsync
>         Option "PreferredMode" "Mode 7"
> EndSection
> root@Gentoo-1 / #
> 
> 
> Even tho my monitor is working fine, no winking in a while now, the
> resolution it is running at isn't listed either.

The resolution is listed - look at Mode 1 and Mode 3.  It is also providing a 
preferred Mode.


> I might also add, I
> have three monitors connected but only one is seen by that command. 

Check the line above stating "Will scan through until the first EDID is 
found."  For additional monitor EDID's you'll probably have to specify a 
different I2C bus number.


> I'm wondering if there is something wonky with that program.  I'd expect
> the resolution it is currently running at to be listed.  Given it is
> not, I'd call that odd.  Or wonky.  ;-)  I might add, there is some
> differences so it is seeing something.  It's not just spitting out the
> same info no matter what. 
> 
> Odd. 
> 
> Dale
> 
> :-)  :-) 

I recall you were using an adaptor for (some of?) your monitor cables.  
Adaptors can cause Modelines to not be detected at all or not detected fully.  
I should count myself lucky because I have not come across such problems at 
least since using VGA cables with CRT monitors.  ;-)

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

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

[Dale]

Michael wrote:
> On Sunday, 25 August 2024 14:53:21 BST Dale wrote:
>> Alan Mackenzie wrote:
>>> 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
>>>         
>>>         #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
> [Snip ...]
>> Just for giggles, I emerged that package and ran that command on my
>> system.  All my monitors are running at 1920 x 1080.  However, this is
>> my output. 
>>
>>
>> root@Gentoo-1 / # get-edid | parse-edid
>> 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 1
>> No EDID on bus 2
>> No EDID on bus 4
>> No EDID on bus 5
>> 2 potential busses found: 3 6
>> Will scan through until the first EDID is found.
>> Pass a bus number as an option to this program to go only for that one.
>> 256-byte EDID successfully retrieved from i2c bus 3
>> Looks like i2c was successful. Have a good day.
>> Checksum Correct
>>
>> Section "Monitor"
>>         Identifier "LS32B30"
>>         ModelName "LS32B30"
>>         VendorName "SAM"
>>         # Monitor Manufactured week 13 of 2024
>>         # EDID version 1.3
>>         # Digital Display
>>         DisplaySize 160 90
>>         Gamma 2.20
>>         Option "DPMS" "true"
>>         Horizsync 30-84
>>         VertRefresh 48-75
>>         # Maximum pixel clock is 180MHz
>>         #Not giving standard mode: 1280x720, 60Hz
>>         #Not giving standard mode: 1280x800, 60Hz
>>         #Not giving standard mode: 1280x1024, 60Hz
>>         #Not giving standard mode: 1440x900, 60Hz
>>         #Not giving standard mode: 1600x900, 60Hz
>>         #Not giving standard mode: 1680x1050, 60Hz
>>         #Not giving standard mode: 1152x864, 75Hz
>>
>>         #Extension block found. Parsing...
>>         Modeline        "Mode 7" +hsync +vsync
>>         Modeline        "Mode 0" +hsync +vsync
>>         Modeline        "Mode 1" 148.500 1920 2008 2052 2200 1080 1084
>> 1089 1125 +hsync +vsync
>>         Modeline        "Mode 2" 74.250 1280 1390 1420 1650 720 725 730
>> 750 +hsync +vsync
>>         Modeline        "Mode 3" 148.500 1920 2448 2492 2640 1080 1084
>> 1089 1125 +hsync +vsync
>>         Modeline        "Mode 4" 74.250 1280 1720 1760 1980 720 725 730
>> 750 +hsync +vsync
>>         Modeline        "Mode 5" 27.027 720 736 798 858 480 489 495 525
>> -hsync -vsync
>>         Modeline        "Mode 6" 27.000 720 732 796 864 576 581 586 625
>> -hsync -vsync
>>         Modeline        "Mode 8" -hsync -vsync
>>         Modeline        "Mode 9" -hsync -vsync
>>         Modeline        "Mode 10" +hsync +vsync
>>         Option "PreferredMode" "Mode 7"
>> EndSection
>> root@Gentoo-1 / #
>>
>>
>> Even tho my monitor is working fine, no winking in a while now, the
>> resolution it is running at isn't listed either.
> The resolution is listed - look at Mode 1 and Mode 3.  It is also providing a 
> preferred Mode.
>

Ahhhhh.  I was looking further up at the other list. 


>> I might also add, I
>> have three monitors connected but only one is seen by that command. 
> Check the line above stating "Will scan through until the first EDID is 
> found."  For additional monitor EDID's you'll probably have to specify a 
> different I2C bus number.
>
>
>> I'm wondering if there is something wonky with that program.  I'd expect
>> the resolution it is currently running at to be listed.  Given it is
>> not, I'd call that odd.  Or wonky.  ;-)  I might add, there is some
>> differences so it is seeing something.  It's not just spitting out the
>> same info no matter what. 
>>
>> Odd. 
>>
>> Dale
>>
>> :-)  :-) 
> I recall you were using an adaptor for (some of?) your monitor cables.  
> Adaptors can cause Modelines to not be detected at all or not detected fully.  
> I should count myself lucky because I have not come across such problems at 
> least since using VGA cables with CRT monitors.  ;-)

At that time, I was using a adapter.  Odd thing is, it works on the new
monitors but not the old monitors.  On one of the new monitors, I had it
wink at me on occasion.  Since I replaced that cable, it hasn't winked
since.  That said, it did the same with other adapters but the same
adapter, bought at the same time, with the other monitor works fine.  As
one can see tho, it can be problematic and confusing.  I think in this
one case tho, it was the cable from the adapter to the monitor that was
bad. 

I still use those adapters on other machines with no problems.  Still,
it does add one more source for a problem.  I just hated to buy yet
another set of pricey cables when I got so many HDMI cables laying
around.  I got a shelf full of miscellaneous cables and wires.  Not one
of them was a display port type.  I got some now tho.  ;-) 

Dale

:-)  :-) 

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

[Alan Mackenzie]

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

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

[Dale]

Alan Mackenzie wrote:
>
> 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.
>
>

Do you have x11-apps/xrandr installed?  If you do, see what this says. 


xrandr --listmonitors


This is mine:


root@Gentoo-1 / # xrandr --listmonitors
Monitors: 3
 0: +*DP-2 1920/698x1080/393+0+1080  DP-2
 1: +DP-1 1920/698x1080/393+0+0  DP-1
 2: +DP-7 1920/1150x1080/650+1920+1080  DP-7
root@Gentoo-1 / #


DP-2 is my primary display and if you have only one monitor, should be
the only line for you but might be DP-1 instead.  Micheal might can
explain this better, or even more correctly, but I think the important
part for this is where mine says +0+.  I think, just think, if yours
says something like +192+ instead of 0, that might be a clue.  If it
says 0 as it should, then this may be the wrong track to look down. 
What I'm wondering, is the monitor set to show a blank, or black,
section on that side for some reason.  This could very well not be the
case tho.  If it shows correctly like mine does, then ignore this and
know that isn't causing the problem at least. 

This is a odd problem.  I don't think I ever saw this even during the
old CRT days.  o_O

Dale

:-)  :-) 

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

[Alan Mackenzie]

Hello, Dale

On Sun, Aug 25, 2024 at 13:28:14 -0500, Dale wrote:
> Alan Mackenzie wrote:

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

> Do you have x11-apps/xrandr installed?  If you do, see what this says. 

I didn't, but I do now.  After trying (and failing) to run it on the
console, I tried in X-Windows (the display of which is miserably
unstable at the moment).

> xrandr --listmonitors


> This is mine:


> root@Gentoo-1 / # xrandr --listmonitors
> Monitors: 3
>  0: +*DP-2 1920/698x1080/393+0+1080  DP-2
>  1: +DP-1 1920/698x1080/393+0+0  DP-1
>  2: +DP-7 1920/1150x1080/650+1920+1080  DP-7
> root@Gentoo-1 / #

That's one tremendous monitor you've got on DP-7.  :-)

I've got just the one monitor.  I got back:

0: +*HDMI-A-0 1920/521x1080/293+0+0  HDMI-A-0

> DP-2 is my primary display and if you have only one monitor, should be
> the only line for you but might be DP-1 instead.  Micheal might can
> explain this better, or even more correctly, but I think the important
> part for this is where mine says +0+.  I think, just think, if yours
> says something like +192+ instead of 0, that might be a clue.  If it
> says 0 as it should, then this may be the wrong track to look down. 
> What I'm wondering, is the monitor set to show a blank, or black,
> section on that side for some reason.  This could very well not be the
> case tho.  If it shows correctly like mine does, then ignore this and
> know that isn't causing the problem at least. 

No, I've got the +0+, too.

> This is a odd problem.  I don't think I ever saw this even during the
> old CRT days.  o_O

I'm convinced this isn't a problem in Linux.  It's something having got
wedged in the motherboard's firmware, seeing as how the blank strip
appears even when going into the BIOS.  I suspect I'm going to have to
reinitialise the CMOS ram, which I really don't want to do, though
Michael doesn't think that's the problem.  We'll see.

> Dale

> :-)  :-) 

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Dale]

Alan Mackenzie wrote:
> Hello, Dale
>
> On Sun, Aug 25, 2024 at 13:28:14 -0500, Dale wrote:
>> Alan Mackenzie wrote:
>>> 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.
>> Do you have x11-apps/xrandr installed?  If you do, see what this says. 
> I didn't, but I do now.  After trying (and failing) to run it on the
> console, I tried in X-Windows (the display of which is miserably
> unstable at the moment).
>
>> xrandr --listmonitors
>
>> This is mine:
>
>> root@Gentoo-1 / # xrandr --listmonitors
>> Monitors: 3
>>  0: +*DP-2 1920/698x1080/393+0+1080  DP-2
>>  1: +DP-1 1920/698x1080/393+0+0  DP-1
>>  2: +DP-7 1920/1150x1080/650+1920+1080  DP-7
>> root@Gentoo-1 / #
> That's one tremendous monitor you've got on DP-7.  :-)
>
> I've got just the one monitor.  I got back:
>
> 0: +*HDMI-A-0 1920/521x1080/293+0+0  HDMI-A-0

If I read that and my thinking is right, that is what it should be.  I
don't completely understand everything that output is saying.  But, I
technically have three monitors.  I have two in front of me that have
different displays.  Those are DP2 and DP-2.  The third, DP-7, is my TV
that I watch.  It goes to a splitter which goes to a TV in my bedroom
and one in the living room.  I can cook, clean etc while watching TV. 
DP-7 is to the right of DP-2 which may be why it shows something larger. 

Some of this monitor stuff is a bit confusing. 


>> DP-2 is my primary display and if you have only one monitor, should be
>> the only line for you but might be DP-1 instead.  Micheal might can
>> explain this better, or even more correctly, but I think the important
>> part for this is where mine says +0+.  I think, just think, if yours
>> says something like +192+ instead of 0, that might be a clue.  If it
>> says 0 as it should, then this may be the wrong track to look down. 
>> What I'm wondering, is the monitor set to show a blank, or black,
>> section on that side for some reason.  This could very well not be the
>> case tho.  If it shows correctly like mine does, then ignore this and
>> know that isn't causing the problem at least. 
> No, I've got the +0+, too.
>
>> This is a odd problem.  I don't think I ever saw this even during the
>> old CRT days.  o_O
> I'm convinced this isn't a problem in Linux.  It's something having got
> wedged in the motherboard's firmware, seeing as how the blank strip
> appears even when going into the BIOS.  I suspect I'm going to have to
> reinitialise the CMOS ram, which I really don't want to do, though
> Michael doesn't think that's the problem.  We'll see.
>
>> Dale
>> :-)  :-) 
>

Ahhhhh.  If it does it in the BIOS, it's either a monitor or video card,
or mobo if video is built in, problem.  If a monitor isn't right in the
BIOS screen, odds are it won't be when booted either.  Can you install a
video card and test?  If it works, mobo has a video driver problem.  If
not, could be monitor or cables or something. 

At least we know one thing it isn't.  ;-) 

Dale

:-)  :-) 

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

[Michael]

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

On Sunday, 25 August 2024 20:37:37 BST Dale wrote:
> Alan Mackenzie wrote:
> > Hello, Dale
> > 
> > On Sun, Aug 25, 2024 at 13:28:14 -0500, Dale wrote:
> >> Alan Mackenzie wrote:
> >>> 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.
> >> 
> >> Do you have x11-apps/xrandr installed?  If you do, see what this says. 
> > 
> > I didn't, but I do now.  After trying (and failing) to run it on the
> > console, I tried in X-Windows (the display of which is miserably
> > unstable at the moment).
> > 
> >> xrandr --listmonitors
> >> 
> >> This is mine:
> >> 
> >> root@Gentoo-1 / # xrandr --listmonitors
> >> Monitors: 3
> >>  0: +*DP-2 1920/698x1080/393+0+1080  DP-2
> >>  1: +DP-1 1920/698x1080/393+0+0  DP-1
> >>  2: +DP-7 1920/1150x1080/650+1920+1080  DP-7
> >> root@Gentoo-1 / #
> > 
> > That's one tremendous monitor you've got on DP-7.  :-)
> > 
> > I've got just the one monitor.  I got back:
> > 
> > 0: +*HDMI-A-0 1920/521x1080/293+0+0  HDMI-A-0
> 
> If I read that and my thinking is right, that is what it should be.

Yes.

> I
> don't completely understand everything that output is saying.  But, I
> technically have three monitors.  I have two in front of me that have
> different displays.  Those are DP2 and DP-2.  The third, DP-7, is my TV
> that I watch.  It goes to a splitter which goes to a TV in my bedroom
> and one in the living room.  I can cook, clean etc while watching TV. 
> DP-7 is to the right of DP-2 which may be why it shows something larger. 
> 
> Some of this monitor stuff is a bit confusing. 
> 
> >> DP-2 is my primary display and if you have only one monitor, should be
> >> the only line for you but might be DP-1 instead.  Micheal might can
> >> explain this better, or even more correctly, but I think the important
> >> part for this is where mine says +0+.  I think, just think, if yours
> >> says something like +192+ instead of 0, that might be a clue.  If it
> >> says 0 as it should, then this may be the wrong track to look down. 
> >> What I'm wondering, is the monitor set to show a blank, or black,
> >> section on that side for some reason.  This could very well not be the
> >> case tho.  If it shows correctly like mine does, then ignore this and
> >> know that isn't causing the problem at least. 
> > 
> > No, I've got the +0+, too.
> > 
> >> This is a odd problem.  I don't think I ever saw this even during the
> >> old CRT days.  o_O
> > 
> > I'm convinced this isn't a problem in Linux.  It's something having got
> > wedged in the motherboard's firmware, seeing as how the blank strip
> > appears even when going into the BIOS.

The plot thickens!  If the resolution in the BIOS menu is also wrong and 
offset, it sounds like an MSI bug of sorts - "Try disabling CSM" in your UEFI 
settings:

https://forums.tomshardware.com/threads/low-resolution-boot-uefi-bios.3530375/

https://superuser.com/questions/1209012/uefi-and-therefore-linux-console-isnt-displayed-at-native-resolution

I have no idea why CSM affects the video resolution of the firmware, but it 
may have to do with how much space is available on the NOR flash chip where 
the UEFI firmware is stored.  Enabling CSM may be eating up some/more 
resources, leaving less to initialise and run the graphics capability of the 
MoBo.  :-/


> > I suspect I'm going to have to
> > reinitialise the CMOS ram, which I really don't want to do, though
> > Michael doesn't think that's the problem.  We'll see.

I wasn't aware this display issue is present *before* the OS has even loaded.  
This is not a linux issue and the linux driver itself does not seem able to 
correct it.

OK, in the first instance disable the CMS in the UEFI settings and reboot.  
Some boards do not lose some of their cached settings when you simply 
shutdown.  Remove the power cable, depress and hold the power button for 10-20 
seconds.  Any capacitors will discharge.  Reconnect the power and boot 
normally.

If the above gymnastics do not fix it, then you'll have to try resetting the 
MoBo.  Make a note of any changed settings and check the CSM option is left 
disabled.


> Ahhhhh.  If it does it in the BIOS, it's either a monitor or video card,
> or mobo if video is built in, problem.

On modern APUs video graphics chips are integrated within the CPU die itself 
as separate graphics cores.


> If a monitor isn't right in the
> BIOS screen, odds are it won't be when booted either.  Can you install a
> video card and test?  If it works, mobo has a video driver problem.  If
> not, could be monitor or cables or something. 
> 
> At least we know one thing it isn't.  ;-) 
> 
> Dale
> 
> :-)  :-) 

Let's hope this is an MSI/CSM specific issue rather than a hardware fault.

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

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

[Alan Mackenzie]

Hello, Dale.

On Sun, Aug 25, 2024 at 14:37:37 -0500, Dale wrote:
> Alan Mackenzie wrote:
> > Hello, Dale

> > On Sun, Aug 25, 2024 at 13:28:14 -0500, Dale wrote:
> >> Alan Mackenzie wrote:
> >>> 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.
> >> Do you have x11-apps/xrandr installed?  If you do, see what this says. 
> > I didn't, but I do now.  After trying (and failing) to run it on the
> > console, I tried in X-Windows (the display of which is miserably
> > unstable at the moment).

> >> xrandr --listmonitors

> >> This is mine:

> >> root@Gentoo-1 / # xrandr --listmonitors
> >> Monitors: 3
> >>  0: +*DP-2 1920/698x1080/393+0+1080  DP-2
> >>  1: +DP-1 1920/698x1080/393+0+0  DP-1
> >>  2: +DP-7 1920/1150x1080/650+1920+1080  DP-7
> >> root@Gentoo-1 / #
> > That's one tremendous monitor you've got on DP-7.  :-)

> > I've got just the one monitor.  I got back:

> > 0: +*HDMI-A-0 1920/521x1080/293+0+0  HDMI-A-0

> If I read that and my thinking is right, that is what it should be.  I
> don't completely understand everything that output is saying.  But, I
> technically have three monitors.  I have two in front of me that have
> different displays.  Those are DP2 and DP-2.  The third, DP-7, is my TV
> that I watch.  It goes to a splitter which goes to a TV in my bedroom
> and one in the living room.  I can cook, clean etc while watching TV. 
> DP-7 is to the right of DP-2 which may be why it shows something larger. 

> Some of this monitor stuff is a bit confusing. 

I won't disagree with you there.

> >> DP-2 is my primary display and if you have only one monitor, should be
> >> the only line for you but might be DP-1 instead.  Micheal might can
> >> explain this better, or even more correctly, but I think the important
> >> part for this is where mine says +0+.  I think, just think, if yours
> >> says something like +192+ instead of 0, that might be a clue.  If it
> >> says 0 as it should, then this may be the wrong track to look down. 
> >> What I'm wondering, is the monitor set to show a blank, or black,
> >> section on that side for some reason.  This could very well not be the
> >> case tho.  If it shows correctly like mine does, then ignore this and
> >> know that isn't causing the problem at least. 
> > No, I've got the +0+, too.

> >> This is a odd problem.  I don't think I ever saw this even during the
> >> old CRT days.  o_O
> > I'm convinced this isn't a problem in Linux.  It's something having got
> > wedged in the motherboard's firmware, seeing as how the blank strip
> > appears even when going into the BIOS.  I suspect I'm going to have to
> > reinitialise the CMOS ram, which I really don't want to do, though
> > Michael doesn't think that's the problem.  We'll see.

> >> Dale
> >> :-)  :-) 


> Ahhhhh.  If it does it in the BIOS, it's either a monitor or video card,
> or mobo if video is built in, problem.  If a monitor isn't right in the
> BIOS screen, odds are it won't be when booted either.  Can you install a
> video card and test?  If it works, mobo has a video driver problem.  If
> not, could be monitor or cables or something. 

> At least we know one thing it isn't.  ;-) 

I got a shop to build this machine for me, and I'm confident they would
have tested it.  It was working fine when I got it.

I'm 95% sure the problem happened when I tried out the drm.edid_firmware
kernel parameter, in an attempt to get my video going.  Actually, I'm
less sure now, having looked at my notes from last Monday, the day I got
then new box.  I got the basics installed on Monday, and then (according
to my notes) was trying to fix this damned video problem in the middle of
the night, Monday night.  That was surely before I started messing with
kernel parameters.  :-(

I honestly don't think it's the hardware at fault.  There are exactly 192
extra pixel rows shown in the output from twiddling the switches on the
front of the monitor, and the display with a console is stable and
moderately usable (in contrast to the X Windows display which goes blank
several times a minute).  192 is 16 x 12, far too round a number to be
happening through HW failure.  Likewise, there are 36 too many extra
pixel columns, also a very round number.

Yet, all the time both the BIOS firmware and the Linux framebuffer think
they're working at 1920x1080.  My bet is a bug in the BIOS firmware.
Anyhow, I opened a support request to MSI on Friday, so I hope they'll
come back to me some time early this week.


> Dale

> :-)  :-) 

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Peter Humphrey]

On Sunday, 25 August 2024 22:04:05 BST Michael wrote:

> Let's hope this is an MSI/CSM specific issue rather than a hardware fault.

I bought an MSI "gaming" monitor recently, and it seems not at all happy at 
being connected through a KVM switch. I haven't looked into that yet.

-- 
Regards,
Peter.

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

[Alan Mackenzie]

Hello, Michael.

On Sun, Aug 25, 2024 at 22:04:05 +0100, Michael wrote:
> On Sunday, 25 August 2024 20:37:37 BST Dale wrote:
> > Alan Mackenzie wrote:

[ .... ]

> > > I'm convinced this isn't a problem in Linux.  It's something having got
> > > wedged in the motherboard's firmware, seeing as how the blank strip
> > > appears even when going into the BIOS.

> The plot thickens!  If the resolution in the BIOS menu is also wrong and 
> offset, it sounds like an MSI bug of sorts - "Try disabling CSM" in your UEFI 
> settings:

> https://forums.tomshardware.com/threads/low-resolution-boot-uefi-bios.3530375/

> https://superuser.com/questions/1209012/uefi-and-therefore-linux-console-isnt-displayed-at-native-resolution

> I have no idea why CSM affects the video resolution of the firmware, but it 
> may have to do with how much space is available on the NOR flash chip where 
> the UEFI firmware is stored.  Enabling CSM may be eating up some/more 
> resources, leaving less to initialise and run the graphics capability of the 
> MoBo.  :-/

The CSM setting actually can't be enabled on my MB for some reason.  I
tried, but it wouldn't go.  Worth a try, but it hasn't gone anywhere.

> > > I suspect I'm going to have to reinitialise the CMOS ram, which I
> > > really don't want to do, though Michael doesn't think that's the
> > > problem.  We'll see.

> I wasn't aware this display issue is present *before* the OS has even loaded.  
> This is not a linux issue and the linux driver itself does not seem able to 
> correct it.

> OK, in the first instance disable the CMS in the UEFI settings and reboot.  
> Some boards do not lose some of their cached settings when you simply 
> shutdown.  Remove the power cable, depress and hold the power button for 10-20 
> seconds.  Any capacitors will discharge.  Reconnect the power and boot 
> normally.

That didn't help either, I'm afraid.

I've had a reply from MSI's support.  It's along the lines of "buy new
cables, don't use an adapter, and don't use a KVM box".  In other words,
not at all useful.  I'm trying to work out whether it's worth trying to
supply MSI with the extra information about the excess numbers of pixels
being multiples of 16 in both the horizontal and vertical directions.  I
suspect I'll just get the runaround from them, no matter what.

Or, I could go back to the shop that built the machine.  Maybe I should
try it connected directly to an HDMI monitor.

> If the above gymnastics do not fix it, then you'll have to try resetting the 
> MoBo.  Make a note of any changed settings and check the CSM option is left 
> disabled.

I think this is what I will try next.  I don't know which of the settings
has been changed, so I'll need to make a note of practically every
setting.  Most of them are still defaults.

> > Ahhhhh.  If it does it in the BIOS, it's either a monitor or video card,
> > or mobo if video is built in, problem.

> On modern APUs video graphics chips are integrated within the CPU die itself 
> as separate graphics cores.

It seems such a graphic core is supplying 2112x1116@60Hz, rather than the
correct 1920x1080@60Hz.  Hopefully the fault is in the firmware, not in
the graphics unit.  ;-(

[ .... ]

> Let's hope this is an MSI/CSM specific issue rather than a hardware fault.

Given MSI support's attitude, it's looking like my machine is going back
to the shop that made it, unless resetting the CMOS RAM does the job.
That's the thing to try out next.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Michael]

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

On Monday, 26 August 2024 11:40:43 BST Alan Mackenzie wrote:
> Hello, Michael.
> 
> On Sun, Aug 25, 2024 at 22:04:05 +0100, Michael wrote:

[snip ...]
> > OK, in the first instance disable the CMS in the UEFI settings and reboot.
> > Some boards do not lose some of their cached settings when you simply
> > shutdown.  Remove the power cable, depress and hold the power button for
> > 10-20 seconds.  Any capacitors will discharge.  Reconnect the power and
> > boot normally.
> 
> That didn't help either, I'm afraid.

:-(

> I've had a reply from MSI's support.  It's along the lines of "buy new
> cables, don't use an adapter, and don't use a KVM box".  In other words,
> not at all useful.  I'm trying to work out whether it's worth trying to
> supply MSI with the extra information about the excess numbers of pixels
> being multiples of 16 in both the horizontal and vertical directions.  I
> suspect I'll just get the runaround from them, no matter what.

Yes, I suspected this would be their default response.  If there is a known 
problem and a fix or workaround, OEMs will advise of it usually in their FAQs.  
On a newly released product they may ask for additional information.  
Otherwise they are unlikely to engage in troubleshooting with retail users and 
tend to point at anything else but their product.  ;-)


> Or, I could go back to the shop that built the machine.  Maybe I should
> try it connected directly to an HDMI monitor.

If you have a monitor with the same connector as your graphics card (DP or 
HDMI) then you can test the health of the new PC with it.  However, if you 
must use the KVM and DVI-HDMI adaptor, then the options are limited.


> > If the above gymnastics do not fix it, then you'll have to try resetting
> > the MoBo.  Make a note of any changed settings and check the CSM option
> > is left disabled.
> 
> I think this is what I will try next.  I don't know which of the settings
> has been changed, so I'll need to make a note of practically every
> setting.  Most of them are still defaults.

Depending on the MoBo you can usually create a backup file with all the 
firmware settings and reload it later on, after you reset the MoBo and 
finished with your tests.


> > > Ahhhhh.  If it does it in the BIOS, it's either a monitor or video card,
> > > or mobo if video is built in, problem.
> > 
> > On modern APUs video graphics chips are integrated within the CPU die
> > itself as separate graphics cores.
> 
> It seems such a graphic core is supplying 2112x1116@60Hz, rather than the
> correct 1920x1080@60Hz.  Hopefully the fault is in the firmware, not in
> the graphics unit.  ;-(

If this is the problem then you should be able to set your desktop to a 
1920x1080 resolution.  I am not familiar with xfce but there will be some 
display setting to adjust the resolution with.

> 
> [ .... ]
> 
> > Let's hope this is an MSI/CSM specific issue rather than a hardware fault.
> 
> Given MSI support's attitude, it's looking like my machine is going back
> to the shop that made it, unless resetting the CMOS RAM does the job.
> That's the thing to try out next.

Another thing to try to confirm is if the EDID of the monitor is correct:

Emerge sys-apps/edid-decode, then capture the EDID of the monitor with get-
edid in a file and feed it to 'edid-decode -p'.  It will parse the file and 
output a human readable output.  Then you can see what the preferred 
resolution is as far as the monitor EDID content is concerned, or if it is 
indeed missing as you reported previously.

You can also read Xorg.0.log to find out what your xorg driver reports.

The recurring flickering of the display after you've loaded your desktop shows 
the linux OS is trying to re-adjust the display.  Usually this happens when 
the connection/power to the monitor is disrupted, which again points to a 
connector issue, or it can also happen if you specified in your GUI the wrong 
resolution/frequency.

Due to my ham-fisted attempts to connect a DVI adaptor behind a monitor 
without being able to see what I was doing, I recall bending one of the 
terminals at the DVI connector.  This was giving spurious results.  I had to 
straighten the terminal carefully with long nose pliers, before I was able to 
use the monitor properly.  Check if your connectors have suffered something 
similar.

Other than the above, I'm out of ideas.  :-(

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

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

[Alan Mackenzie]

Hello, Michael.

On Mon, Aug 26, 2024 at 12:54:20 +0100, Michael wrote:
> On Monday, 26 August 2024 11:40:43 BST Alan Mackenzie wrote:
> > Hello, Michael.

> > On Sun, Aug 25, 2024 at 22:04:05 +0100, Michael wrote:

> > I've had a reply from MSI's support.  It's along the lines of "buy new
> > cables, don't use an adapter, and don't use a KVM box".  In other words,
> > not at all useful.  I'm trying to work out whether it's worth trying to
> > supply MSI with the extra information about the excess numbers of pixels
> > being multiples of 16 in both the horizontal and vertical directions.  I
> > suspect I'll just get the runaround from them, no matter what.

> Yes, I suspected this would be their default response.  If there is a known 
> problem and a fix or workaround, OEMs will advise of it usually in their FAQs.  
> On a newly released product they may ask for additional information.  
> Otherwise they are unlikely to engage in troubleshooting with retail users and 
> tend to point at anything else but their product.  ;-)

I'm beginning to think getting an MSI board was a mistake.

> > Or, I could go back to the shop that built the machine.  Maybe I should
> > try it connected directly to an HDMI monitor.

That's what I'm going to be doing tomorrow, after I 'phoned them up this
afternoon.

> If you have a monitor with the same connector as your graphics card (DP or 
> HDMI) then you can test the health of the new PC with it.  However, if you 
> must use the KVM and DVI-HDMI adaptor, then the options are limited.

Well, I'm loathe to throw away my still well working monitor after all
these years.  We have enough electronic waste as it is.  Yes, I need to
use the KVM and either an HDMI->DVI or a DisplayPort->DVI adapter (which
I haven't tried, yet).

> > I think this is what I will try next.  I don't know which of the settings
> > has been changed, so I'll need to make a note of practically every
> > setting.  Most of them are still defaults.

> Depending on the MoBo you can usually create a backup file with all the 
> firmware settings and reload it later on, after you reset the MoBo and 
> finished with your tests.

I tried resetting the CMOS, but it didn't do any good.

> > > > Ahhhhh.  If it does it in the BIOS, it's either a monitor or video card,
> > > > or mobo if video is built in, problem.

> > > On modern APUs video graphics chips are integrated within the CPU die
> > > itself as separate graphics cores.

> > It seems such a graphic core is supplying 2112x1116@60Hz, rather than the
> > correct 1920x1080@60Hz.  Hopefully the fault is in the firmware, not in
> > the graphics unit.  ;-(

> If this is the problem then you should be able to set your desktop to a 
> 1920x1080 resolution.  I am not familiar with xfce but there will be some 
> display setting to adjust the resolution with.

No, the graphics HW is sending out physically 2112x1116, but logically
1920x1080.  The gap between the 1920 pixels and the 2112 pixels on each
line is taken up by the nasty gap.

> > [ .... ]

> > > Let's hope this is an MSI/CSM specific issue rather than a hardware fault.

> > Given MSI support's attitude, it's looking like my machine is going back
> > to the shop that made it, unless resetting the CMOS RAM does the job.
> > That's the thing to try out next.

> Another thing to try to confirm is if the EDID of the monitor is correct:

> Emerge sys-apps/edid-decode, then capture the EDID of the monitor with get-
> edid in a file and feed it to 'edid-decode -p'.  It will parse the file and 
> output a human readable output.  Then you can see what the preferred 
> resolution is as far as the monitor EDID content is concerned, or if it is 
> indeed missing as you reported previously.

It would appear to be (something like)

    DTD 1: 1920x1080 60Hz.

(Sorry, I can't be bothered to copy it over on a USB stick at the moment,
but it looks plausible).

> You can also read Xorg.0.log to find out what your xorg driver reports.

Lots of 1920x1080s, yes.  No 2112x1116.  The entire software, including
the BIOS thinks its running on 1920x1080, just the hardware is pumping
out 2112x1116.  Maybe there's something nasty in my HDMI->DVI adapter,
but I wouldn't have thought so.

> The recurring flickering of the display after you've loaded your desktop shows 
> the linux OS is trying to re-adjust the display.  Usually this happens when 
> the connection/power to the monitor is disrupted, which again points to a 
> connector issue, or it can also happen if you specified in your GUI the wrong 
> resolution/frequency.

Yes.  I think the connectors are OK, but maybe we'll see how the machine
performs differently at the shop tomorrow.

> Due to my ham-fisted attempts to connect a DVI adaptor behind a monitor 
> without being able to see what I was doing, I recall bending one of the 
> terminals at the DVI connector.  This was giving spurious results.  I had to 
> straighten the terminal carefully with long nose pliers, before I was able to 
> use the monitor properly.  Check if your connectors have suffered something 
> similar.

No, I think both sides of the KVM are OK.  They both work OK with my
current computer.

> Other than the above, I'm out of ideas.  :-(

Well thanks a great deal for all the helpful suggestions so far.  My top
theory at the moment is that some of my kernel experiments irreversibly
set something on the MB which is causing the gap.  We'll see what happens
tomorrow when the machine gets connected up directly to an HDMI or DP
socket.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Alan Mackenzie]

Hello, everybody.

On Mon, Aug 26, 2024 at 14:49:14 +0000, Alan Mackenzie wrote:
> On Mon, Aug 26, 2024 at 12:54:20 +0100, Michael wrote:
> > On Monday, 26 August 2024 11:40:43 BST Alan Mackenzie wrote:
> > > On Sun, Aug 25, 2024 at 22:04:05 +0100, Michael wrote:

> I'm beginning to think getting an MSI board was a mistake.

I'm still thinking that.

> > > Or, I could go back to the shop that built the machine.  Maybe I
> > > should try it connected directly to an HDMI monitor.

OK, I'm just back from the shop.  The technician there plugged the
machine into an HDMI monitor, and it just worked.  Before leaving, I
assured him that I _would_ get the machine working, even if that might
involve buying a new monitor.  ;-(

When I got back home again and plugged in the new machine, it was
slightly different.  It was still pumping out 2112x1116, but the 2" gap
has become a 1" gap on both the left hand and the right hand sides.
There's still a (smaller) gap at the top.  I haven't yet tried booting
into Linux.

At least we now have an indication of something "analog" perhaps not
being in order.  I'm thinking that perhaps my HDMI->DVI adapter is
broken.  I should have bought a new one while I was at the shop, just to
test.  I did have trouble with Windows laptops when I plugged them in
via this adapter a couple of years ago.  Maybe I'll go back to the shop
to get that new HDMI->DVI adapter tomorrow.

There might still be errors in the MSI's BIOS firmware's handling of the
EDID, I still think that.

[ .... ]

>> Another thing to try to confirm is if the EDID of the monitor is
>> correct:

>> Emerge sys-apps/edid-decode, then capture the EDID of the monitor
>> with get- edid in a file and feed it to 'edid-decode -p'.  It will
>> parse the file and output a human readable output.  Then you can see
>> what the preferred resolution is as far as the monitor EDID content
>> is concerned, or if it is indeed missing as you reported previously.

After reading the fine manual page, I tried edid-decode -pc, the -c
meaninguto check the correctness of the EDID.  It output a warning and
(attleastdone)efault - something about some indicated resolutions'
verticallsyncptimetlying(outside the given bounds.

The diagnostics look like this:

Warnings:

Block 1, CTA-861 Extension Block:
  Display Product Serial Number is set, so the Serial Number in the Base EDID should be 0.
  Add a Colorimetry Data Block with the sRGB colorimetry bit set to avoid interop issues.

Failures:

Block 1, CTA-861 Extension Block:
  Missing VCDB, needed for Set Selectable RGB Quantization to avoid interop issues.
EDID:
  Base EDID: Some timings are out of range of the Monitor Ranges:
    Vertical Freq: 50.000 - 75.062 Hz (Monitor: 56.000 - 75.000 Hz)

EDID conformity: FAIL

[ .... ]

> > The recurring flickering of the display after you've loaded your desktop shows 
> > the linux OS is trying to re-adjust the display.  Usually this happens when 
> > the connection/power to the monitor is disrupted, which again points to a 
> > connector issue, or it can also happen if you specified in your GUI the wrong 
> > resolution/frequency.

> Yes.  I think the connectors are OK, but maybe we'll see how the machine
> performs differently at the shop tomorrow.

I've decided I'm definitely going to get a new HDMI->DVI adapter.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Michael]

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

On Tuesday, 27 August 2024 17:05:26 BST Alan Mackenzie wrote:
> Hello, everybody.
> 
> On Mon, Aug 26, 2024 at 14:49:14 +0000, Alan Mackenzie wrote:
> > On Mon, Aug 26, 2024 at 12:54:20 +0100, Michael wrote:
> > > On Monday, 26 August 2024 11:40:43 BST Alan Mackenzie wrote:
> > > > On Sun, Aug 25, 2024 at 22:04:05 +0100, Michael wrote:
> > I'm beginning to think getting an MSI board was a mistake.
> 
> I'm still thinking that.
> 
> > > > Or, I could go back to the shop that built the machine.  Maybe I
> > > > should try it connected directly to an HDMI monitor.
> 
> OK, I'm just back from the shop.  The technician there plugged the
> machine into an HDMI monitor, and it just worked.  Before leaving, I
> assured him that I _would_ get the machine working, even if that might
> involve buying a new monitor.  ;-(

Well, that's a different monitor and the cable was an HDMI-to-HDMI cable (I 
assume?).  Since you went to all this trouble it would be better if you 
dragged your monitor along with you.  Either way, I admire your doggedness to 
get to the bottom of this.  :-)


> When I got back home again and plugged in the new machine, it was
> slightly different.  It was still pumping out 2112x1116, but the 2" gap
> has become a 1" gap on both the left hand and the right hand sides.
> There's still a (smaller) gap at the top.  I haven't yet tried booting
> into Linux.
> 
> At least we now have an indication of something "analog" perhaps not
> being in order.  I'm thinking that perhaps my HDMI->DVI adapter is
> broken.  I should have bought a new one while I was at the shop, just to
> test.  I did have trouble with Windows laptops when I plugged them in
> via this adapter a couple of years ago.  Maybe I'll go back to the shop
> to get that new HDMI->DVI adapter tomorrow.

It would be best if you could buy a cable with the requisite HDMI on one end 
and a DVI-D on the other.  DVI-DL is capable of higher than 1920x1080 
resolutions, although the optimal resolution of your panel is at 1920x1080.


> There might still be errors in the MSI's BIOS firmware's handling of the
> EDID, I still think that.
> 
> [ .... ]
> 
> >> Another thing to try to confirm is if the EDID of the monitor is
> >> correct:
> >> 
> >> Emerge sys-apps/edid-decode, then capture the EDID of the monitor
> >> with get- edid in a file and feed it to 'edid-decode -p'.  It will
> >> parse the file and output a human readable output.  Then you can see
> >> what the preferred resolution is as far as the monitor EDID content
> >> is concerned, or if it is indeed missing as you reported previously.
> 
> After reading the fine manual page, I tried edid-decode -pc, the -c
> meaninguto check the correctness of the EDID.  It output a warning and
> (attleastdone)efault - something about some indicated resolutions'
> verticallsyncptimetlying(outside the given bounds.

Normally warnings and errors reported by the DDC check can be overcome by the 
graphics and/or Xorg drivers.  I have monitors here which complain about all 
sorts of warnings and errors and fail the DDC compatibility check, but still 
work fine *and* display a more accurate picture (chromatically) than other 
monitors which pass the EDID/DDC check and post no warnings.  Go figure ...  
:-/


> The diagnostics look like this:
> 
> Warnings:
> 
> Block 1, CTA-861 Extension Block:
>   Display Product Serial Number is set, so the Serial Number in the Base
> EDID should be 0. Add a Colorimetry Data Block with the sRGB colorimetry
> bit set to avoid interop issues.
> 
> Failures:
> 
> Block 1, CTA-861 Extension Block:
>   Missing VCDB, needed for Set Selectable RGB Quantization to avoid interop
> issues. EDID:

This Extended Block Type Tag 1 is used to provide the Video Capability Data 
Block.  I don't think this is critical.  It just means the EDID Extension 
block with additional information may not be provided wholly or partly by the 
monitor.

>   Base EDID: Some timings are out of range of the Monitor Ranges:
>     Vertical Freq: 50.000 - 75.062 Hz (Monitor: 56.000 - 75.000 Hz)

This could be relevant, especially as your display keeps flickering on & off, 
as it tries to find a suitable frequency.


> EDID conformity: FAIL
> 
> [ .... ]
> 
> > > The recurring flickering of the display after you've loaded your desktop
> > > shows the linux OS is trying to re-adjust the display.  Usually this
> > > happens when the connection/power to the monitor is disrupted, which
> > > again points to a connector issue, or it can also happen if you
> > > specified in your GUI the wrong resolution/frequency.
> > 
> > Yes.  I think the connectors are OK, but maybe we'll see how the machine
> > performs differently at the shop tomorrow.
> 
> I've decided I'm definitely going to get a new HDMI->DVI adapter.

I suggest you buy an HDMI-to-DVI-D bidirectional adaptor, or a cable with such 
connectors on each end.  A DVI-DL will be able to display higher resolutions 
than 1920x1080, if both ends had this connector, but the HDMI is a single link 
interface so only one of the dual link connectors on the DVI end will be wired 
in.

Random links as an example:

https://cablenet.co.uk/product/32-3750

https://www.kenable.co.uk/en/computer-cables-/dvi-cables-adapters/dvi-to-hdmi-cables/8970-dvi-d-24-1pin-male-to-hdmi-digital-video-cable-lead-gold-05m-50cm-008970-5055383489701.html

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

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

[Alan Mackenzie]

Hello, Michael.

On Tue, Aug 27, 2024 at 19:36:49 +0100, Michael wrote:
> On Tuesday, 27 August 2024 17:05:26 BST Alan Mackenzie wrote:
> > On Mon, Aug 26, 2024 at 14:49:14 +0000, Alan Mackenzie wrote:
> > > On Mon, Aug 26, 2024 at 12:54:20 +0100, Michael wrote:
> > > > On Monday, 26 August 2024 11:40:43 BST Alan Mackenzie wrote:
> > > > > On Sun, Aug 25, 2024 at 22:04:05 +0100, Michael wrote:

[ .... ]

> > OK, I'm just back from the shop.  The technician there plugged the
> > machine into an HDMI monitor, and it just worked.  Before leaving, I
> > assured him that I _would_ get the machine working, even if that
> > might involve buying a new monitor.  ;-(

> Well, that's a different monitor and the cable was an HDMI-to-HDMI cable (I 
> assume?).

Yes.

> Since you went to all this trouble it would be better if you dragged
> your monitor along with you.  Either way, I admire your doggedness to
> get to the bottom of this.  :-)

No, I had enough trouble getting the PC back to the shop, without somehow
having to pack up the monitor and all the cables and KVM Box between it
and the machine.  That would have turned a minor inconvenience into a
major expedition.

But I've _got_ to get to the bottom of this, otherwise I don't have a
working new machine.  ;-(

> > When I got back home again and plugged in the new machine, it was
> > slightly different.  It was still pumping out 2112x1116, but the 2" gap
> > has become a 1" gap on both the left hand and the right hand sides.
> > There's still a (smaller) gap at the top.  I haven't yet tried booting
> > into Linux.

> > At least we now have an indication of something "analog" perhaps not
> > being in order.  I'm thinking that perhaps my HDMI->DVI adapter is
> > broken.  I should have bought a new one while I was at the shop, just to
> > test.  I did have trouble with Windows laptops when I plugged them in
> > via this adapter a couple of years ago.  Maybe I'll go back to the shop
> > to get that new HDMI->DVI adapter tomorrow.

> It would be best if you could buy a cable with the requisite HDMI on one end 
> and a DVI-D on the other.  DVI-DL is capable of higher than 1920x1080 
> resolutions, although the optimal resolution of your panel is at 1920x1080.

Such a cable would involve removing the KVM box from the setup, at which
point I wouldn't have a fully working machine to read Gentoo
documentation on, or carry on using email.  I will stick with 1920x1080
for the foreseeable future - I can barely make out the pixels on my
screen (a 24" diagonal screen) as it is, without pushing up to a higher
resolution.

I think the manufacture of monitors is a finished art.  It's reached the
stage at which our eyes can't see any finer resolution or any more
colours, and the current sizes of monitors are already sufficiently big
to put on any desk top.  It's not like when we had to put up with
16-colour 640x480 VGA, eagerly lapping up any and every subsequent
development.

[ .... ]

[ EDID block correctnes ]

> Normally warnings and errors reported by the DDC check can be overcome by the 
> graphics and/or Xorg drivers.  I have monitors here which complain about all 
> sorts of warnings and errors and fail the DDC compatibility check, but still 
> work fine *and* display a more accurate picture (chromatically) than other 
> monitors which pass the EDID/DDC check and post no warnings.  Go figure ...  
> :-/

My current monitor has been performing just fine since 2011.  I doubt the
warnings and errors in its EDID block have anything to do with the
malfunctioning.

[ .... ]

> > > > The recurring flickering of the display after you've loaded your desktop
> > > > shows the linux OS is trying to re-adjust the display.  Usually this
> > > > happens when the connection/power to the monitor is disrupted, which
> > > > again points to a connector issue, or it can also happen if you
> > > > specified in your GUI the wrong resolution/frequency.

> > > Yes.  I think the connectors are OK, but maybe we'll see how the machine
> > > performs differently at the shop tomorrow.

> > I've decided I'm definitely going to get a new HDMI->DVI adapter.

> I suggest you buy an HDMI-to-DVI-D bidirectional adaptor, or a cable with such 
> connectors on each end.  A DVI-DL will be able to display higher resolutions 
> than 1920x1080, if both ends had this connector, but the HDMI is a single link 
> interface so only one of the dual link connectors on the DVI end will be wired 
> in.

Again, to avoid having completely to rejig my cabling set up, I'm going
for the HDMI male to DVI female to replace the one I've got.  It only
costs a little less than 9 euros, considerably less than the taxi rides I
needed to get the machine to the shop and back again.

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Alan Mackenzie]

Hello, everybody.

On Tue, Aug 27, 2024 at 20:50:01 +0000, Alan Mackenzie wrote:
> On Tue, Aug 27, 2024 at 19:36:49 +0100, Michael wrote:
> > On Tuesday, 27 August 2024 17:05:26 BST Alan Mackenzie wrote:
> > > On Mon, Aug 26, 2024 at 14:49:14 +0000, Alan Mackenzie wrote:
> > > > On Mon, Aug 26, 2024 at 12:54:20 +0100, Michael wrote:
> > > > > On Monday, 26 August 2024 11:40:43 BST Alan Mackenzie wrote:
> > > > > > On Sun, Aug 25, 2024 at 22:04:05 +0100, Michael wrote:

[ .... ]

> > > When I got back home again and plugged in the new machine, it was
> > > slightly different.  It was still pumping out 2112x1116, but the
> > > 2" gap has become a 1" gap on both the left hand and the right
> > > hand sides.  There's still a (smaller) gap at the top.  I haven't
> > > yet tried booting into Linux.

> > > At least we now have an indication of something "analog" perhaps not
> > > being in order.  I'm thinking that perhaps my HDMI->DVI adapter is
> > > broken.  I should have bought a new one while I was at the shop, just to
> > > test.  I did have trouble with Windows laptops when I plugged them in
> > > via this adapter a couple of years ago.  Maybe I'll go back to the shop
> > > to get that new HDMI->DVI adapter tomorrow.

Well, I now have that new HDMI->DVI adapter, and my video now works!
Both the console and X Windows (running XFCE) work fully.  There must
have been a dodgy connection in my old adapter, possibly in a timing
twisted pair, or something like that.

As always, after solving such a problem, one wonders why it took so long
to fix.  I was convinced it was something in the motherboard's firmware,
and it took an actual demonstration of it working on an HDMI monitor to
persuade me otherwise.

Anyhow, now to finish setting the machine up, in particular getting an
email server installed and configured.

Many thanks to the people who helped me diagnose the problem,
particularly Michael and Dale.

[ .... ]

> -- 
> Alan Mackenzie (Nuremberg, Germany).

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

[Dale]

Alan Mackenzie wrote:
> Hello, everybody.
>
> On Tue, Aug 27, 2024 at 20:50:01 +0000, Alan Mackenzie wrote:
>> On Tue, Aug 27, 2024 at 19:36:49 +0100, Michael wrote:
>>> On Tuesday, 27 August 2024 17:05:26 BST Alan Mackenzie wrote:
>>>> On Mon, Aug 26, 2024 at 14:49:14 +0000, Alan Mackenzie wrote:
>>>>> On Mon, Aug 26, 2024 at 12:54:20 +0100, Michael wrote:
>>>>>> On Monday, 26 August 2024 11:40:43 BST Alan Mackenzie wrote:
>>>>>>> On Sun, Aug 25, 2024 at 22:04:05 +0100, Michael wrote:
> [ .... ]
>
>>>> When I got back home again and plugged in the new machine, it was
>>>> slightly different.  It was still pumping out 2112x1116, but the
>>>> 2" gap has become a 1" gap on both the left hand and the right
>>>> hand sides.  There's still a (smaller) gap at the top.  I haven't
>>>> yet tried booting into Linux.
>>>> At least we now have an indication of something "analog" perhaps not
>>>> being in order.  I'm thinking that perhaps my HDMI->DVI adapter is
>>>> broken.  I should have bought a new one while I was at the shop, just to
>>>> test.  I did have trouble with Windows laptops when I plugged them in
>>>> via this adapter a couple of years ago.  Maybe I'll go back to the shop
>>>> to get that new HDMI->DVI adapter tomorrow.
> Well, I now have that new HDMI->DVI adapter, and my video now works!
> Both the console and X Windows (running XFCE) work fully.  There must
> have been a dodgy connection in my old adapter, possibly in a timing
> twisted pair, or something like that.
>
> As always, after solving such a problem, one wonders why it took so long
> to fix.  I was convinced it was something in the motherboard's firmware,
> and it took an actual demonstration of it working on an HDMI monitor to
> persuade me otherwise.
>
> Anyhow, now to finish setting the machine up, in particular getting an
> email server installed and configured.
>
> Many thanks to the people who helped me diagnose the problem,
> particularly Michael and Dale.
>
> [ .... ]
>
>> -- 
>> Alan Mackenzie (Nuremberg, Germany).
>


Very welcome.  You may have noticed that HUGE thread where Micheal and I
were banging at a monitor on my new rig.  Turns out, bad cable, adapter
or both.  New monitor, two new monitors later actually, and I still had
one monitor winking at me.  New cable with no adapter fixed that.  I
might add, second monitor still has the adapter and works just fine. 

I also had a hard drive once that was spitting out some sort of error. 
Turned out, cable wasn't making a good connection.  Unplug, re-plug and
carry on.  I might add, after recent move of all my hard drives to a new
case, some drives are having that error again.  I detect new cables in
their future.  May unplug and re-plug as a test tho, just in case. 

This is why I try to have extra cables hanging around in a box
somewhere.  It seems cables tend to have issues.  I think part of it is
the cheap way they make them.  I have several XTar VC4 battery
chargers.  The power cables to those things is always giving me fits. 
It's hard to find a quality cable that doesn't cost a arm and a leg. 

Glad you got it going.  :-D

Dale

:-)  :-)