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