Michael wrote: > On Thursday, 27 June 2024 23:52:25 BST Dale wrote: >> Michael wrote: >>> [snip ...] >>> [ 30.345] (II) modeset(0): [DRI2] DRI driver: nouveau <== Not nvidia >>> == >>> >>> [snip ...] >>> [ 30.295] (II) modeset(0): Output DP-1 disconnected >>> [ 30.295] (II) modeset(0): Output DP-2 disconnected >>> [ 30.295] (II) modeset(0): Output DP-3 disconnected >>> [ 30.295] (II) modeset(0): Output DP-4 connected >>> >>> What does it take to connect the cable on the FIRST port of the video >>> card? >> This reply may be a little odd. I wrote some then went back and tried >> some stuff and added info to it. Trying to make it make sense. > My apologies, I didn't meant to add to your frustration. Working with a > headless system is no fun when you expect to run a desktop on this thing!
I didn't take it that way. I learned long ago that text doesn't convey emotion very well. I take things in the best possible way unless there is no other way to read it. I've just never had this much trouble getting a computer to work. Things have improved a lot and mostly, they just work without much help from us. Generally, if the correct drivers are in the kernel and the right packages are installed, it works. Like magic. Usually without a config file even. > > I was just making a remark on the fact the card detects the monitor as being > connected to DFP-3 or DFP-5 when using the proprietary nvidia driver, but the > DP-4 when you used the open source nouveau driver. > I've noticed that the port numbers keep changing too. I don't understand why since the card should assign those but it is changing. It changes even when all I do is reboot. >>> At first, when it really wouldn't work, I had it on the bottom port. At >> some point we thought that was the last port, #4 or DP-3 in the logs, >> and not the first port. I moved it to the top port which is #1, we >> thought. It's still on that port but that port did work once and >> resulted in "solved" being added to the subject line. I just double >> checked. It is plugged in the top port. Unless the bottom port is #1 >> like I originally thought, then it should be on port #1. I did a search >> and found a image that shows it puts the port number on the metal >> bracket. I removed the card so I could see the numbers. The bottom >> port is number 1 like I originally thought. So, I had it in the right >> port to begin with, which wasn't working either. I'll put it back on >> what the metal bracket says is port #1, or bottom port. I booted up, >> started DM, correct resolution but no plasma and background is black. >> Still not a functional desktop. Partially works tho. Time to reboot. >> On reboot, sddm and KDE are low resolution. It does have a background >> image and plasma is working. Keep in mind, all I did is reboot. I >> didn't change any config file or run any commands. Reboot again. This >> time, correct resolution but no plasma. Again, all I did was reboot. >> No changes to anything at all. As you can see, each time I reboot, it >> is like rolling dice. I suspect if I keep rebooting it will eventually >> do the black screen and power the monitor off. > It seems to me the card is probing the monitor to find out what settings it > prefers/will work with. This probing of the driver scrolls through a number > of potential Modelines, but if the monitor does not respond in a timely > manner > with its preferred resolution and frequency you get a broken result. > > Here are some hypotheses of mine, in absence of more concrete evidence. The > old box is slower and the initialisation process takes longer. In this > longer > processing time the monitor responds with its EDID and what not. The card > receives it in a timely fashion and sets the driver accordingly. > > With your new box things happen faster on the PC side, but not on the monitor > side. Two times out of three the synchronisation between driver and monitor > fails and you end up with reports of EDID not found and monitor shown as > disconnected in your Xorg.0.log. > > Having the monitor plugged in any port on the card, first or last, should not > make a difference, but if milli/nano-seconds count then it /might/ make a > difference, assuming the ports are tried sequentially by the driver. Hence I > had suggested stick with the first port. Some user reports on the interwebs > mentioned it, so I thought it is worth trying it. > > What else worth trying is to set fixed directives for the "Monitor" section > in your xorg config file, or capture the EDID table into a file and feed it > to > the driver. The former ought to work, the latter may not if the EDID itself > is buggy, but that's a problem to solve later if it even exists. Either way, > setting explicit directives for the monitor Modeline(s) and preferred > resolution/frequency ought to take auto-probing out of the equation. > And to me, that all makes sense. This new machine boots very fast. I have a SATA controller card in there now and it shows it scanning for a connected drive on a lot of ports. Of course, nothing is there yet. Before I put that card in, it would boot so fast you couldn't even think of trying to read even bits of the screen. I never timed it but I'd guess around 12 to 15 seconds to a login prompt with the card. If that. Without the SATA card, well, don't blink. I'd guess 5 seconds at most. I kinda wish I had built the original rig now. It would boot so fast, it might smoke this old monitor. ROFL If needed, I could hook the monitor to the NAS box and grab data from there. Right now, the NAS box "kit" is in the living room on top of a magazine on the piano. Didn't want the pins scratching the piano. NAS box has no case. To be honest tho, may as well wait on the new monitor. It will be here Tuesday according to FedEx. If it doesn't get damaged. Dang monitors/TVs are fragile nowadays. I bumped the TV screen while cleaning in my living room and the screen cracked. Dang, that was easy. Anyone need some control boards??? 32" LG I think it is. >> I did originally try to use the nouveau drivers. It kinda worked, once >> at least, but the screen was very slow to respond and the mouse was very >> jerky. It just wasn't good enough for whatever reason. I recompiled >> the kernel without those drivers and emerged nvidia. > It's your call which drivers you should try to get it to work with first. > > Slow GUI response with the nouveau driver would indicate the kernel > configuration/firmware loading was not 100% when you trying initially, > because > it works fine when you tried it again with Kubuntu's kernel. > > People who use Nvidia prefer the nvidia driver in terms of performance, CUDA, > etc. so you may want to stick with the nvidia driver initially. In this > case, > walk through this guide and cross-check you followed all suggestions in there > to configure your kernel, including disabling the nouveau driver. > > https://wiki.gentoo.org/wiki/NVIDIA/nvidia-drivers > > If you intend to have both nouveau and nvidia drivers and switch between > them, > then you can build nouveau as a module and implement the more convoluted > switching methods suggested in the next guide, but I suggest you leave this > for later and not confuse the two drivers: > > https://wiki.gentoo.org/wiki/Nouveau_%26_nvidia-drivers_switching > > Having checked your kernel against the nvidia-driver guide, installed your > updated kernel & initramfs images you should reboot. Use 'lspci -k' and scan > dmesg to make sure nvidia is loaded and there were no hiccups. > > You've tried not having an xorg.conf and didn't work, or at least it did not > work reliably. Mind you, you also tried with a xorg.conf and this didn't > make > things better. LOL! However, I think this was because the "Monitor" section > was mostly empty: > > Section "Monitor" > Identifier "Monitor0" > VendorName "Unknown" > ModelName "Unknown" > Option "DPMS" > EndSection > > Restart, if you need to, the display-manager until you eventually arrive at a > fully loaded and functioning desktop. nvidia-smi should reveal if the driver > is loaded and working fully. You can run nvidia-settings, (emerge x11- > drivers/nvidia-drivers with USE="tools") to tweak resolution and frequency > for > your monitor, which will then be stored in your config file: > > https://download.nvidia.com/XFree86/Linux-x86_64/1.0-6106/nvidia-settings-user-guide.txt > > O, while all is working as desired 'xrandr -q' will provide you with some > useful information for your xorg.conf: > > Identifier - e.g. "DisplayPort-0", or "LG Electronics W2253" > > Modeline - e.g. Modeline 1920x1080_60.0 138.50 1920 1968 2000 2080 1080 > 1083 1088 1111 +hsync +vsync > > and you can set a preferred option in your xorg.conf; e.g. > > HorizSync 15.0 - 67.0 > VertRefresh 59.0 - 60.0 > Modeline "1920x1080_60.0 138.50 1920 1968 2000 2080 1080 1083 1088 > 1111 +hsync +vsync" > Option "PreferredMode" "1920x1080"_60.0" > > or some such. > > If the above won't do it, you can capture the monitor's EDID while it is > working - you can use nvidia-settings again: > > https://nvidia.custhelp.com/app/answers/detail/a_id/3571/~/managing-a-display-edid-on-linux > > There's a more manual way to do this too: > > find /sys |grep -i edid > > then copy the corresponding file to /lib/firmware/LG/W2253_edid.bin > > and add it to your kernel before you recompile it: > > https://docs.kernel.org/admin-guide/edid.html# > > See if the above helps you to a stable monitor, or post back with xorg.0.log > results. Before I ran out of steam this morning, I tried the nouveau drivers again. I never can remember how to spell that. :/ I unmerged the nvidia drivers to do this. I used the in tree nouveau drivers tho. For some reason, even tho I removed the nvidia package and rebooted, it still showed it was loading the nvidia drivers which shouldn't even exist. No matter what I did, it loaded the nvidia drivers. I could see it with lsmod and lspci -k. It's like I can't get rid of the nvidia drivers now. Naturally, DM wouldn't start at all since I told it to use the nouveau drivers. Also, I couldn't get modprobe to even find the nouveau drivers even if the nvidia drivers were removed with rmmod. Wrong package maybe??? I've tried using the nvidia tools to get display information. It works fine on my main rig so I know I have the command and options right. On the new rig, it says something like no display found or something. I installed xrandr at one point to and added a command to a file somewhere, I think you mentioned that. It's still there by the way. Thing is, even it doesn't shed much light. Given some things I got going on right now, I think I'm going to wait and try the new monitor. It's on the way. While I'd like to figure out why this older monitor doesn't work, I'm just to low on steam. I boot and play with the new rig on occasion but fixing that old monitor is turning into a nightmare. I'd hate to end up with a $1,000 target for practice. O_O If I get a little steam built up, I'll try some of this tho. If nothing else, it will keep me inside instead of outside in the heat. It's not just hot, it's humid. I need scuba gear to breath outside. Who knew building a new rig would turn into all this. :/ Dale :-) :-)
