Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Problem with Xorg 1.13 vs Xorg 1.12. [SOLVED]
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Installing Gentoo
View previous topic :: View next topic  
Author Message
52midnight
Tux's lil' helper
Tux's lil' helper


Joined: 20 Mar 2012
Posts: 131
Location: Brisbane AU

PostPosted: Sun Mar 03, 2013 8:25 pm    Post subject: Problem with Xorg 1.13 vs Xorg 1.12. [SOLVED] Reply with quote

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
View user's profile Send private message
popsUlfr
Tux's lil' helper
Tux's lil' helper


Joined: 27 Feb 2011
Posts: 80

PostPosted: Sun Mar 03, 2013 9:33 pm    Post subject: Reply with quote

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
View user's profile Send private message
52midnight
Tux's lil' helper
Tux's lil' helper


Joined: 20 Mar 2012
Posts: 131
Location: Brisbane AU

PostPosted: Sun Mar 03, 2013 9:46 pm    Post subject: Reply with quote

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
View user's profile Send private message
Hu
Watchman
Watchman


Joined: 06 Mar 2007
Posts: 8908

PostPosted: Sun Mar 03, 2013 10:13 pm    Post subject: Reply with quote

If you explicitly install Xorg 1.12 in the non-working installation, does that work correctly?
Back to top
View user's profile Send private message
52midnight
Tux's lil' helper
Tux's lil' helper


Joined: 20 Mar 2012
Posts: 131
Location: Brisbane AU

PostPosted: Sun Mar 03, 2013 10:16 pm    Post subject: Reply with quote

> 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
View user's profile Send private message
Jaglover
Advocate
Advocate


Joined: 29 May 2005
Posts: 4635
Location: Saint Amant, Acadiana

PostPosted: Sun Mar 03, 2013 11:27 pm    Post subject: Reply with quote

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.
_________________
Please learn how to denote units correctly!
Back to top
View user's profile Send private message
52midnight
Tux's lil' helper
Tux's lil' helper


Joined: 20 Mar 2012
Posts: 131
Location: Brisbane AU

PostPosted: Sun Mar 03, 2013 11:37 pm    Post subject: Reply with quote

> 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
View user's profile Send private message
Jaglover
Advocate
Advocate


Joined: 29 May 2005
Posts: 4635
Location: Saint Amant, Acadiana

PostPosted: Sun Mar 03, 2013 11:41 pm    Post subject: Reply with quote

Try fbdev, works for me.
_________________
Please learn how to denote units correctly!
Back to top
View user's profile Send private message
52midnight
Tux's lil' helper
Tux's lil' helper


Joined: 20 Mar 2012
Posts: 131
Location: Brisbane AU

PostPosted: Sun Mar 03, 2013 11:51 pm    Post subject: Reply with quote

> 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
View user's profile Send private message
Jaglover
Advocate
Advocate


Joined: 29 May 2005
Posts: 4635
Location: Saint Amant, Acadiana

PostPosted: Mon Mar 04, 2013 12:28 am    Post subject: Reply with quote

emerge -av1 =xorg-server-1.12.4
_________________
Please learn how to denote units correctly!
Back to top
View user's profile Send private message
52midnight
Tux's lil' helper
Tux's lil' helper


Joined: 20 Mar 2012
Posts: 131
Location: Brisbane AU

PostPosted: Mon Mar 04, 2013 12:53 am    Post subject: Reply with quote

> emerge -av1 =xorg-server-1.12.4

Great, thanks! Will come back after some experimenting (compile time under steam power ~= days).
Back to top
View user's profile Send private message
52midnight
Tux's lil' helper
Tux's lil' helper


Joined: 20 Mar 2012
Posts: 131
Location: Brisbane AU

PostPosted: Tue Mar 05, 2013 7:02 am    Post subject: Reply with quote

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
View user's profile Send private message
Hu
Watchman
Watchman


Joined: 06 Mar 2007
Posts: 8908

PostPosted: Wed Mar 06, 2013 1:57 am    Post subject: Reply with quote

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
View user's profile Send private message
52midnight
Tux's lil' helper
Tux's lil' helper


Joined: 20 Mar 2012
Posts: 131
Location: Brisbane AU

PostPosted: Wed Mar 06, 2013 2:33 am    Post subject: Reply with quote

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
View user's profile Send private message
52midnight
Tux's lil' helper
Tux's lil' helper


Joined: 20 Mar 2012
Posts: 131
Location: Brisbane AU

PostPosted: Wed Mar 06, 2013 3:16 am    Post subject: Reply with quote

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:

http://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
View user's profile Send private message
52midnight
Tux's lil' helper
Tux's lil' helper


Joined: 20 Mar 2012
Posts: 131
Location: Brisbane AU

PostPosted: Wed Mar 06, 2013 8:08 am    Post subject: Reply with quote

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
View user's profile Send private message
52midnight
Tux's lil' helper
Tux's lil' helper


Joined: 20 Mar 2012
Posts: 131
Location: Brisbane AU

PostPosted: Wed Mar 06, 2013 8:25 pm    Post subject: Reply with quote

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
View user's profile Send private message
chithanh
Developer
Developer


Joined: 05 Aug 2006
Posts: 1661
Location: Berlin, Germany

PostPosted: Wed Mar 06, 2013 9:13 pm    Post subject: Reply with quote

The 1.14 release candidates have been in portage for quite some time already (under package.mask).
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Installing Gentoo All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum