View previous topic :: View next topic |
Author |
Message |
52midnight Apprentice
Joined: 20 Mar 2012 Posts: 176 Location: Brisbane AU
|
Posted: Sun Mar 03, 2013 8:25 pm Post subject: Problem with Xorg 1.13 vs Xorg 1.12. [SOLVED] |
|
|
Edit 2013-03-05: I've marked this 'Solved' because moving back to Xorg-1.12.4 has solved my immediate problem. However, it appears that Xorg-1.13.1 will not support Savage cards. See posts after this date for discussion.[/b]
I have just emerged Xorg in a new Gentoo installation on a machine with a working Gentoo install in another partition. Although Xorg initializes, only the top half of the screen is filled with a distorted image; the lower half displays the earlier content of the display buffer. The new install uses Xorg 1.13 whereas the earlier one is Xorg 1.12.
Thinking that the kernel 3.7.9 driver might be at fault, I copied the 3.5.7 kernel and module files from the earlier partition to the new one and booted into it, but without any change.
The earlier install ran fine without an xorg.conf file, but I decided to create one. I grepped the Modelines out of Xorg.0.log, pasted them into a newly-written /etc/X11/xorg.conf.d/xorg.conf, but Xorg ran the same with and without the config file.
I then copied this xorg.conf into the new installation. Xorg gives a clean screen with a colour depth of 8, but the same faulty result with colour depths of 16 and 24. I'd guess that one of three things could be wrong:
1. An error or oversight of my own in emerging Xorg. Both were done with x11-base/xorg-server udev in package.use.
2. A bug in the Gentoo version of Xorg 1.13.
3. A bug Xorg 1.13 itself.
The first seems the most likely. Could anyone point me to the next debug steps. Thanks for all replies.
I've posted copies of the xorg.conf file and the Xorg.0.log files at http://52midnight.com/xorg.html
Last edited by 52midnight on Thu Mar 07, 2013 12:54 am; edited 3 times in total |
|
Back to top |
|
|
popsUlfr Tux's lil' helper
Joined: 27 Feb 2011 Posts: 80
|
Posted: Sun Mar 03, 2013 9:33 pm Post subject: |
|
|
Hi midnight!
Could you backup your xorg.conf and replace the contents with this ?
Code: |
Section "Device"
Identifier "Savage"
Driver "savage"
EndSection
|
(you could also create the '/etc/X11/xorg.conf.d/' directory and drop a file (e.g.: 30-savage.conf) in there with these contents)
Right now during automatic detection without xorg.conf it loads the fbdev_drv module to take care of your card which may be the cause of the faulty results in the color depth. |
|
Back to top |
|
|
52midnight Apprentice
Joined: 20 Mar 2012 Posts: 176 Location: Brisbane AU
|
Posted: Sun Mar 03, 2013 9:46 pm Post subject: |
|
|
Did as you suggested with the same faulty result: top half of the screen has a bad image, bottom half untouched. Neither installation had an xorg.conf.d directory in /etc/X11/ - I had to create them myself. It seems the Xorg discovery process is judged reliable enough not to need a config file, but in this case it's not.
Question is why 1.12 works fine but 1.13 doesn't, unless there's something else I'm missing - could well be. |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21489
|
Posted: Sun Mar 03, 2013 10:13 pm Post subject: |
|
|
If you explicitly install Xorg 1.12 in the non-working installation, does that work correctly? |
|
Back to top |
|
|
52midnight Apprentice
Joined: 20 Mar 2012 Posts: 176 Location: Brisbane AU
|
Posted: Sun Mar 03, 2013 10:16 pm Post subject: |
|
|
> If you explicitly install Xorg 1.12 in the non-working installation, does that work correctly?
Good suggestion, but I'm not sure how that's done. I assumed that older versions were removed from the repo. Could you give a brief explanation? |
|
Back to top |
|
|
Jaglover Watchman
Joined: 29 May 2005 Posts: 8291 Location: Saint Amant, Acadiana
|
|
Back to top |
|
|
52midnight Apprentice
Joined: 20 Mar 2012 Posts: 176 Location: Brisbane AU
|
Posted: Sun Mar 03, 2013 11:37 pm Post subject: |
|
|
> I'm surprised savage was working for you, I have an old IBM T23 here and I was forced to switch to fbdev long time ago.
You've answered the question I didn't want to ask. My hardware is ... er ... vintage, but it still works fine and I see no reason to upgrade, unless support for drivers etc starts to die out. Problem is they won't leave well enough alone. To judge by the latest KDE and Gnome, the next generation of coders will keep "improving" everything until its quite unusable. |
|
Back to top |
|
|
Jaglover Watchman
Joined: 29 May 2005 Posts: 8291 Location: Saint Amant, Acadiana
|
|
Back to top |
|
|
52midnight Apprentice
Joined: 20 Mar 2012 Posts: 176 Location: Brisbane AU
|
Posted: Sun Mar 03, 2013 11:51 pm Post subject: |
|
|
> Try fbdev, works for me.
OK, I'll give it a go. At the moment I'm browsing the docn for how to emerge 1.12 instead of 1.13, but haven't found a solution. Can you offer a quick hint? |
|
Back to top |
|
|
Jaglover Watchman
Joined: 29 May 2005 Posts: 8291 Location: Saint Amant, Acadiana
|
|
Back to top |
|
|
52midnight Apprentice
Joined: 20 Mar 2012 Posts: 176 Location: Brisbane AU
|
Posted: Mon Mar 04, 2013 12:53 am Post subject: |
|
|
> emerge -av1 =xorg-server-1.12.4
Great, thanks! Will come back after some experimenting (compile time under steam power ~= days). |
|
Back to top |
|
|
52midnight Apprentice
Joined: 20 Mar 2012 Posts: 176 Location: Brisbane AU
|
Posted: Tue Mar 05, 2013 7:02 am Post subject: |
|
|
Following advice on this forum I've moved back to Xorg-1.12.4 and everything's fine. Thanks to all who assisted.
This suggests that Xorg-1.13.1 will not support Savage cards. I'm wondering whether it's worth reporting this to the Xorg developers. It's not conclusive; I may still have made an error, or there may be an error in the Gentoo build. But S3 chips were very popular and there are doubtless still plenty of Savage-equipped boxes out there still running. Any thoughts? |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21489
|
Posted: Wed Mar 06, 2013 1:57 am Post subject: |
|
|
I think a bug report is worth pursuing, now that we know that the environment can build some working Xorg servers. I suggested building the 1.12 series as a test of your environment, not as a long term solution. |
|
Back to top |
|
|
52midnight Apprentice
Joined: 20 Mar 2012 Posts: 176 Location: Brisbane AU
|
Posted: Wed Mar 06, 2013 2:33 am Post subject: |
|
|
OK, I'll get onto the Xorg site and file a bug report; will return here when there's something to post.
> I suggested building the 1.12 series as a test of your environment, not as a long term solution.
I'm happy either way, especially given this from Jaglover (more of a Triumph bike fan meself):
> I'm surprised savage was working for you, I have an old IBM T23 here and I was forced to switch to fbdev long time ago.
There are arguments for and against keeping old versions, but personally I believe that 'old' is rather meaningless where electronics technology is concerned. All societies worldwide are now critically dependent on electronics technology, including and especially computers, and a decade or two is nothing in comparison to the estimated lifetime of essential infrastructure.
By way of interest, the big banks have recently discovered this. Much of their critical code is written in COBOL, and now that they're trying to interface it to the latest PC/tablet/mobile technology, they're having to drag COBOL coders out of retirement villages and pump them full of Viagra and coke to get them writing interface code. |
|
Back to top |
|
|
52midnight Apprentice
Joined: 20 Mar 2012 Posts: 176 Location: Brisbane AU
|
Posted: Wed Mar 06, 2013 3:16 am Post subject: |
|
|
Dear Xorg
I am in process of installing Gentoo on my desktop PC, and have found it necessary to revert to Xorg-1.12.4 instead of the latest 1.13.1. Gentoo is a rolling release source distro, so one is usually faced with the latest versions of packages. When I emerged Xorg, version 1.13.1 was the default, but an earlier installation had installed 1.12.2, so I was in the fortunate position of being able to compare them on my rather outdated hardware. The results of my efforts are summarized in a file on my website, which contains the xorg.conf file I wrote, and four Xorg.0.log files resulting from investigation:
http://52midnight.com/xorg.html
Assistance from the participants on the Gentoo forum provided a successful workaround:
https://forums.gentoo.org/viewtopic-t-952908.html
but they also suggested that I file a bug report with Xorg. I trust that this may suffice as such.
With many thanks for your invaluable code
52midnight
_________________________________________________________
Your mail to 'xorg' with the subject
Failure to support 'savage' driver in 1.13.1
Is being held until the list moderator can review it for approval.
The reason it is being held:
Post by non-member to a members-only list
Either the message will get posted to the list, or you will receive
notification of the moderator's decision. If you would like to cancel
this posting, please visit the following URL: |
|
Back to top |
|
|
52midnight Apprentice
Joined: 20 Mar 2012 Posts: 176 Location: Brisbane AU
|
Posted: Wed Mar 06, 2013 8:08 am Post subject: |
|
|
From: Tormod at Xorg
Refer: http://lists.x.org/archives/xorg/2013-March/055513.html
See also https://bugs.launchpad.net/bugs/1083032 . The easiest
workaround for now is to use DisableTile. This disables most of what
was left of hardware acceleration, but still might have some advantage
(i.e. modesetting, outputs) over the vesa driver.
Section "Device"
Identifier "mypoorsavage"
Option "DisableTile"
EndSection
I intend to investigate this further when I find more time. I've been
thinking there might be some initialization hook that isn't called
from the server any longer.
Best regards,
Tormod |
|
Back to top |
|
|
52midnight Apprentice
Joined: 20 Mar 2012 Posts: 176 Location: Brisbane AU
|
Posted: Wed Mar 06, 2013 8:25 pm Post subject: |
|
|
From: Tormod at Xorg
From a quick look through the xserver git log, this commit looks like exactly that:
* commit 785af88ab0120036e0ce3d0139f3c560ff71e10b
* Author: Dave Airlie <airlied@redhat.com>
* Date: Wed Sep 26 16:16:40 2012 +1000
*
* dri1: fix dri1 startup since 459c6da0f907ba33d733c7e62a116184ba2f14e5
*
* This commit regresses dri1 since it moves the drmSetServerInfo from being
* called at module load time to extension init time. However DRIScreenInit
* relies on this being called before it gets control.
*
* This patches moves the call into DRIScreenInit and seems to work here.
Looks like the regressing commit ended up in 1.13 and the fixup in 1.14.
Can you gentoo guys "emerge" to xserver 1.14 and see if that fixes the issue?
Regards,
Tormod |
|
Back to top |
|
|
chithanh Developer
Joined: 05 Aug 2006 Posts: 2158 Location: Berlin, Germany
|
Posted: Wed Mar 06, 2013 9:13 pm Post subject: |
|
|
The 1.14 release candidates have been in portage for quite some time already (under package.mask). |
|
Back to top |
|
|
|