OK … having been wasting time on silly things like ‘natural scrolling’ I decided it was about time I took the bull by the horns and sorted out the basic hardware problems.
To set the scene … 2 off samsung 24" monitors native 1920x1200 … keyboard and mouse … all in the office with a couple of CAT5 links to the workshop where there is a stack of computers on an older style (expensive) KVM switch. I’ve 6 machines in the rack and a couple of extra cables for machines that are being built on the bench.
Some of you will already have spotted the problem Current installations of X ‘automatically’ configure themselves from the DCC data, and more irritatingly switch the resolution down when the ‘connection’ goes away. I’m more than happy playing with xorg.conf settings and I can even live with the seemingly pointless step of pulling that data apart into separate files, but there is still something getting in the way of setting up a ‘manual’ configuration that does not ‘reset’ when you switch monitors. The main problem on ‘switching’ is the DVI feeds which have a 4 way selector as I only have two monitors on a couple of boxes, but even the ‘simple’ solution of cabling a couple of monitors direct to the box while setting up fails when you unplug the VGA to restore the KVM feed. I know the real solution is to throw out 500GBP of switch and buy a new one that handles DCC, but getting the DCC down the remote feed is not something that even current kit seems to support? The DVI switch IS a new one, and ‘helps’ by reporting 1920x1080 resolution, but the computer end still hickups when you switch
In the past, ‘NOMODESET’ would disable the automatic hot switch detection?
I’ve added the
Section “ServerFlags”
Option “AutoAddDevices” “False”
EndSection
to the xorg.conf , but IDEALLY that should be more selective - hence the ‘asking the impossible’ - currently I need to fix the keyboard layout as I’ve lost the GB buttons …
I’ve loaded the nvidia supplied drivers in an attempt to help since their configuration tool does still work to create an xorg.conf setup, but this is bauking at the DVI switches 1920x1080 and will not even allow me to set 1920x1200 via xrandr So I’ll strip that back off again and return to the generic driver which was working 1920x1200 on both monitors but I could not reconfigure the earlier xorg.conf I believe now becuase the ‘automatic’ stuff IS still getting in the way?
So what am I missing to make this work reliably with 12.3 installations … I’ve 3 more machine to upgrade at some point … that is if I even bother
OK - I can now add to my own thread …
The problem is directly related to the fact that start-up no longer respects the X11 settings for the graphics. So what I’m actually looking for is some means of configuring the hardware outside of X11.
The current situation is that it boots to the ‘automatic’ resolution of each monitor, so I only get 1024x768 on the main screen. Even though I have set the higher resolution in X11 I have to manually reselect it every time I log in. Logging out of the desktop gives the erroneous selections and resets things so that a new login now restores the ‘lower’ resolution.
At least currently I’m not getting the warning banner that I was getting that the ‘resolution can not be set’, and a script can kick in the right resolutions - or at least I should be able to achieve that once I uninstall the nvidia driver so I can get the full resolution on the DVI output.
SO - how do I get the boot loader to use the best resolution on both monitors at boot time?
On 07/18/2013 12:26 PM, lsces wrote:
> SO - how do I get the boot loader to use the best resolution on both
> monitors at boot time?
from my understanding of your first post in this thread (where 6 to 9
machines are directly connected to one keyboard and two monitors,
through a switch, one at a time–or did i miss something?) i must
ask: do you mean when you boot any of those six to nine systems, that
both screens ARE connected throughout the boot process? and, are they
also connected throughout the shut down process?
but still, somehow they resort to a lesser resolution?
so, just thinking out loud: the file /etc/X11/xorg.conf used to ‘set’
monitor(s) resolution…but, that file was done away with so that
every time X starts it ‘looks’ at the monitors and does the best it
can to figure out what resolution is best…but, if there is an
xorg.conf it will use it…and, i think if you have a super good
xorg.conf on every one of those nine boxes they will boot to the
right resolution every time…even when no monitor is hooked
up…if you have set it to run headless…
but, i really don’t know for sure what i’m talking about, so read my
sig caveat prior to walking down any dark alleys…
Man nomodeset should bring up the option to cause the kernel to use bios setting as per the link I posted.
I had to roll my own xorg.conf some time ago due to using an old lead on my monitor. Xorg.log was useful to see exactly what x is actually doing
I still use my xorg.conf file, it isn’t as nvidia installed it. May help you force resolutions but can’t help on multiple screens. There have been many posts on that subject around the time of 11.4 introduction. I tried to find the post that I started but no luck with the search. One fact I did find is that xorg’s docs didn’t cover recent changes but they may help you see how to make something like my file multi monitor.
There is a utility for generating modeline entries. From memory its called GTF. The data it uses has to be determined from the mode details usually provided with monitors or at least in it’s specifications.
I believe that the conf files has to be put in etc/x11 and not the other x directory.
NVidia put nothing in it as it assumed X would get the info from the monitor.
Meant to add that the device section is important.
Also I understand some have had problems with nodmps actually stopping the screen from blanking after a period of inactivity. Seems to work for me. I feel that the on off button is a better option.
Actually the problem has nothing to do with the X11 xorg.conf … it’s happened a long time before that starts!
grub gives the option to boot into a high res mode available from the bios, this list probably will not match your graphics card but it’s a start. I selected 1600x1200 as it’s the height difference between 1200 and 1080 which is the irritating thing when IN X. On the test machine I’ve got a duff setup, so I can’t confirm that it retains the 1600x1200 for the login screen yet, I suspect it should.
nomodeset acts on this selection, so when set and you are monitoring bootup then the screen resolution stays constant. Without nomodeset, the resolution switches down to 1024x768 about half way through, too fast to see what started and switched it It then uses the 1024x768 for the login screen and defaults the initial X screen to that resolution what ever you set in xorg.conf!
A side issue is the fact that the nvidia supplied driver will not allow the 1920x1200 mode to be set hence being stuck with 1080 on the DVI monitor. nouveau should sort that, but I’ve not managed to remove the nvidia driver as it’s not appeared in package manager
( DenverD all the machines on, some are running as backups for critical systems on customer sites or our web hosting, moving towards text mode where possible, but rendering maps on a couple of the machines so the graphic desktop can be helpful. )
Following up on that … the ‘duff setup’ would seem to be caused by the fact that the boot sequence is not using the xorg.conf settings. I have 1600x1200 added in the modes, but the boot-up will only work if I select a bios mode that is in the limited subset of modes it ‘automatically’ creates. SETTING nomodeset on the failsafe boot would seem to be a problem if you also select a bios mode the automatic stuff can’t handle. This I think explains why some people have problems getting new incarnations working. I’ve seen a few posts about ‘nomodeset did not work either’, but x11failsafe seems to get around the conflict.
Quote of the day … Once you know the answers asking the right questions on google/bing confirms them
It’s quite amazing how a few innocent little changes create a mile of work down the road. I KNOW the solution now, just not how to implement it in SUSE I just need to update the EDID table with a copy of the one with the monitor plugged in so everything carries on working when it’s unplugged
I’m not sure how to implement kernel/git/torvalds/linux.git - Linux kernel source tree myself …
IIUIC you just have to put a file with the firmware to /lib/firmware and provide “edid_firmware=firmware_file” as kernel boot parameter.
Or use one of those as “firmware_file” for the built-in EDIDs:
An addition:
On my system the EDID of the attached monitor is contained in /sys/bus/i2c/devices/1-0050/eeprom, so the following would create an EDID file:
1-0050 may differ on your system, it’s bus-address.
The address should be 50, but the bus may differ.
So try 0-0050, 1-0050 and so on and use the first one that exists. That’s how the “ddcmon” util from i2c-tools does it as well.
You can check with “hexdump” if it is an EDID, in this case it should begin with:
:’( My interest stems from not going near the console unless I have too - had to re x - so roughly remember what to do and then they go change it.
As I read the git post the usual utility gives the numbers needed for a particular graphics mode but they are re arranged for kernel use as indicated. The instructions for building it are given. That should just mean installing C etc development and following them. The etc is because it will build from source in a number of languages.
Next problem may be where opensuse have put the file. My answer to that is usually to search * dot what ever it is from //. Usually finds things.
Not sure what you mean about the nvidia driver not offering your mode. As my 11.4 machine is set up using the x config file the driver offers the resolutions that I have specified in it so I assume if you add your mode to the “new stuff” it will do that same. These days they do seem to specify higher resolutions via the digital output on the card but if the o/s driver will give the higher res via the vga socket you should find the nvidia one will too. I suspect the change is down to image quality and perhaps a desire to get rid of the extra socket for vga. :\ All based on my current now a little old nvidia card. What comes out of the digital socket also comes out of the vga one. My monitor has both.
I’m only getting i2c-x where x is 0 to 9
AH … found
drm/card0/card0-VGA-1/ and card0-DVI-I-1 which has an edid file and a modes file under them which match the defaults displayed.
Only problem is that the display channels are currently report as VGA-0 and DVI-0 … but knowing where to look is a start …
John - The problem with the nvidia driver is that it will not allow me to change the resolution via xrandr to manually added modes, so you can’t load the 1920x1200 mode and use it. The nouveau driver is working fine and a script restores the two full screens after a reboot. Changing the EDID data should remove the need to have to do that and retain my desktop layout properly as it is now …
AH - and a reminder - I don’t have a problem if I take the monitors outside and plug them in direct - its the KVM switch and extneder that prevent the edid data being read …
/sys/bus/i2c/devices/i2c-0/device/drm/card0/ but all 10 i2c-x folders have the same set of files …
Searched entire disk and no ‘1920x1080.bin’ file anywhere, so should I be downloading something to get it? debug version of the kernel?
This is the sort of ‘consistency’ I’ve been going on about in another thread … needing 4 different sets of style files for one theme and having to change each separately is another.
Ah, ok. Yes I have that as well. I have only looked in i2c-1…:shame:
This should be ok.
Searched entire disk and no ‘1920x1080.bin’ file anywhere, so should I be downloading something to get it? debug version of the kernel?
This file doesn’t exist. It’s a “pseudo” file built into the kernel and contains EDID data for a (fake) monitor with 1920x1080 resolution.
Just copy your real monitor’s EDID data to a file, put that file in /lib/firmware and specify that file with the “edid_firmware” boot parameter.
But I haven’t tried that myself yet, so can’t guarantee you that it works. If it doesn’t you should have a look in dmesg and/or /var/log/messages to find out why (grep for “drm” I would say).
There should be an equiv of the file used to generate this as well - if I understand the linux git link plus any other files opensuse use to build the kernel. Interesting to note that some of these files do not contain the modes that the git link suggests that they should.
I assumed that kernel sources would be installed - sorry about that.
The few times I have ever done things kernal I have found that opensuse differs from many distro’s on just what has to be done. It was a while ago but from memory it was a paths problem - might be that this was fixed with an export command from a certain directory. To long ago to remember. At that time the method was detailed in a Novel howto.
I’ll need to lug the monitors out to the workshop and plug them in direct to get the right file.
But it’s on the to-do list, I’m working again and so I’ll not worry just at the moment.
oyranos-monitor-nvidia is currently reporting ‘no monitors’ which is why I’m not getting anything But it is all working fine for the first time this week!
I’m not sure what update last weekend created the initial problem