Le mardi 27 novembre 2012, Felix Miata a écrit :
On 2012-11-27 20:46 (GMT-0500) Patrick Serru composed:
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 recentdistributions, 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/
--------------------------------------------------------------------- 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