| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 43 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 96:13:40 |
| Calls: | 290 |
| Files: | 904 |
| Messages: | 76,426 |
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.
Or, I could go back to the shop that built the machine. Maybe I
should try it connected directly to an HDMI monitor.
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.
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.
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:I'm beginning to think getting an MSI board was a mistake.
On Sun, Aug 25, 2024 at 22:04:05 +0100, Michael wrote:
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.
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?).
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.
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 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.
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!
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.
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.
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
:-)á :-)á
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.
.... 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.
If nothing else, that may give you a idea, about something I really
don't understand completely. o_O LOL
Dale
:-) :-)