Tech Insider					     Technology and Trends


		   Linux Activists Mailing List Archives

From: pmacdona@sanjuan (Peter MacDonald)
Subject: X, ET4000 and mice
Date: 9 May 92 22:23:27 GMT


Contrary to popular belief, having an ET4000 doesn't automatically
let you run X386.  I have seen reports of some ET4000 cards that just
don't work.

Myself, I set up X under DELL UNIX at work using an ET4000 Ammazing card:
no problem.  Now I am trying it at home with an ET4000 vga2max card with Linix.
Using the default "640x480" mode, it gives me four images on the screen, 
complete with four pointers, four xterms, etc.  I have mucked around for 4-5 
hours trying different monitor settings, but no joy.  It seems that Clock must
be wrong (half?) or something.  I also found a 800x600 mode that gives me
6 windows!  The card seems to have something called Hicolor mode (32K colors 
I think).

Also, I have one of those switchable mouse (ACE).  The logitech setting
works not at all, while with the MS setting, the buttons work but the mouse
movement doesn't.   Using another alternate mouse, a logitech only (2button)
causes eratic movement.

Fortunately, I am just borrowing this equipment from work, so am not
saddled with it.  But, the moral is:  If you think just getting an
ET4000 card will let you run X with no problems, maybe.
Configuring the monitor section alone can be very tough.  Anyone know
why you can install a VGA card under DOS, and it can display just fine
without knowing anything about the monitor?   The card just uses various
Video Clock, Horz Sync, and Vert Sync combos.  If the monitor doesn't 
support it, you get the "Outer Limits" on screen. 

But not X386.  I like flexibility, but  I think maybe a more usable 
configuration would be one that just lets you supply the Clock/VSync/HSync,
and it would try some intelligent monitor timings.  Actually, have tried
going through the video tutorial by Chin Fang.  Even tried developing
a spreadsheet under oleo to do the calculations.  But the real solution
is to use C code, and then incorporate it into a server as a configuration
option. 

From: obz@sisd.kodak.com (Orest Zborowski COMP)
Subject: Re: X, ET4000 and mice
Date: 10 May 92 06:21:17 GMT

pmacdona@sanjuan (Peter MacDonald) writes:
>
>Contrary to popular belief, having an ET4000 doesn't automatically
>let you run X386.  I have seen reports of some ET4000 cards that just
>don't work.
>
>Myself, I set up X under DELL UNIX at work using an ET4000 Ammazing card:
>no problem.  Now I am trying it at home with an ET4000 vga2max card with Linix.
>Using the default "640x480" mode, it gives me four images on the screen, 
>complete with four pointers, four xterms, etc.  I have mucked around for 4-5 
>hours trying different monitor settings, but no joy.  It seems that Clock must
>be wrong (half?) or something.  I also found a 800x600 mode that gives me
>6 windows!  The card seems to have something called Hicolor mode (32K colors 
>I think).

ah! but i already thought of this! one of the few nonstandard patches i
have applied to the server is the hiclock patch (which was discussed in
comp.unix.sysv386).  if you find your clock halues are high, try adding
the line
        vendor "hiclock"
in the vga256 section. i'd be interested to know if this works.

>
>Also, I have one of those switchable mouse (ACE).  The logitech setting
>works not at all, while with the MS setting, the buttons work but the mouse
>movement doesn't.   Using another alternate mouse, a logitech only (2button)
>causes eratic movement.
>
>Fortunately, I am just borrowing this equipment from work, so am not
>saddled with it.  But, the moral is:  If you think just getting an
>ET4000 card will let you run X with no problems, maybe.
>Configuring the monitor section alone can be very tough.  Anyone know
>why you can install a VGA card under DOS, and it can display just fine
>without knowing anything about the monitor?   The card just uses various
>Video Clock, Horz Sync, and Vert Sync combos.  If the monitor doesn't 
>support it, you get the "Outer Limits" on screen. 
>
>But not X386.  I like flexibility, but  I think maybe a more usable 
>configuration would be one that just lets you supply the Clock/VSync/HSync,
>and it would try some intelligent monitor timings.  Actually, have tried
>going through the video tutorial by Chin Fang.  Even tried developing
>a spreadsheet under oleo to do the calculations.  But the real solution
>is to use C code, and then incorporate it into a server as a configuration
>option. 

what a great idea! let me know when you're done! :-)

zorst
[obz@sisd.kodak.com]
-- 
zorst (orest zborowski)
[reply to obz@sisd.kodak.com]

From: hlu@yoda.eecs.wsu.edu (H.J. Lu)
Subject: Re: X, ET4000 and mice
Date: 10 May 92 07:40:07 GMT

In article <1992May10.062117.5370@sisd.kodak.com> 
obz@sisd.kodak.com (Orest Zborowski COMP) writes:
>pmacdona@sanjuan (Peter MacDonald) writes:
>>
>>But not X386.  I like flexibility, but  I think maybe a more usable 
>>configuration would be one that just lets you supply the Clock/VSync/HSync,
>>and it would try some intelligent monitor timings.  Actually, have tried
>>going through the video tutorial by Chin Fang.  Even tried developing
>>a spreadsheet under oleo to do the calculations.  But the real solution
>>is to use C code, and then incorporate it into a server as a configuration
>>option. 
>
>what a great idea! let me know when you're done! :-)
>
>zorst
>[obz@sisd.kodak.com]
>-- 

I believe somebody posted it a while ago on comp.unix.sysv386. Just aak
it over there.

H.J.

From: fangchin@leland.Stanford.EDU (Chin Fang)
Subject: Re: X, ET4000 and mice
Date: 10 May 92 09:22:56 GMT

In article < 1992May10.062117.5370@sisd.kodak.com>, 
obz@sisd.kodak.com (Orest Zborowski COMP) writes:
|> pmacdona@sanjuan (Peter MacDonald) writes:

|> >But not X386.  I like flexibility, but  I think maybe a more usable 
|> >configuration would be one that just lets you supply the Clock/VSync/HSync,
|> >and it would try some intelligent monitor timings.  Actually, have tried
|> >going through the video tutorial by Chin Fang.  Even tried developing
|> >a spreadsheet under oleo to do the calculations.  But the real solution
|> >is to use C code, and then incorporate it into a server as a configuration
|> >option. 

|> what a great idea! let me know when you're done! :-)

I whole heartedly agree the timing stuff should be done in a manner that's 
transparent to general users.  But I will tell a bit of background why the 
tutorial was written in the manner it is ...
 
The way I look at the timing calculation is basically a mult-objective 
optimization problem.  (Let's use non-interlace and multisync monitors for 
discussion purpose) It is because

(1) if you want high resolution => you get low refresh rate
(2) on the other hand, if you want high refresh rate => you can't get
    high resolution

So, some compromise has to be reached (thus multi-objective), and this 
compromise is *really* subjective, varying from person to person, quite
tough to meet using a program :(

And, there are *real* constraints as well.  The biggest constraint usually is 
a monitor's horizontal sync upper limit, this is the main constraint for most 
people. Normally most people have a video adapter which has far more capability
than his/her monitor (primarily due to cost). In addition, some early SVGA 
cards using crystals don't have certain desirable dot-clocks, and that's 
another constraint.  Third one is the available display memory, which is 
getting less important as 1MB equipped SVGAs and better are becoming more 
common. There are few others that I will not elaborate here.

In short, this is a classical constrained optimization problem.  One way
to solve it is to use Danzig's simplex method [a] or a simplex method 
with BFGS update nonlinear programming [b] afterwards for polishing (geez, 
what a fussy guy :).  However, the big trouble I had (and still having!) is
that there is no way I can 100% sure about the constraint values that *my
program* gets.  That is, it's not that hard to write a C code, 
probing the hardware, and obtaining constraints discussed above.  But
without extensive testing and validation, the timing suggested by such a code 
would be almost untrust-worthy as a random guess as soon as it is used on 
a unknown hardware.  Thus it would be really imprudent to release it.

Therefore, I often look at the descriptions (in fact, basic algorithm in 
disguise) in the timing tutorial with regret.  Simply because mathematically 
it's a very easy problem, but it is also ill-posed due to the fact that part 
of the problem formulation data are not guaranteed to be i) available and 
ii) accurate.  Given the situation of the commodity PC market, I doubt such 
a code would work for many :(

David Wexelblat at AT&T Bell Laboratories started collecting timing info
for various hardware a while back, primarily in comp.unix.sysv386.  Early
on I naively thought that soon this database would grow very significantly
and thus I would have a good base to train a neural network code [c], 
which, after trained using data in this database, would provide a good guess
(more precisely, interpolation, as neural network <=> glorified data
 interpolator).  But after months, even the latest version of X386 timing
data base is not as extensive as I would like to see.  So another regret...

The problem is still nagging me however :) ...

Have a nice weekend.

Chin Fang
fangchin@leland.stanford.edu
=============================================================================
PS. yes, this is a nerdy post.  But I believe some people must be thinking
    more or less along the same line, so I list two references below 

[a] D.G.Luenberger, Linear and Nonlinear Programming.  Addison-Wesley,
    Reading, Mass, 2nd, 1984, Chapter 3.
[b] op.cit, Chapter 9.
[c] Burnod, Adaptive Neural Network.  Prentice Hall. 1992

			        About USENET

USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.

		       SCO Files Lawsuit Against IBM

March 7, 2003 - The SCO Group filed legal action against IBM in the State 
Court of Utah for trade secrets misappropriation, tortious interference, 
unfair competition and breach of contract. The complaint alleges that IBM 
made concentrated efforts to improperly destroy the economic value of 
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services 
business. See SCO vs IBM.

The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or
research.

Electronic mail:			       WorldWideWeb:
   tech-insider@outlook.com			  http://tech-insider.org/