public inbox for gentoo-amd64@lists.gentoo.org
 help / color / mirror / Atom feed
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



  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