From: "Wil Reichert" <wil.reichert@gmail.com>
To: gentoo-amd64@lists.gentoo.org
Subject: Re: [gentoo-amd64] Re: Anyone tried xorg-server-1.2.99.901?
Date: Sat, 17 Mar 2007 07:14:23 -0700 [thread overview]
Message-ID: <7a329d910703170714q2152d6f0t604a00671a6b6a1d@mail.gmail.com> (raw)
In-Reply-To: <pan.2007.03.17.11.35.34@cox.net>
> 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.
Never could get over the UI, didn't seem intuitive to me for whatever
reason. Been following KDE 4 development, look pretty spiffy.
Probably give it a shot again once it goes alpha. Could be mistaken
but it almost seems like the gnome folk are more concerned about their
release schedule than innovating new features.
> Anyway, this build doesn't have the patches applied, and exa works fine
> once again.
I think an exa update was one of the main additions in 1.3, the other
being the randr 1.2 code.
> 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.
A couple of emerge -e world's later....
metacity - gnome-terminal starts fine, <CTRL><SHIFT>T creates a new tab
beryl - gnome-terminal starts fine, <CTRL><SHIFT>T crashes it as before
I'll chalk this one up to either stupidity on my part or the beryl svn
code I'm using is conflicting with the new driver / server code. No
big, some breakage is to be expected running ~arch & live code. FWIW,
I'm using XAA and have xcb enabled. EXA makes little difference on my
system, haven't had a chance to see what recompiling w/out xcb will
do. The next rc build should be hitting portage soon, I'll probably
just wait & see if that does some magic. Or breaks more stuff =)
Wil
--
gentoo-amd64@gentoo.org mailing list
next prev parent reply other threads:[~2007-03-17 14:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-10 16:23 [gentoo-amd64] Anyone tried xorg-server-1.2.99.901? Wil Reichert
2007-03-17 11:35 ` [gentoo-amd64] " Duncan
2007-03-17 14:14 ` Wil Reichert [this message]
2007-03-17 19:13 ` B. Nice
2007-03-17 16:11 ` Peter Humphrey
2007-03-17 19:22 ` B. Nice
2007-03-17 23:47 ` Duncan
2007-03-18 15:17 ` The Doctor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7a329d910703170714q2152d6f0t604a00671a6b6a1d@mail.gmail.com \
--to=wil.reichert@gmail.com \
--cc=gentoo-amd64@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox