Re: E and Solaris 2.6 bugs



On 10 Mar, Mark R. Bowyer scribbled:
->  
->  >From: Glenn Kronschnabl <grk@arlut.utexas.edu>
->  >2) everytime I try to change an E theme, it complains that another
->  >enlightenment WM is running (which is wrong - I have verified this
->  >_everytime_), and it doesn't matter if I hit cancel or ok, E proceeds to
->  >lock up the entire X session, and I have to go to another terminal and
->  >kill E - then everything works okay.
->  >
->  >3) Display problems - sometimes the refresh of windows gets screwed up
->  >(i.e., they don't repaint themselves).  Even weirder, this only happens
->  >with GNOME apps, Netscape doesn't exhibit this problem.  When I switched
->  >to dtwm (not something I like to do), the repaint problem went away.
->  
->  This number (3) is almost certainly a framebuffer (video card) driver bug.  Make 
->  sure you have all the latest Sun patches for X and your video card for 2.6.
->  
->  Number (2) though, plus this:
->  
->  >From: Tomas Ogren <stric@ing.umu.se>
->  >I have to say that I've only been compiling E a couple of times, just to
->  >check the progress (machines too slow for E right now, fvwm2 works like
->  >a charm).. And in a few of those tries (not all I think) E has had
->  >problems restarting, saying that a WM is already running...
->  
->  I've always seen this too.  And I'm running Solaris 8_alpha on an Ultra10/300 - 
->  so I doubt it's the slow system speed that Tomas suggests =OZ
->  
->  I've always put this down to having 2 screens, and so I *do* have 2 copies of 
->  Enlightenment running when I click "Restart".  But sure enough, if I kill one, 
->  and then attempt to restart the other, I *still* get told it can't restart as 
->  another window manager is running...  How odd.

one process is forked... it handles the "screen" thats put up whilst
restarting.. thsi screen stays up to "cover up" nasty operations behind
the scenes.. it does have its own display connection etc. though. maybe
somehow the fd under solaris is retained between forks so the display
connection is still active.. and thus select on root window still
active... tho it seems on linux this doesnt happen. (Xlib sets the X fd
to "close on exec").

->  Since I can't reproduce the long pause in Enlightenment's startup at 94% (since 
->  I upgraded to GNOME 1.0.1 and GTK+ 1.2 - so that was probably it) I'll use what 
->  time I have now to try and debug this.  Don't let that stop anyone else from 
->  trying too, though ;O)

oh oh oh oh... I know.. coudl it perchance have ben E attempting to
connect to the session manager (gnome-session) and the connection et.c
just hanging till gnome-session responded. and now that's been
fixed????????????? *baffle again*

-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
raster@rasterman.com       /\___ /\ ___/||\___ ____/|/\___  raster@redhat.com
Carsten Haitzler           | _ //__\\ __||_ __\\ ___|| _ /  Red Hat Advanced
218/21 Conner Drive        || // __ \\_ \ | |   \ _/_|| /   Development Labs
Chapel Hill NC 27514 USA   ||\\\/  \//__/ |_|   /___/||\\   919 547 0012 ext 282
+1 (919) 929 9443, 801 4392   For pure Enlightenment   http://www.rasterman.com/

              \|/ ____ \|/  For those of you unaware. This face here is in fact
	      "@'/ ,. \@"   a Linux Kernel Error Message.
	      /_| \__/ |_\
		 \__U_/
							   



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]