xorg Digest, Vol 163, Issue 3

[Chris Sorenson]

> 
> Message: 1
> Date: Sun, 3 Feb 2019 09:10:56 -0800
> From: Earl Killian <xorg at earl.killian.com>
> To: xorg at lists.x.org
> Subject: Screen(s) found, but none have a usable configuration.
> Message-ID: <8d88022e-7595-12bc-da2a-30df722f4602 at killian.com>
> Content-Type: text/plain; charset="utf-8"
> 
> I have an old 1U server with VGA output. The graphics card is an ATI
> Mach64. The monitor connected to the VGA is a Dell 2001FP, which is
> 1600x1200 native, but should be operated at a lower resolution on this
> server because of limited VGA bandwidth.
> 
> I recently upgraded the Linux distro to openSUSE Leap 15.0, and now no
> matter what I try, I get "Screen(s) found, but none have a usable
> configuration." no matter what I try. I would appreciate any 
> suggestions
> that would help me get this working. My first attempt with the distro
> files in /etc/X11/xorg.conf.d, which are essentially empty, letting 
> Xorg
> default everything. I have since attempted adding Monitor, Section, and
> Device sections to give me 1024x768 at 60Hz, but nothing gets rid of the
> none usable error.
> 
> I am relatively naive when it comes to Xorg configuration, and so I
> could easily be missing something obvious. I would therefore appreciate
> someone looking over the following log output and suggest what the
> problem might be.
> 
> Since this a 1U server that will usually be booted headless, I would
> like a configuration that will work with whatever monitor happens to be
> on the "crash cart" in the colocation facility. That's why my target is
> 1024x768 at 60Hz, since that is pretty much universal. But right now I
> cannot get it to work with the monitor on my bench, no matter what I
> try. For example, I have tried putting the ModeLines from the log file
> into my 50-monitor.conf file, to no avail. I have also tried the vesa
> driver instead of the mach64 driver, also to no avail. Always no usable
> screens.
> 
> Suggestions or pointers much appreciated!
> 

Fairly lengthy thread on this topic here:

https://lists.debian.org/debian-powerpc/2017/03/threads.html#00184

Looks like they solved it a couple of different ways, either compiling a 
new kernel with CONFIG_IO_STRICT_DEVMEM=n in the configuration file 
(definitely a security concern) or booting the original kernel with boot 
parameter iomem=relaxed ...