In <URL:news:local.port-arm32> on Sun 17 Jan, Neil A. Carson wrote:
> Brian,
> 
> The CATS X11 sources have not been fed back yet. You can e-mail Mark
> mark@causality.com for source code. It's currently a bit of a hack,
> which is why it's not published yet. X11R6 isn't anywhere near as
> portable as we initially hoped, which is why ther are some stability
> issues as you have observed.
Thanks for that - Marks contacted me now.

> 
> That's interesting if shared memory/local transport is the problem. If
> you do something like setenv DISPLAY localhost:0.0 then does it still
> work? I presume so.

It still breaks, but I think thats just because X is too smart about working
out whether to use shared memory. Running it on a different machine works.

Anyway, on investigation, it turns out that the latest version of gtk always
tries to use shared memory, even when just reading a xpm file into a bitmap.
If I go in and disable that, then it works fine. (Well better, and fine if I
disable shared memory for stepping video frames as well)

I'm slightly suspicious that it may be the kernel at fault because of our
other problem with emacs, (which reliably fails to run twice from the same
binary file), but I'm having problems getting current to build - fixed a few
odd prototype mismatches, commented obsolete stuff from arm32/machdep.c
etc...

Is there a simple recipe for what to enable disable for the new console stuff
to work - I'm a little confused about vga/wsdisplay etc, whats new and whats
old.

At the moment it falls over in cnopen because its not getting the right
device number passed up from the low level kernel console thing in cn_tab.
I'm about to try fixing that too...

> 
> When life is fully organised in the US, we should pull up XF86 3.3.3 to
> the CATS.
> 
> 	Regards,
> 
> 	Neil
> 

-- 
The past is a fading dream, the future mere speculation - live for the moment
Brian Brunswick bdb@eidos.co.uk   Disclaimer  !Shortsig! <SPAM_ACCEPT="NONE">