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

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

[Wil Reichert]

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.
Refuses to start now with the following error:

~ $ gnome-terminal
The program 'gnome-terminal' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
  (Details: serial 1097 error_code 8 request_code 72 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

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

Wil
-- 
gentoo-amd64@gentoo.org mailing list

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

[Duncan]

"Wil Reichert" <wil.reichert@gmail.com> posted
7a329d910703100823o1f5d91c5n9378510dfddbf027@mail.gmail.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@gentoo.org mailing list

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

[Wil Reichert]

> 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

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

[Peter Humphrey]

On Saturday 17 March 2007 11:35:35 Duncan wrote:

> I ... 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 think its arrogance is on a par with that of Windows, myself. We aren't to 
be trusted with any of that clever stuff, so it must be hidden deep.

-- 
Rgds
Peter Humphrey
Linux Counter 5290, Aug 93
-- 
gentoo-amd64@gentoo.org mailing list

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

[B. Nice]

I recently had to revert back to xorg-server  1.2.0-r1 to regain the
ability to use gnome-terminal (or any terminal in gnome)  In my case the
system was still rock solid, but the terminals just disappeared, and
would not re-appear using any of the icons/menus.  I didn't (still
don't) know how to use a virtual terminal(Ctrl-Alt-F1-F6) to open a
window in the X terminal so, reverted it went.

Wish I could offer more assistance.



On Sat, 2007-03-17 at 07:14 -0700, Wil Reichert wrote:
> > 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
> 

-- 
gentoo-amd64@gentoo.org mailing list

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

[B. Nice]

Or to tempt the flame-war that always seems to occur when comparing the
philosophy of Gnome vs. KDE.

Gnome provides you with what 90% of the users need, and with effort, you
can access most of what the rest want.  KDE floods you with every
conceivable option and leaves it up to you to ignore the un-needed
cruft, and hides the option to remove the excess.

Who's right.  Who cares. IMNSHO it is extremely ignorant and arrogant to
assume that one philosophy is superior to the other.  Hopefully with the
major and minor Desktop Environments competing, everyone can be
satisfied.

Just a thought

On Sat, 2007-03-17 at 16:11 +0000, Peter Humphrey wrote:
> On Saturday 17 March 2007 11:35:35 Duncan wrote:
> 
> > I ... 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 think its arrogance is on a par with that of Windows, myself. We aren't to 
> be trusted with any of that clever stuff, so it must be hidden deep.
> 
> -- 
> Rgds
> Peter Humphrey
> Linux Counter 5290, Aug 93

-- 
gentoo-amd64@gentoo.org mailing list

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

[Duncan]

"B. Nice" <anonymous.pseudonym.88@gmail.com> posted
1174159371.6186.10.camel@ShadowBook.Workgroup, excerpted below, on  Sat,
17 Mar 2007 15:22:51 -0400:

> Who's right.  Who cares. IMNSHO it is extremely ignorant and arrogant to
> assume that one philosophy is superior to the other.  Hopefully with the
> major and minor Desktop Environments competing, everyone can be
> satisfied.

Agreed.  GNOME drives me to distraction, but apparently some folks like 
it.  Variety is what FLOSS is good at, so let's celebrate the 
differences, and be glad there remains the choice. =8^)

Another way to look at it is that all the devs that like the dumbed down 
interface will be attracted to GNOME, leaving KDE in less danger of 
having them come in and try to dumb it down too.  Of course the reverse 
is true as well, the folks that like to have everything customizable will 
be attracted to KDE, leaving the GNOME folks in relative peace to do it 
their way.  As long as the GNOME folks stay there and don't try to dumb 
down KDE, I'm happy, and I'm sure many GNOME users say the same about KDE 
devs and "needless complexity".

-- 
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@gentoo.org mailing list

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

[The Doctor]

[-- Attachment #1: Type: text/plain, Size: 880 bytes --]

On Sat, 2007-03-17 at 15:22 -0400, B. Nice wrote:

> Who's right.  Who cares. IMNSHO it is extremely ignorant and arrogant to
> assume that one philosophy is superior to the other.  Hopefully with the
> major and minor Desktop Environments competing, everyone can be
> satisfied.

There are also users out there who don't use a desktop environment at
all, just a window manager.  Environments like Gnome or KDE (I'm not
playing any least-favorites here) might be overkill for someone's
hardware, or offer features that will just be turned off, anyway.  Why
run the Gnome panel when GKrellm does what you need?  Why start up KDE
when Fluxbox gives you just enough?

The Doctor [412/724/301/703]

PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1
WWW: http://drwho.virtadpt.net/

To err is human. To really screw up requires the root password.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]