HDTenEightyP/NetNews huggingface dataset:
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.windows.x.i386unix,comp.windows.x
Subject: Re: NeXT programs
Date: 22 Dec 92 19:09:13 GMT
Followup-To: comp.windows.x
Organization: McGill Research Centre for Intelligent Machines

In article <1992Dec18.180846.27819@gossip.urich.edu>, 2ec0@aurora.urich (Cheese) writes:

> I am wondering if there is a program that allows a NeXT computer to
> pop-up and run x-window programs.  If so where can I find this
> program.

This does not belong on c.w.x.i386unix, since a NeXT has nothing
whatever to do with i386s (and less than one might wish to do with
UNIX).  So I'm crossposting to comp.windows.x and setting followups
there.

Yes, X servers for the NeXT exist.  I know of three.  In chronological
order:

- An R3 port, that presents a 1-bit StaticGray visual to clients (a
  traditional "monochrome" display).  The X root appears in a NextStep
  window.  It is available free, but binary-only because, I am told, it
  uses a proprietary library of some sort.  From what little I know of
  it, it should run on any NeXT display of any sort.  I don't know
  where to get it, except that I think it's from MIT somewhere.

- An R4 port, done by yours truly.  It takes over the screen, the way X
  servers for most other machines do.  It also tells clients the truth,
  in that it presents a 2-bit StaticGray visual.  It has some problems,
  but is perhaps not unusable.  (Someday I'll get around to porting a
  more recent release....)  It is available free; the smaller pieces of
  it (like patches to Xlib and Xt) are public domain, while the most
  involved work - the NeXT-specific stuff, in particular - has a
  copyright like the one used by the MIT distribution.  This runs on
  the 2-bit MegaPixel display and nothing else.  (I have heard of
  people working on ports to color machines, but haven't seen anything
  concrete.)  It can be obtained by anonymous ftp from
  larry.mcrcim.mcgill.edu (132.206.1.1) in /X/XNeXT.

- A company called PenCom (Pencom? PenComm?) sells a commercial server.
  I know little about it, but I believe it does everything inside
  NextStep windows.  I'm sure the company would be pleased to answer
  any queries you may have about it.  I don't know whether they have a
  mail alias like info@pencom.com or help@pencom.com or some such;
  their whois information is:

	Pencom Systems, Inc. (PENCOM-DOM)
	   9050 Capital of Texas Highway N
	   Suite 300
	   Austin, TX 79759
	
	   Domain Name: PENCOM.COM
	
	   Administrative Contact, Technical Contact, Zone Contact:
	      Bryant, David  (DB63)  dbryant@pencom.com
	      (512) 343-1111
	
	   Record last updated on 02-Oct-91.
  [rest deleted as irrelevant here]

There may well be other companies selling X servers for the NeXT, but I
know of none.

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu
Newsgroups: comp.windows.x.i386unix
From: jason@oaknet.chi.il.us (Jason Vanick)
Subject: Xfree on AT&T Sys V r 3.2.1
Organization: OAKNET - Public Access Unix
Date: Mon, 21 Dec 1992 13:47:08 GMT

I am currently running X11R4 (X386 1.?) and would like to run Xfree,
I have about 70 megs to compile the beast in and I would like to know
if either anybody has gotten it to compile, and could send me your
binaries, or if it would be possible to compile it in that 70 meg partition?
I am running stock AT&T System V release 3.2.1 on a 386 with 8 megs of ram.
I do not have any tcp/ip, just the AT&T RFS garbage...
If you can help me, please email me.
- Jason
-- 
--------------------------------------------------------------------
Jason Vanick               | Operator of Oaknet - public access unix
jason@oaknet.chi.il.us     | +1-708-425-8739     300->14.4k baud N81 
--------------------------------------------------------------------
Newsgroups: comp.windows.x.i386unix
From: roell@informatik.tu-muenchen.de (Thomas Roell)
Subject: Re: 32K or 16M colours?
	<1992Dec22.130619.18414@news.lrz-muenchen.de>
	<1992Dec23.171933.11736@thunder.mcrcim.mcgill.edu>
Organization: Inst. fuer Informatik, Technische Univ. Muenchen, Germany
Date: Thu, 24 Dec 1992 11:58:11 GMT

>>> Take a look at how the 24-bit SVGA's are implemented.  Packed 3-byte
>>> pixels.  It's going to make working on them rediculous[sic].
>> I don't think 3byte pixels is that rediculus[sic] if you look at the
>> memory contraints given in todays SVGAs.  But the price to pay is
>> VERY high.  You can only deal with 24bpp (opposed to 32bpp) by using
>> 32bit reads/writes.  A simple statistic shows that about every second
>> access will be not correctly aligned and hence at least 2 32bit
>> accesses to video memroy will be necessary.  Having this in mind a
>> 24bpp framebuffer will be at leat 1.5 times slower than a 32bpp.
>
>Only if the implementation is careless.  You should be doing three
>32-bit memory accesses for every four pixels.  Only if you're doing
>something narrow (ie, small span along the x axis) will the
>misalignment effect make much difference.  Granted, drawing lines is a
>common operation, but I believe area copies and text drawing are much
>more important for nearly all applications.

Hmmm .... very intresting. I tried it doing it the 'careless' way. Anyway,
I have some perhaps strong arguments again doing your approach (at leat
some thoughts that might make this approach not a good as it seems to be
at first, but nevertheless faster than the dumb brute force approach):

1) Much of the speed of cfb comes from the fact that basically all unary
   operations (everything except CopyArea and CopyPlane) are reduced to:

        (((dst) & (and)) ^ (xor))

   and & xor are precumputed constants (with optimisations if xor == 0 or
   and == PMSK). If you would used units of 96bits (for four pixels) you
   had to use 6 constants instead of 2, which might break the register
   allocation of your compiler.

2) The way cfb handles ragged edges would have to be changed to make
   as few accesses as possible, instead of reading one pixel unit (32bit 
   for cfb) and simply handle the complete group. Instead you hand to make
   special case for 3,2,1 pixels which are unaligned.

3) Cases for CopyArea where source and destination will not have the 
   same alignment regarding the 96bit units will have to be handled in
   a complex shifting code. For 32bit units you have enought registers on
   a 386, but with 96bit units, you have to store temporay results and
   hence will be slower than using unaligned accesses.


But after all this way seems to be faster than even 32bpp. One would
have to try it out. But on the other hand I feel like the speed will be still
to slow for real usage. And then most people will get accelerated graphics
boards, which do support TrueColor but again only in 32bpp ...

- Thomas
--
-------------------------------------------------------------------------------
Das Reh springt hoch, 				e-mail: roell@sgcs.com
das Reh springt weit,				#include <sys/pizza.h>
was soll es tun, es hat ja Zeit ...
Newsgroups: comp.windows.x.i386unix
From: jtsilla@damon.ccs.northeastern.edu (James Tsillas)
Subject: Re: X386 on Hercules and X386 bugs and suggestions
Organization: Northeastern University, Boston, MA
	<1992Dec21.052259.24129@athena.mit.edu>
	<1992Dec21.132332.11450@cbnewsj.cb.att.com>
	<1992Dec21.175647.9279@athena.mit.edu>
Date: Mon, 21 Dec 1992 19:30:09 GMT


This is one of the worst layer violations X11 has. There's no solution
but to install multiple sets of bitmaps. Perhaps something has been done
with the fonts to allow dynamic conversion to snf (?).

I am interested in working on this as well as the interlacing problem
mentioned in an earlier posting. I'd like to get the mfb running on
interlaced and banked cards. If anyone else is interested in working on
this send me e-mail. We'll form a mailing list and try to divide the
tasks. I'd appreciate it if only people with serious interest (and
resources to match) contact me.

regards,
-Jim.
--
	***  James Tsillas  jtsilla@damon.ccs.northeastern.edu   ***
	***      Work: (508)898-2800, Home: (617)641-0513        ***
	***        "He is after me. Jim is after him."           ***
	***            - Hop on Pop, Dr. Seuss                   ***
From: paul@pphbau.atr.bso.nl (PPH Bauwens)
Newsgroups: comp.windows.x.i386unix
Subject: Alt-F kills XFree 1.1 server
Date: 30 Dec 92 08:26:57 GMT
Organization: Private Node
X-Newsreader: TIN [version 1.1 PL7]

Dear XFree86 users,

Last week I decided to re-build my X environment to the latest XFree86 
version. Starting from MIT X11R5 PL0 I sucessfully applied all
subsequent patches to arrive at X11R5 PL17 + XFree86.
I am impressed by the level of configuration control at MIT and the XFree86
developers! No patch rejects!
Many thanks to the MIT people and the XFree86 developers!

After succesfully configuring and building the new X environment everything
seemed to work OK, until I noticed yesterday that typing ALT-F in any
window or root kills the server immediately.
I am using ESIX 4.0.4 SVR4 and the native 'cc' compiler.
My original X server (X386 1.2 + speedup patches) didn't show this problem.

Has anyone encountered this problem before? It would save me a lot of
debugging...

A happy New Year!
-- 
--------------------------------------------------------------------------
Paul Bauwens				Email:	paul@pphbau.atr.bso.nl
Rietkerkweg 364					paul@pphbau.hobby.nl
3066VL Rotterdam  Nederland		Phone:	+31-10-4211858
Newsgroups: comp.windows.x.i386unix
From: dawes@physics.su.OZ.AU (David Dawes)
Subject: Re: Alt-F kills XFree 1.1 server
Organization: School of Physics, University of Sydney, Australia
Date: Thu, 31 Dec 1992 02:43:43 GMT

In article <1992Dec30.082657.337@pphbau.atr.bso.nl> paul@pphbau.atr.bso.nl (PPH Bauwens) writes:
>Dear XFree86 users,
>
>Last week I decided to re-build my X environment to the latest XFree86 
>version. Starting from MIT X11R5 PL0 I sucessfully applied all
>subsequent patches to arrive at X11R5 PL17 + XFree86.
>I am impressed by the level of configuration control at MIT and the XFree86
>developers! No patch rejects!
>Many thanks to the MIT people and the XFree86 developers!
>
>After succesfully configuring and building the new X environment everything
>seemed to work OK, until I noticed yesterday that typing ALT-F in any
>window or root kills the server immediately.
>I am using ESIX 4.0.4 SVR4 and the native 'cc' compiler.
>My original X server (X386 1.2 + speedup patches) didn't show this problem.
>
>Has anyone encountered this problem before? It would save me a lot of
>debugging...

Alt-F is intercepted by the VT manager, and means a forced VT switch.
Being a forced switch, it doesn't wait for the X server to release the
VT -- and this causes the server to crash.  On Esix there are two ways
to disable the 2-key VT sequences (and allow only the 3-key versions).
The first way is to change the value of kd_2keysw  to 0 in
/etc/conf/pack.d/kd/space.c and rebuild the kernel.  The second way
(which I use) is to run a program that makes use of the KDDIS2KEYSW
ioctl.  This (and KDENA2KEYSW) can be used to enable/disable 2-key VT
switching on a per-VT basis.  If you take the later approach, the
program must be run after the server starts.  The next release of
XFree86 will have an Xconfig option to allow such a program to be run
automatically at startup.  Other versions of SVR4 handle this differently.

David
--
------------------------------------------------------------------------------
 David Dawes <dawes@physics.su.oz.au>    DoD#210      | Phone: +61 2 692 2639
 School of Physics, University of Sydney, Australia   | Fax:   +61 2 660 2903
------------------------------------------------------------------------------
 I was so satisfied, deep down inside, like a hand in a velvet glove -- AC/DC
------------------------------------------------------------------------------
From: hedrick@geneva.rutgers.edu (Charles Hedrick)
Newsgroups: comp.windows.x.i386unix
Subject: Re: Getting 1152x900 with Orchid ProIIs
Date: 2 Jan 93 21:48:34 GMT
Organization: Rutgers Univ., New Brunswick, N.J.

In comp.windows.x.i386unix you write:

>Try the 65-MHz dot clock to get about a 65-Hz refresh rate; my ET4000 book
>says that's the upper limit--you may or may not have a chip that exceeds
>this spec.  I can't see any flicker even at 60 Hz in 1024x768 (with some
>tweaking of the sync and blank intervals) on a 14" Sampo AlphaScan+, and
>I'm very picky.

I've run at 80MHz on two different Orchid ProIIs's, and on a Cardinal
700, resulting in 81Hz refresh.  This is with a NEC Multisync 5FG.
All are ET4000's.  Maybe they've sped them up?
From: tjrc1@cus.cam.ac.uk (T.J.R. Cutts)
Newsgroups: comp.windows.x.i386unix
Subject: Re: Third button on a 2-button mouse
Date: 21 Dec 92 18:02:36 GMT
Organization: U of Cambridge, England

In your Xconfig file, add the line 'Emulate3Buttons'.  Then clicking both
buttons on your microsoft mouse simultaneously will generate a button 2 click.
-- 
-- Tim Cutts                             /~\     ----
                                        (   )  /     \
Sugarmice on a skateboard               /   \/        \
                                      /  O             \
From: sscalsk@nswc-wo.? (Stanley Scalsky)
Newsgroups: comp.windows.x.i386unix
Subject: interlace info please
Date: 29 Dec 92 19:27:50 GMT
Distribution: comp
Organization: NSWC White Oak

Would someone please explain this little quirk?

I have a ViewSonic 4 capable for 1024x768 interlace and have Xfree 1.1 under
linux .99 currently supporting it but every now and then I notice that
when a window is placed just right all the horizontal lines that are 1 scan
line thick are not visable. The X maze utility shows this pretty well
because of its mix of vertical and horizontal lines. Is this a product
of the monitor, an Xfree misconfiguration or the result of using interlace
mode? Any info is appreciated.

-= stan     sscalsk@nswc-wo.navy.mil
From: ail8070@tamuts.tamu.edu (Andy I. Liaw)
Newsgroups: comp.windows.x.i386unix
Subject: [Q]: How do I change xterm font?
Date: 28 Dec 1992 07:19:05 GMT
Organization: ~/lib/organization
NNTP-Posting-Host: tamuts.tamu.edu

Just a simple question: how do I specify a larger font for xterm?
I'm running Xfree86 1.1 under linux in 800x600, and the default fonts
are a bit too small on my 14" monitor.

Also, for those of you that use olwm: if I click too fast on the
scroll-bar, the system would hang.  I still get the virtual screen,
but nothing else works.  Is this a bug or there's something wrong
with my system?

andy
aliaw@stat.tamu.edu

Newsgroups: comp.windows.x.i386unix
From: rich@Rice.edu (& Murphey)
Subject: Re: XConfig Settings for NEC 4FG 1024x768 & SS + HiColor wanted
Reply-To: Rich@rice.edu
Organization: Department of Electrical and Computer Engineering, Rice
	University
Date: Thu, 24 Dec 1992 07:18:31 GMT

>>>>> In article <933@unidoct.chemietechnik.uni-dortmund.de>, sn@plato.chemietechnik.uni-dortmund.de (sn) writes:
sn> Hello everyone,
sn> I am running 386BSD-0.1 with Xfree86 and I'm experiencing problems
sn> with my VGA-Card/Monitor combination.
sn> In the beginning, everything went fine with the default VESA
sn> settings of the XConfig file.
sn> Suddenly, xdm detected other clockrates on my SpeedStar Plus (4.23) HiColor.
sn> Since then, I had to adjust my XConfig file numerous times to
sn> take care of the new clock rates xdm detected (e.g. 75 changed to 76, etc)

The system load can affect the timing measurements.  This is fixed in
the next release by raising the priority during the mesurement of the
clocks.  Till then, your best measurement can be made on a quiescent
system.  Once the server reports clock values that work for you, hard
code them in your Xconfig.  This has the added benfit of saving some
startup time.

sn> However, I'm now having problems using the following 1024x768 modes
sn> on my NEC 4FG:
sn> # name        clock   horizontal timing     vertical timing      flags
sn>   "1024x768"    75     1024 1048 1184 1328    768  771  777  806
sn> This is the same I have been using at the beginning and it used to work
sn> fine. Now, however, I am experiencing an pretty much unusable picture.

Make sure that the clock values have not changed enough to force the
server to match 1024x768 to the timings for another clock rate.

sn> Did I damage my monitor? Does anyone have better settings for the NEC 4FG?
sn> What are the best/correct Clocks for the SpeedStar Plus Hicolor?
sn> Do I get more flicker if I use a lower clock?

well, it depends on your timing values which in turn determine the
refresh rate.  If the lower clock forces you to use a lower refresh
rate, then yes.  Good luck!  Rich

Newsgroups: comp.windows.x.i386unix
From: danubius@halcyon.com (Joseph R. Pannon)
Subject: SpeedStar+ and CristalScan Xconfig
Organization: Northwest Nexus Inc. (206) 455-3505
Date: Wed, 30 Dec 1992 09:42:54 GMT

I have a year-old Gateway 2000 486/33C tower with SpeedStar Plus video
card (BIOS version 4.23) and the CrystalScan 1024 NI monitor.  I figure
there must be a ton of these systems out there and s few of you have
already figured out the right Xconfig parameters for it.  I have no luck
with it so far.  

Will one of you have mercy and share his Xconfig with poor me?
In exchange I'll say a prayer for you if that Xconfig works for me. ;-)
I'll can fix the mouse stuff in it.  My linux is built from the 0.99 SLS
package I ftp-d from tsx-11.mit.edu. 

Thanks already,
Joe Pannon
Newsgroups: comp.windows.x.i386unix
From: adelt@imada.ou.dk (Adel Shavandi)
Subject: Problems running XView applications, please help!
Summary: Problems running XView applications, please help!
Keywords: Problems running XView applications, please help!
Organization: Dept. of Math. & Computer Science, Odense University, Denmark
Date: Sun, 3 Jan 1993 14:04:33 GMT


I am a linux user with XFree86 version 1.1 and XView version 3.0L2. I have 
written a very simple XView application which runs with no problems under
SUN-OS4 with XView3.0 and now I would like to port it to linux.  
 
After having done all work required for compiling and linking a Xview 
application, when I tried to start it from my xterm window, the program 
did nothing! Then I tried to run it from xxgdb version 4.6 and the program 
runs without no problems, but after the following message appears in the
window of xxgdb: 
 
        [ioctl TIOCSPGRP failed in terminal-inferior: Not a typewriter] 
 
What is this message supposed to mean, and how can I correct this problem? 
I guess this is why I can't run my application without xxgdb. Is it true? 
 
 
I will really appraciate any kind of hints/help. 
 
 
 
 
                        Thanks in advance and 
                                happy new year, 
 
                                        Ade'l 
Newsgroups: comp.windows.x.i386unix
From: ujlh@pool.info.sunyit.edu (James Henrickson)
Subject: X8514 problem
Organization: State University of New York -- Institute of Technology
Date: Wed, 23 Dec 1992 02:04:04 GMT

Hi all,

I am trying to get X8514 working under 386BSD.  The computer has an ATI
Ultra video card and a NEC MultiSync 4FG monitor.  I got past several
Xconfig problems, but now I'm stuck.  I get the following message:

Fatal server error:
Attached monitor not capable of displaying 8514!

Ouch.  Does this mean I can only use this video card if the monitor
is 8514 compatible?  Would I have the same problem with the Linux
8514 server?

Thanks for any and all replies.

-- 
Jim H.
*
* James L. Henrickson  |  "I don't need a signature, I need a job!"
* ujlh@sunyit.edu      |  BSCS, December 1992
Newsgroups: comp.windows.x.i386unix
From: dawes@physics.su.OZ.AU (David Dawes)
Subject: Re: X386 on Hercules and X386 bugs and suggestions
Organization: School of Physics, University of Sydney, Australia
Date: Wed, 23 Dec 1992 03:40:00 GMT

In article <1992Dec21.175647.9279@athena.mit.edu> dmatic@athena.mit.edu (Davor Matic) writes:
>
>
>I have a question about IMAGE_BYTE_ODER and BITMAP_BIT_ORDER.
>
>i386/486 machines use IMAGE_BYTE_ORDER as LSBFirst.  Now, I noticed
>that BITMAP_BIT_ORDER is defined to be LSBFirst as well for SYSV386.
>BITMAP_BIT_ORDER should be device dependant, right?  So are VGA's
>really LSBFirst or is this not relevant if one is using only the
>vga256 driver?  mfb certailny works faster with both BIT and BYTE 
>order the same way.

It's matters for the mono vga driver where BITMAP_BIT_ORDER is MSBFirst.

>What happens if one wants to use two devices which use different 
>BITMAP_BIT_ORDER in the same server?  Is this possible at all?

Not sure -- that's why XFree86 has a separate binary for the colour and
mono servers.  I've never tried setting BITMAP_BIT_ORDER to MSBFirst in
the vga256 server (off-hand I can't think why it wouldn't work).  We've
found that if IMAGE_BYTE_ORDER != BITMAP_BIT_ORDER,
BITMAP_SCANLINE_UNIT needs to be set to 8 instead of the usual 32.

>Hercules card is MSBFirst for BITMAP_BIT_ORDER.  What is the correct
>order for VGA boards?  Can I use both in the same server?
>
>Where can I find XFree86 source code, but not as patches, please?

It is only available as patches to the MIT X11R5 source.  The patches
are on export.lcs.mit.edu in contrib/XFree86.

David
--
------------------------------------------------------------------------------
 David Dawes (dawes@physics.su.oz.au)    DoD#210      | Phone: +61 2 692 2639
 School of Physics, University of Sydney, Australia   | Fax:   +61 2 660 2903
------------------------------------------------------------------------------
From: whuang1@husc10.harvard.edu (Weidong Huang)
Newsgroups: comp.windows.x.i386unix
Subject: Sun i386/150/250 for sale
Date: 24 Dec 92 06:20:30 GMT
Article-I.D.: husc3.1992Dec24.012031.18814
Distribution: usa
Organization: Harvard University Science Center

I have some Sun i386/150/250 for sale. give me an offer.
From: bkuhn@rhlab.UUCP (bmk Bradley Kuhn)
Newsgroups: comp.windows.x.i386unix
Subject: gwm compile under Linux .99pl17, wool.lex problems
Keywords: gwm, linux, X386, X11
Date: 31 Dec 92 13:59:09 GMT
Organization: Baltimore Rh Laboratory, Inc., Maryland

I downloaded gwm from tsx-11.mit.edu's linux directories, but I couldn't
get it to compile properly. xmkmf worked ok, but make Makefiles died 
because imake couldn't find a file, and wool.lex had lots of errors when
gcc tried to compile yy.tab.c.  If it were C code, I would attempt to fix
it myself, but I don't know anything about lex and yacc.  Is there a 
gwm binary around for Linux .99pl17?  Or can someone tell me what to do
to fix the errors in wool.lex?

Thanks.


-- 

 -- Bradley M. Kuhn    Computer Systems Development, Inc.
     INTERNET: rhlab!bkuhn@uunet.uu.net OR bkuhn@loyola.edu
     UUCP:     ...uunet!rhlab!bkuhn
Newsgroups: comp.windows.x.i386unix
From: adelt@imada.ou.dk (Adel Shavandi)
Subject: Problem running XView application, please help!
Summary: Problems running XView applications!`
Keywords: Problems running XView application!
Organization: Dept. of Math. & Computer Science, Odense University, Denmark
Date: Sun, 3 Jan 1993 14:00:47 GMT



I am a linux user with XFree86 version 1.1 and XView version 3.0L2. I have 
written a very simple XView application which runs with no problems under
SUN-OS4 with XView3.0 and now I would like to port it to linux.

After having done all work required for compiling and linking a Xview
application, when I tried to start it from my xterm window, the program
did nothing! Then I tried to run it from xxgdb version 4.6 and the program
runs without no problems, but after the following message appears in the
window of xxgdb:

	[ioctl TIOCSPGRP failed in terminal-inferior: Not a typewriter]

What is this message supposed to mean, and how can I correct this problem?
I guess this is why I can't run my application without xxgdb. Is it true?


I will really appraciate any kind of hints/help.




			Thanks in advance and
				happy new year,

					Ade'l
From: aoki@risk.stanford.edu (ikuro aoki)
Newsgroups: comp.windows.x.i386unix
Subject: Re: XS3 ?
Date: 21 Dec 92 15:56:31
Organization: Stanford University, Stanford, CA, USA.
Distribution: usa
	<ljc1ooINNggd@paducah.cs.utexas.edu>
	<1992Dec21.192129.29264@netcom.com>
NNTP-Posting-Host: risk.stanford.edu
In-reply-to: kehcheng@netcom.com's message of Mon, 21 Dec 1992 19:21:29 GMT

The Actix's number is (408)986-1625.
Newsgroups: comp.windows.x.i386unix