30 Nov
2012
30 Nov
'12
2:54 a.m.
Le mardi 27 novembre 2012, Felix Miata a écrit :
On 2012-11-27 20:46 (GMT-0500) Patrick Serru
composed:
---------------------------------------------------------------------
Hi all, hi Felix,
Thank you for your response.
From inside KDE:
kdesu konqueror /etc/X11/
renaming /etc/X11/XF86Config to /etc/X11/~XF86Config
On a root console (F4):
/etc/X11 # sax2
SaX: Checking update status for radeon driver
SaX: initialization already done
SaX: call [ sax2 -r ] if your system has changed !
SaX: startup
SaX: X-Server: :0.0 -> grant
SaX: importing current configuration...
This worked an a root window showing proposing
ATI RV350 AP card,
FUS LCD Monitor, at
1280x1024 (SXGA) - 24 bit
X Acceleration activated
--------------------------------------------
Leaving KDE3, Login as "root" in tty1 and executing sax2 is working well.
But with such a reserved of files, this is not surprising:
/etc/X11/xorg.conf
/etc/X11/xorg.conf.bak
/etc/X11/xorg.conf.saxsave
and my change /etc/X11/~XF86Config
/etc/X11/xorg.conf.md5
--------------------------------------------
So: I did not cut the wings of X. But I understand that if I do, X
will no longer work. There is not only X that no longer works when its
configuration file is missing!
What can I say? The screen works quite well, for a user like me. As I
am not manufacturer, I do not have the means to quickly fully test the
screen. I will not study the specifications of the "Extended display
identification" and its use on X side, to check my screen. But at a moment
of my tests, I typed a command that gave me what should have been included
in some equivalent of XOrg.conf. I dont know if the following command to
enable this resolution worked because the system (Ubuntu) did not restart
("Ctrl D to continue"). A recent distributions tested these last ~30 days
has shown in 1280x1024. I think I saw it from a TDE live CD after "normal
user level" adjustment (from desktop contextual menu, I think).
Felix, thank you again, but you can simply forget the component of
that thread corresponding to my difficulties. I am no longer interrested by
OpenSuse. But I would restart Ubuntu or Fedora tests if there is someone
here that could really help me, more than the Ubuntu inline help did it.
Cheers,
Patrick
> It's just that developers don't have
*your* particular hardware
> combination to test on…
Is 1280x1024 pixels screen such an exceptionnel
format?
It's probably the most common native resolution currently. But, was the
Scaleoview T17-2 you're looking at perfect when it left the factory? Is it
still perfect?
> …, and when the required hardware data is
missing or broken, as
> apparently must be the case for your display's EDID,…
My display (Fujisu-Siemens FUS T17-2) works well,
and its Extended
display identification data (EDID) too, but I did not espacialy check
that last point. And some recent distributions did configure X correctly
for its use.
But will they today? That something worked is not proof that it works.
Faced with the difficulties of installing
the most recent
distributions, I got to thinking that the tests were done on virtual
machines, and thus, the developers were not seeing the problems. The ATI
driver? But I am using this machine, this graphic card and this screen
with this ancient OSS 11.1!
IIRC, automatic X configuration was rather young at the time of, and
likely not implemented in, openSUSE 11.1. The 11.1 I just booted even has
a /etc/X11/XF86Config as a soft link from xorg.conf! The in place backup
of its original xorg.conf is timestamped April 2007. What happens when you
restart X in 11.1 after removing xorg.conf?
When I try X in 11.1 with xorg.conf removed, Xorg.0.log ends with fatal
server error \ cannot run in framebuffer mode, even after having correctly
identified the gfxchip as Radeon. After restoring xorg.conf, X starts in
1600x1200 according to specification in the xorg.conf file.
Most modern distros have automagic X configuration that works in most
cases, but not all. Until one tries manual configuration or other
hardware, there's no practical way to be sure a particular failure is not
some previously unobserved hardware fault. I have found in *every* case
tried personally, absent known driver or X bugs applicable to the hardware
used, that basic automagic X configuration failure can be worked around
through manual configuration. Trying a less than 1Kbyte
http://fm.no-ip.com/Share/xorg.conf-minimal-EDID-workaround as a shortcut
to manual configuration from scratch is a pretty simple thing to try. It
doesn't take much in most cases to work around apparent EDID-related
automagic failure.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/