[gentoo-amd64] Re: Anyone tried xorg-server-1.2.99.901?

[Duncan]

"Wil Reichert" <wil.reichert@×××××.com> posted
7a329d910703100823o1f5d91c5n9378510dfddbf027@××××××××××.com, excerpted
below, on  Sat, 10 Mar 2007 08:23:31 -0800:

> Saw the announcement on the xorg list, saw it in portage, had to try it.
> Running ~amd64 so I've had the randr-1.2 upgrade fo r a while. Also
> upgraded to xf86-video-i810-1.9.91 as well.  Pretty painless upgrade -
> restarted xdm and logged in.  Beryl still worked, everything else seemed
> to be ok.  Well, with the exception of gnome-terminal.

Thanks to your post (which I saved as unread until I had a chance to 
upgrade), I'm running it now. =8^)  Actually, it's running far better for 
me than 1.2.0-r1 (~arch) was.  That one had serious problems with exa, 
and on my hardware with composite enabled, xaa is MUCH slower than exa, 
so exa is VASTLY preferable, when it works, as it did in the earlier 
versions and does now again in 1.2.99.901.  So far, it's working great, 
no problems at all, altho I've not really noticed anything better or 
faster about it as compared to 1.2.0.  (I'm reasonably sure the problems 
in 1.2.0-r1 were due to Gentoo patches, which at one point had a comment 
saying they broke exa for some people... well they did!

I run KDE here, don't even have GNOME installed as for me as a power 
user, GNOME's dumb-down-everything-by-removing-most-choices-as-too-
complex policy drives me right up one wall and down the other!  (I'm with 
Linus on that one, it seems!)  I'm running kwin, with composite 
functionality enabled (only window semi-transparency, not the other 
stuff) as I mentioned above.  

Video card is a Radeon 9200, running the native xorg Radeon driver, dual 
21" monitors running @ 1600x1200 stacked for 1600x2400 total desktop 
resolution (normal unzoomed mode), in the Radeon driver's merged 
framebuffer mode.  

I believe the bug with the patches mentioned above was due to the fact 
that OpenGL only works with this card up to 2048x2048, so there's an area 
352 px high at the bottom of my work area that's 2D only, the problem 
being that the patches tried to run the entire desktop (or at least 
certain apps on it, including konsole) as 3D, which caused them to auto-
blank as soon as they dropped into this 3D-dead-zone.  If I were to cut 
back to 1360x1024 (odd resolution, but maintaining the 4x3 ratio), so the 
stacked height was 2048, it would eliminate that dead zone and I think I 
would have been fine, but 1600x1200 is the "native" resolution for these 
monitors (yes, CRTs have a native resolution, the resolution they look 
best at given the dot-pitch) and I use it and don't want to lose the 
pixels, so...

Anyway, this build doesn't have the patches applied, and exa works fine 
once again.

> [Gnome-terminal r]efuses to start now with the following error:

[snipped as it's Greek to me.]

> revdep-rebuild shows nothing, prolly just need to re-emerge something.
>  Any other successes / failures?

As I said, everything's working great here, better even than the latest 
non-masked ~arch version! =8^)

If you've not already done so and the lack of gnome-terminal is serious 
for you, of course there are quite a few other alternatives, xterm being 
the generic one, naturally.

Thinking about your bug, perhaps you have the reverse problem to mine, as 
konsole (compare to gnome-terminal) did run here but as I said, with 
issues (blanking and the like).  You might dig out the AIGLX patches from 
1.2.0-r1 and see if they still apply cleanly to 1.2.99.901.  If they do, 
try that and see if your problem still exists.  Take a look at the ebuild 
but I /think/ all you have to do is list the appropriate patches in a 
PATCHES= line, copying the ones from the line in the ~arch version 
to .901 in your overlay.  A single bit of editing, not too hard.  (I was 
going to try building without those patches here, but never got around to 
it before seeing your post mentioning the new version, so tried it 
instead.)

If that fixes your problem, then it's likely those patches may have to be 
hooked to a USE flag of some sort, so people can apply them or not 
depending on the hardware and software they run.

Something else that /might/ be worth trying.  Enable (or disable, if you 
have it enabled) USE=xcb, and do an emerge -N world to rebuild anything 
using that flag.  xcb is a new and lighter alternative to Xlib.  Xlib can 
render to it for anything not yet migrated to xcb yet, and that's what 
most X clients are using if xcb is enabled at this point, xlib thru xcb.

I decided to try enabling it at the same time I upgraded to xorg-server 
1.2.99.901, and one of the things that got rebuilt as a result was cairo, 
which of course is what GTK+ now uses for rendering, and GNOME of course 
in turn uses GTK+. (I do have GTK+ merged, as a pan dependency, but no 
GNOME.)

What I'm thinking is that xcb might bypass whatever issue you are having, 
particularly if it's a deprecated xlib call that's no longer working, 
since xcb is newer and presumably written with AIGLX and similar new 
technologies in mind, where xlib has a lot of compatibility cruft left 
over from long ago versions.  I've seen the difference that makes in xaa/
exa, xlib/xcb could well make a similar difference.

So anyway, please update if you try any of the suggestions above, whether 
or not they work, or if you get it working again otherwise.  I'm always 
interested in finding out if my guesses were correct or not, as it's very 
useful info the next time something similar comes up.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@g.o mailing list