HDTenEightyP/NetNews huggingface dataset:
From: Conrad_Nobili@Harvard.EDU (Conrad C. Nobili)
Newsgroups: comp.windows.x.i386unix
Subject: Re: X386 on Tandy 48000
Date: 12 Jan 93 22:04:24 GMT
Followup-To: comp.windows.x.i386unix
Organization: Harvard University Office for Information Technology

In article <mengel.726823221@fnsg01.fnal.gov>, mengel@fnsg01.fnal.gov (Marc
Mengel) wrote:

> I have been trying to get X386 to run on my new Tandy notebuook PC

> The system appears to have a Cirrus  GL-GD6410-320C-A chip, and
> a TwinHead 6460B chip next to it right up against the external VGA plug.

> Has anyone any idea what if any chipset this Cirrus monstrosity
> (it's a HUGE chip) might be emulating, or have of the TwinHead?!?

Well, I suspect this is a TwinHead slimnote, same as Altima, Compudyne, and
a few other companies that put their names on these Taiwanese clones.  I
don't recognize the model number in the Subject: but I do know that RS also
sells these.  I have a Compudyne version (the 486DX/33 one if that helps). 
I don't have it with me at the moment so can't tell you whether my chips
have the same exact numbers.  They sound similar though....

You should have no problems getting XFree86 running in mono.  If you have
the built-in trackball thingy you will need to do the right things to use
it with X.

All of the information you need should be in the FAQs.

Conrad C. Nobili  N1LPM  Conrad_Nobili@Harvard.EDU  Harvard University OIT
From: pb@idca.tds.philips.nl (Peter Brouwer)
Newsgroups: comp.windows.x.i386unix
Subject: gcc and shared libs in X386 1.1b ( X11R4 )
Date: 12 Jan 93 08:46:25 GMT
Reply-To: pb@idca.tds.philips.nl (Peter Brouwer)
Organization: Digital Equipment Enterprise B.V.,Apeldoorn,The Netherlands.

X-Disclaimer: This opinion is mine alone

I am trying to compile the X386 1.1b ( X11R4 ) release with gcc.
Shared libraries build are compiled with no errors. When linking with
applications I get errors, complaining about noload sections.
Compilation and linking with AT&T cc works okee.
When looking at the library object I see gcc creating bss data while the cc
does not have any bss sections.
Does gcc not work at all for generating shared libs or do I have to use on of
the many options from gcc to get the right object format.
I am using gcc 2.2.2 on a AT&T Unix V 3.2.


--
#  Peter Brouwer,                | Digital Equipment Enterprise ,              #
#  NET  : pb@idca.tds.philips.nl | Integration Industry Standard Systems,      #
#  PHONE:ext [+31] [-0]55 432992,| Dept Systems Enginering, Bld V1/B4          #
#  FAX  :ext [+31] [-0]55 432070 | P.O.Box 245,7300AE Apeldoorn,The Netherlands#
Newsgroups: comp.windows.x.i386unix,comp.windows.x,comp.unix.sysv386
From: dwex@cbnewsj.cb.att.com (david.e.wexelblat)
Subject: Re: Should XFree86 work with fs ?
Organization: AT&T
Date: Tue, 12 Jan 1993 19:57:26 GMT

In article <C0ponn.EGC@compound.se> smith@compound.se (Bjorn Smith) writes:
> We are having problems getting XFree86 working with the font server
> supplied in the X11R5 source. The command fsinfo -server comsys:7000
> gives the following output (wich appears to be ok):
> 
>   name of server:	comsys:7000
>   version number:	2
>   vendor string:	MIT X Consortium
>   vendor release number:	5001
>   maximum request size:	16384 longwords (65536 bytes)
>   number of catalogues:	1
> 	  all
>   Number of alternate servers: 0
>   number of extensions:	0
> 
> The command fslsfonts lists all the expected fonts as well.
> 
> The servers Xconfig file contains:
> 
>   #
>   # some nice paths, to avoid conflicts with other X-servers
>   #
>   #FontPath	"/usr/X386/lib/X11/fonts/misc/"
>   FontPath	"/usr/X386/lib/X11/fonts/misc/,:comsys:7000"
> 
> When starting the X386 server I get the following message:
> 
>   XFree86 Version 1.1 / X Window System
>   (protocol Version 11, revision 0, vendor release 5000)
>   Configured drivers:
>     VGA256 (256 colour SVGA):
>         et4000, et3000, pvga1, gvga, ati, tvga8900
>   (using VT number 1)
>   VGA256: et4000 (mem: 1024k numclocks: 16)
>   VGA256:   clocks: 25 28 61 72 79 69 50 64 13 14 36  0 40 26  0 33
>   VGA256: SpeedUp mode selected (Flags=0x3f)
>   failed to set default font path '/usr/X386/lib/X11/fonts/misc/,:comsys:7000'
>   Fatal server error:
>   could not open default font 'fixed'
>   giving up.
>   xinit:  Software caused connection abort (errno 130):  unable to connect to X server
>   xinit:  No such process (errno 3):  Server error.
> 
> Removing the font server item in Xconfig makes the X386 start properly !
> What could possibly be wrong ?
> 
> Thanks in advance for any kind of help,
> --
> Bj|rn Smith	Compound Systems, phone +46 8 7923689
> UUCP:	 	{uunet,mcsun}!seunet!comsys!smith
> Domain Address:	smith@compound.se
> -- 
> Bj|rn Smith	Compound Systems, phone +46 8 7923689
> UUCP:	 	{uunet,mcsun}!seunet!comsys!smith
> Domain Address:	smith@compound.se


Well, it's a bug, but not what you think.  The X386 manual page has the wrong
syntax for specifying the font server (fixed in the next release).

Change your FontPath line to:

	FontPath	"/usr/X386/lib/X11/fonts/misc/,tcp/comsys:7000"

and everything should be fine.

For whatever reason I don't understand, the X server will die if ANY
piece of the font path is invalid.  Sigh.  This is in the MIT code
that we haven't touched.  We are looking into remedying this fact, but
haven't tracked down a good solution yet.  XFree86 1.2 will do a lot
of font path validation during parsing of the Xconfig file, but it
can't do much with font servers at that point.

--
David Wexelblat <dwex@mtgzfs3.att.com>  (908) 957-5871
AT&T Bell Laboratories, 200 Laurel Ave - 3F-428, Middletown, NJ  07748

"The meaning of life?  That's simple.  Try to be happy, try not to hurt
 other people, and hope to fall in love."  -- Mallory Keaton
Newsgroups: comp.windows.x.i386unix
From: dwex@cbnewsj.cb.att.com (david.e.wexelblat)
Subject: Re: non-stop X386
Organization: AT&T
Date: Tue, 12 Jan 1993 19:17:48 GMT

In article <1993Jan12.002227.1843@cbnewsh.cb.att.com> billc@pegasus.ATT.COM (Bill Carpenter) writes:
> I recently converted to XFree86 from my home-cooked X11r5.  When I run
> my old stuff, I can shut the server down in the usual ways (ie, my
> last client in ~/.xinitrc ends, xinit kills the server).
> 
> When I run the server from XFree86, I can't get rid of the server
> except with the CTL-ALT-BS sequence.  When that last client dies, the
> server looks like it's shutting down, but a couple of seconds later it
> seems to reinitialize itself and give me the gray background and
> default mouse cursor.  No clients appear.  I've waited 5-10 minutes to
> see if something just had to time out, but no change.  It dies quickly
> when I punch CTL-ALT-BS.  (I tried NoTrapSignals, but didn't notice
> any change.)

Hmm.  This is odd.  Forget about NoTrapSignals - you don't want it on,
unless you are debugging the server - with it set, if the server aborts
abnormally, you may not get your screen back.  That's in there for us
to debug with, and for people to get us coredumps if necessary.

> 
> I'm on a 386 running AT&T UNIX SVR4.0.2.1a with an ET4000 video card.
> My XFree86 stuff was picked up recently from bradley.edu.
> 
> Any clues?


Hmm.  Not really.  I know that AT&T SVR4 uses a different TCP/IP package
than the other SVR4 packages.  Maybe somthing odd is happening with
unix-domain sockets.  Try adding

	xhost +
	DISPLAY=localhost:0

to the top of your .xinitrc, which should force TCP/IP for all connections.

I will ask on our beta list to see if anyone else is having this problem.  
Anyone our here in the real world having this problem, or using AT&T
2.1 without problems?

> -- 
>   Bill@attmail.com                    billc@pegasus.ATT.COM    or
>   (908) 576-2932                      William_J_Carpenter@ATT.COM
>   AT&T Bell Labs / AT&T EasyLink Services               LZ 3C-207


--
David Wexelblat <dwex@mtgzfs3.att.com>  (908) 957-5871
AT&T Bell Laboratories, 200 Laurel Ave - 3F-428, Middletown, NJ  07748

"The meaning of life?  That's simple.  Try to be happy, try not to hurt
 other people, and hope to fall in love."  -- Mallory Keaton

Newsgroups: comp.windows.x.i386unix,comp.windows.x,comp.unix.pc-clone.32bit,comp.os.linux.announce,comp.unix.bsd,comp.os.mach
From: dwex@mtgzfs3.att.com (David E Wexelblat)
Subject: X-for-Intel-Unix BOF at the X Technical Conference
Followup-To: comp.windows.x.i386unix
Keywords: XFree86, X Conference
Organization: AT&T
Date: Wed, 6 Jan 1993 21:27:43 GMT

I will be hosting a Birds-of-a-Feather (BOF) session at the X Technical
Conference.  The topic for the session is "X For Intel-based Unix",
and it is scheduled for 5:30-7PM on Wednesday 1/20/93.

I am soliciting ideas for topics for discussion at this session.  I
intend to discuss the current status and future plans for XFree86
(along with Jim Tsillas, one of my cohorts in crime).  I'm open for any 
other topic that people want to discuss.  If you want some time to present
soemthing that you want discussed let me know, so we can make sure that
everyone is accomodated.

Even if you're not going to be there, I'd like to here what topics you 
would like to have discussed.  I'll keep some notes, and post a summary
of the session to comp.windows.x.i386unix after I return from the
conference.

--
David Wexelblat <dwex@mtgzfs3.att.com>  (908) 957-5871
AT&T Bell Laboratories, 200 Laurel Ave - 3F-428, Middletown, NJ  07748

"The meaning of life?  That's simple.  Try to be happy, try not to hurt
 other people, and hope to fall in love."  -- Mallory Keaton
Newsgroups: comp.windows.x
From: garath@engin.umich.edu (Scott Grosch)
Subject: Drawables
Date: Mon, 04 Jan 93 17:39:11 EST
Organization: University of Michigan Engineering, Ann Arbor


Thanks to everyone who sent me information on a Drawable.

Newsgroups: comp.windows.x
From: todd@fred.dfrf.nasa.gov (Todd Vernon)
Subject: Re: Too Big XCreatePixmap returns ? (answers)
Reply-To: todd@fred.dfrf.nasa.gov (Todd Vernon)
Organization: Clarkson
Date: Thu, 7 Jan 1993 16:44:43 GMT

Thanks for the reply's to the question,

	>How do I trap for instance BadAlloc as would happen if I ask for
	>a pixmap that is too big ?  This seems like a common problem
	>since off screen memory in X Servers is often limited ?

The responces that I have received suggest that BadAlloc on pixmap creates
are server error events that I can receive a variety of ways using the
XSetErrorHandler routine.  I yield to these peoples experience, however I
did notice in ORielly VII p409 XSetErrorHandler the paragraph

	> The error handler is not called on ... BadAlloc, BadAccess errors.
	> These errors are all indicated by a 0 return value in the 
	> corresponding Xlib routines, and can be caught and handled by
        > by the application.

This seems to muddy the water a bit.  For information, here is responces
that I have received.  Thanks everyone for the suggestions, anyone elses
opionion is more then welcome.

todd@fred.dfrf.nasa.gov
----------------------------------------------------------------------

	The id's are generated on the client, so you will get a good id
	even when the server can't allocate it.  The error will get
	returned later.

	Here's how I get around it:
	-	XSync to process any pending errors
	-	save away the current error handler and set a new one
		that looks for badalloc.  this function should set
		a flag if badalloc happened.
	-	clear the error flag.
	-	create the pixmap
	-	do an XSync
	-	reset the error handler.
	-	check the error flag, and handle the error if so.
		


	Ugly, huh?  If you come up with better solutions, I'd like to
	hear them.


-brian
brian.warkentine@eng.sun.com
----------------------------------------------------------------------

Here's what to do.

1) Establish an Xlib error handler.

2) Do the XCreatePixmap call.  Assume it returns a valid
   Pixmap id. 

3) Do XGetGeometry on the Pixmap.  If allocation
   failed, you'll drop into the error handler.

4) Clear the error handler.

oj@roadrunner.pictel.com (Oliver Jones)

----------------------------------------------------------------------

Bad alloc is a Protocol Error and hence is send to you by the server. What you
shuold do is to install your own Event Handler function . If no one else tells
you how to do this email me and I will give you an short exemple.


fmhv@minerva.inesc.pt

----------------------------------------------------------------------
Newsgroups: comp.windows.x
From: humphrey@hightop.nrl.navy.mil (Jeff Humphrey [Jeffus])
Subject: Re: Help in using XDrawLine()
Organization: Computer Security, Naval Research Lab
Date: Tue, 12 Jan 1993 21:43:45 GMT

In article <Jan.12.15.49.54.1993.10085@caip.rutgers.edu> jayesh@caip.rutgers.edu (jayesh patel) writes:
[STUFF DELETED]
>  XSetForeground(display,gc,BlackPixel(display,screen));
>  XSetBackground(display,gc,WhitePixel(display,screen));

   XSelectInput (display,win,ExposureMask);

>  while(1)
>    {
>      XNextEvent(display,&event);
>      switch(event.type){
>      case Expose:
>	XDrawPoint(display,win,gc,10,10);
>	XDrawPoint(display,win,gc,20,20);
>	XDrawLine(display,win,gc,10,10,20,20);

  XFlush (display);

>        break;
[STUFF DELETED]

  That should fix it ...

-- 
 _     ___   ___ _   _ ____
| |   / _ \ / __| | | | ___| #include "standard.disclaimer"   <- IMHO
| |__| |_| | |__| |_| |___ | humphrey@hightop.nrl.navy.mil  (703)960-1000
|____|\___/ \___|\___/|____| @Naval Research Labs           (202)404-8241
Newsgroups: comp.windows.x
From: sjwright@cix.compulink.co.uk (Simon Wright)
Subject: Portrait Server
Cc: sjwright@cix.compulink.co.uk
Reply-To: sjwright@cix.compulink.co.uk
Date: Tue, 12 Jan 1993 21:35:00 +0000

X-Newsreader: TIN [version 1.1 PL6]

At present we supply some of our customers with portrait displays. We're
investigating the possibilities of using (relatively) commercially-
available hardware instead of the custom kit we use now.

A monitor manufacturer is prepared to supply us with a suitable monitor,
but he's not prepared to alter the electronics, so the scan lines will
now be vertical. [I can see that this would make life easier all round
in so far as the frame buffer won't have to change either].

However, we're now faced with modifying the server to cope with the new
scheme of things. I've had a quick look, and it seems to be a fairly major
port; and a lot of code in mfb (and cfb) is going to be inefficient if
scanlines don't map naturally onto bytes &c in the frame buffer.

Any experiences, words of wisdom (or warning!), or pointers to
implementations would be much appreciated.

--
Simon Wright
Ferranti International, Naval Systems
Newsgroups: comp.windows.x,comp.windows.x.intrinsics,comp.windows.x.motif
From: drand@spinner.osf.org (Douglas S. Rand)
Subject: Re: X/Xt/Motif Event Interleaving?
Followup-To: comp.windows.x,comp.windows.x.intrinsics,comp.windows.x.motif
Organization: Open Software Foundation
Date: 5 Jan 93 15:39:25

In article <1993Jan5.151408.3422@ods.com> chris@ods.com (Chris Atkins) writes:

   Buzz Moschetti (buzz@bear.com) wrote:
   : We are trying to create a very simple "drag-n-drop" type UI.  All widgets 
   : that can be dragged or dropped on will live in the same container widget
   : (xmFormWidgetClass).  Thus, we thought it would be possible to add event
   : handlers to all child widgets as follows:

   : 	XtAddEventHandler(widget,
   : 		EnterWindowMask | 
   : 		ButtonPressMask | ButtonReleaseMask | Button1MotionMask,
   : 		      FALSE, my_event_proc, client_data);

   : Assume we have two button widgets.  Clicking on and dragging either widget
   : correctly hits my_event_proc() with event->type set accordingly, likewise
   : for entering the widgets.

   : What we thought would happen is while, say, widget 1 was dragged over
   : widget 2, the latter's EnterNotify event would appear in the "stream" of
   : widget 1's MotionNotify events, e.g.

   : 	Dragging [w1]...
   : 	Dragging [w1]...
   : 	EnterNotify [w2]...
   : 	Dragging [w1]...

   : We do *not* see this behavior.  The problem is that widget 2 never gets
   : the EnterNotify event until *after* the button is released, which is
   : too late:

   A button press event sets up a passive grab.

Which does not apply to all events.  In particular,  enter and
leave events should be reported normally.  What might be more
important is what button was pressed.  In Motif,  button2 is 
setup to do drag and drop and more interesting grabs result.



--
Douglas S. Rand <drand@osf.org>		OSF/Motif Dev.
Snail:         11 Cambridge Center,  Cambridge,  MA  02142
Disclaimer:    I don't know if OSF agrees with me... let's vote on it.
Amateur Radio: KC1KJ
Newsgroups: comp.windows.x
From: fleming@wright.enet.dec.com (John Fleming)
Subject: Delete Xrm resource?
Organization: Digital Equipment Corporation
Date: Mon, 11 Jan 1993 14:31:35 GMT

Is there a way to delete a resource from the resource database?
I am saving application specific resources in my Xrm database using
XrmPutLineResource but I also need to occasionally delete resources.
There doesn't seem to be a corresponding XrmRemoveLineResource.
Thanks in advance,
John Fleming
From: lecom@slhp1.epfl.ch (Claude Lecommandeur)
Newsgroups: comp.windows.x
Subject: Re: Deleting Mouse Selected text in "xedit"
Date: 11 Jan 93 15:32:37 GMT
Organization: Ecole Polytechnique Federale de Lausanne

In article <1iruvrINNnnk@shelley.u.washington.edu>, zzz@byron.u.washington.edu (Sample) writes:
|> Could someone email me here (zzz@byron.u.washington.edu)
|> and tell me of an easier why to delete mouse
|> selected text in "/usr/bin/X11/xedit".  I know that
|> the '^W' key works but there should be a quicker
|> way (like a signle key press (no control press) or
|> adding a delete to the "Quit", "Save" and "Load"
|> menues.
|> 
|> Jeff

   The quickest thing you can imagine is to have :

xedit*editWindow.translations:  #override \n\
   <Btn1Up>: extend-end(PRIMARY, CUT_BUFFER0) kill-selection()

   When you release button1, the text gets automatically deleted. A more
reasonable solution is :

xedit*editWindow.translations:  #override \n\
   Shift<Btn1Up>: extend-end(PRIMARY, CUT_BUFFER0) kill-selection()

   This the setting i use. If i want to delete a text, i press shift before
releasing button1.


-- 


                    Claude Lecommandeur
                    Service Informatique Central
                    Ecole Polytechnique Federale de Lausanne
                    1015 LAUSANNE (SWITZERLAND)
                    E-Mail : lecom@sic.epfl.ch
                    Tel : (41 21) 693-22-97
From: opus@hydra.unm.edu (Colby Kraybill)
Newsgroups: comp.windows.x
Subject: Possible bug with XtCreateWidget()?
Date: 12 Jan 1993 10:21:16 GMT
Organization: University of New Mexico, Albuquerque
Distribution: world
Reply-To: opus@astro.unm.edu
NNTP-Posting-Host: hydra.unm.edu
Keywords: Xt, XtCreateWidget, bug


I have been trying to get an application going which works under the
khoros signal/image processing software.  I've pretty much eleminated
the possibility that the error is in the khoros stuff.

Anyways, there is a library routine under khoros which makes a call to
XtCreateManagedWidget().  I traced through the source code of that call
and then came upon XtCreateWidget().  The error is this :

signal BUS (alignment error) in Get_GC at 0x60ecc
Get_GC+0x14:    ld      [%o0 + 4], %o0

I've yet to find 'Get_GC' in my X11R5 sources, but I am still looking.
However, instead of having to recompile some of those sources with a -g
option.  I'd like to find out if anyone out there has encountered something
like this and has some sortof fix, or atleast a reason why this is happening.

The values which are being passed to XtCreateWidget are fine, they are :

widget = XtCreateWidget(name, widget_class, parent, args, num_args);

name : "Glyph"
widget_class is commandWidgetClass
parent is a valid 'toplevel' window
args has all nine values which num_args says there should be.

Ideas?


--
Colby Kraybill
Department of Physics and Astronomy - Computer Geek Extrodenaire
opus@astro.unm.edu


-- 
Colby Kraybill
Department of Physics and Astronomy - Computer Geek Extrodenaire
opus@astro.unm.edu
Newsgroups: comp.windows.x
From: brianc@Aus.Sun.COM (Brian Cunningham)
Subject: linker errors under OpenWindows
Organization: The Internet
Date: Wed, 6 Jan 1993 16:02:04 GMT


> 
> I am using a SUN SPARC STATION IPX with SunOS Release 4.1.3 (GENERIC_SMALL) #).
> It seems that the X-window Athena widget kit is having some problem with this 
> platform. Simple try to compile the famous HelloWorld program xhw3 yield the 
> following:
> 
> % make -f makefile xhw3
> cc -o xhw3  xhw3.o -O  -lXaw -lXmu -lXt -lX11 -lm   
> ld: Undefined symbol
>    _XShapeQueryExtension
>    _XShapeCombineMask
>    _get_wmShellWidgetClass
>    _get_applicationShellWidgetClass
> *** Error code 2
> make: Fatal error: Command failed for target `xhw3'
> 
> Actually, the executable code of xhw3 was generated and runnable. But what the 
> above errors are telling us. an identical compile session running on IPC or ELC
> do not have problem at all. Anyone has experience with this problem? What 
> I should do about it? Any suggestion/comments will be appreciated. E-mail
> to zhang@buast7.bu.edu is preferred.
> 
> Following the suggestion on this newsgroup on a similar thread, I tried to 
> use -Bstatic option for the linker, it gave even more undefined symbols:-(
> 
> A quick look at th include/X11 area found that the content/directory-structure
> are different b/w SUN IPX and SUN ELC
> 
> Yun Fei Zhang
> ===============
> 
> for your information, a ls command in /usr/openwin/lib gives the following
> 
> % ls libX*
> libX.sa.1.0@    libX11.so@      libXmu.sa@      libXol.so@      libXt.so@
> libX.so.1.0@    libX11.so.4.3   libXmu.sa.4.0   libXol.so.3.1   libXt.so.4.1
> libX11.sa@      libXaw.so@      libXmu.so@      libXt.sa@
> libX11.sa.4.3   libXaw.so.4.0   libXmu.so.4.0   libXt.sa.4.1
> 
>

I have the Same problem Yun. I am running SunOS 4.1.3, OW 3.0. All fully 
installed and always find that the following two errors occur when compiling
most X programs;

   _get_wmShellWidgetClass
   _get_applicationShellWidgetClass

I too tried the -Bstatic compile option, to no effect. Does anyone out there
have a solution?

Thanks in advance,

	Brian Cunningham ...

---
Sun Microsystems Australia. Systems Administrator.
Newsgroups: comp.windows.x
From: blain@blmc45.QE.Bell.CA (Stephane Blain)
Subject: Re: Positioning xdm-login window
Reply-To: stblain@stam.qe.bell.ca
Organization: CARC -- Bell Canada
Distribution: na
Date: Tue, 12 Jan 1993 15:31:19 GMT

In article <2657@eagle.ukc.ac.uk>, rlh@ukc.ac.uk (R.L.Hesketh) writes:
> 
> I think Stephane wants to set the login window put up by xdm before
> any session is started.  I suspect that the xdm in OpenWindows 3.0
> is derived from the R4 version of the MIT xdm, which overrides any
> settings for x and y with the code ...
> 
>     x = (WidthOfScreen (XtScreen (w)) - w->core.width) / 2;
>     y = (HeightOfScreen (XtScreen (w)) - w->core.height) / 3;
> 
> However in R5 the code is ...
> 
>     if ((x = w->core.x) == -1)
>         x = (int)(WidthOfScreen (XtScreen (w)) - w->core.width) / 2;
>     if ((y = w->core.y) == -1)
>         y = (int)(HeightOfScreen (XtScreen (w)) - w->core.height) / 3;
> 
> and x and y are set to -1 by default.  So the solution would be
> to use xdm from the R5 source (I for one would be interested to hear what
> happens if you try this).
> 
> Richard

Richard,

it's exactly my problem.  Before your mail, I have talked to the Sun people,
and they told me that was a proplem of the xdm from MIT X11R4.  I have
modified the xdm code myself (exactly the same lines that you told)
and it work well.  But now then I know that was corrected in the X11R5,
I will use the xdm from X11R5.

P.S.: Excuse my english, I'm not biligual...

--------------------------------------------------------------
Stephane BLAIN ing. jr      | E-mail : stblain@stam.qe.bell.ca
			    | Tel    : (514) 870-2638
			    | Fax    : (514) 391-3146
			    | Pagette: (514) 339-3379
Newsgroups: comp.windows.x