IIRC, SunRay's require using Xsun still. So he wouldn't have the composite extension available, but Xorg is often installed so it may be compiled with support for composite.

On 12/21/05, Kim Woelders <kim@woelders.dk> wrote:
Mark R. Bowyer wrote:
> On Tue, 2005-12-20 at 21:26, Kim Woelders wrote:
>>>On Solaris Nevada on my x64 laptop, it works fine.  On a SunRay running
>>>off a SPARC-based server running the same Solaris release, with both
>>>0.20 and now this pre1, on starting I'd get the split screen, the 2
>>>progress meters at the top would go, and then it would just freeze that
>>>way.  Truss shows it reading and writing forever on fd 4, with the
>>>occasional "Err#11 EAGAIN" message on a read.  If I clear away my ~/.e16
>>>and start that way, I see the extra progress meter as it looks for
>>>backgrounds, but then the same long wait.  It happens whether or not I
>>>use the -p argument.  I've left it over 5 minutes and it's not helped.
>>>Version 0.17 worked fine, as did all the ones before?
> OK, further testing later:
>>Not sure what goes on here. If there is a session manager I'd expect
>>that connection on fd 4. Is there a session manager involved? I don't
>>recall having made changes to that in ages though. If not, can you find
>>out what is on fd 4?
> Well, all my tests now it was fd 3, which according to pfiles is an
> AF_UNIX socket at /tmp/.X11-unix/X3 - I've been getting :3.0 as my
> display on this SunRay server.  So it's the local talking to the X
> server that's going on, which is expected?
Yes, the X-server connection will normally be on fd 3.

>>Could you find out in which version (.18/.19/.20) the problem first appears?
> .18 no longer exists on the sourceforge site.

It can still be found here:
Could you please try that as well?

> I built .19, and it
> happens there.  I installed it, and logged out and in as a "Failsafe"
> session - X and one dtterm.  Started e16 from .19 and see the closed
> doors for a long time.  Did the truss and pfiles from my Linux box next
> to the SunRay.  Same thing.  Killed e16, logged back in to Gnome
> (gnome-session is starting "e16 -p e_config") and same thing for fd 3.
> Go back into my .17 build directory, "gmake install", and the problem
> has gone away again.  Note I've tried without the -p - that isn't it.
> So, go back to .19, and try starting it with --fast as well.  And we get
> in to a windowing environment, and all seems well.  But no dialogues
> will come up (menus will) and windows wont raise, and a number of other
> issues show up.  I can *move* windows, but it's not fully functional.
> Back to .17, and everything's back again, including the "About" box.
> All a bit trippy, really.  It's like a central part of E isn't working
> any more...  The only thing I've not tried is rebuilding .17 in case
> it's something about how I built it.  I'm going to make sure I have a
> safe backup of the working code first, and will then try that.
> Does this give you any clues?
Not really. There are quite a few changes between .17 and .19. Results
for .18 will narrow down the possibilities considerably.

It sounds like some OS/X-server dependent issue. Which X-server are you
using? If xorg, is e16 built with composite support?

If running with/whithout --fast makes a difference the problem may
somehow be related to the startup windows ("split screen"). In .19 could
you try changing in src/startup.c
and see if that changes anything?


This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
enlightenment-devel mailing list