Newsgroups: comp.os.linux
From: pnakada@oracle.com (Paul Nakada)
Subject: Wow! X is great!
Nntp-Posting-Host: pnakada.us.oracle.com
Organization: Oracle Corporation, Redwood Shores, CA
Distribution: comp
Date: Thu, 7 May 1992 16:38:54 GMT
X-Disclaimer: This message was written by an unauthenticated user
at Oracle Corporation. The opinions expressed are those
of the user and not necessarily those of Oracle.
Many thanks to Thomas Roell and OBZ for their tremendous effort in
getting X11R5 up on the 386, and espeialliy Linux. This is a serious
credibility builder for linux.
a serious bug. If I pull down the xterm middle menu (control +
middlebutton (both buttons)) my screen gets shifted ~30% with the
right side wrapping to the left side. wierd.
is libobz.a going to be part of the 0.96 release? it's missing from
the pre 96 + X patches release, making building any X apps impossible.
Following up on my note from yesterday oncerning "lame" SVGA cards, I
must comment. Yesterday, I evaluated two video cards, the orchid
prodesigner IIs, and the Diamond Speedstar+, both running about $170 +
tax. Performance was *much* better then my trident 8900 chipset card.
Scrolling under windows 3.1 is actually accepable, and performance
under X is great.
I really think it's worth upgrading to a better card, just for the
performance benefits. my $0.02.
-Paul
--
Paul Nakada | Oracle Corporation | pnakada@oracle.com
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Wow! X is great!
Date: 7 May 92 17:40:38 GMT
Distribution: comp
Organization: University of Helsinki
In article < PNAKADA.92May7083854@pnakada.oracle.com> pnakada@oracle.com
(Paul Nakada) writes:
>
>a serious bug. If I pull down the xterm middle menu (control +
>middlebutton (both buttons)) my screen gets shifted ~30% with the
>right side wrapping to the left side. wierd.
Yes, this is one of the bugs that is still in the pre-0.96 release with
the X patches: it's due to the fact that error messages get printed to
the console, and the pre-0.96 kernel didn't notice that things were in
graphics mode, so it prints out the message and changes various VGA
regs, thinking it writes to a normal text-screen. This obviously doesn't
work too well when in garphics mode.
Other bugs relate to the pty's: when scrolling in an xterm it sometimes
stops, and you have to hit a key to get it to wake up. I've also found
it's possible to freeze the machine with ^C under some circumstances
when writing heavily to pty's. Don't try it without syncing first, and
avoid testing it at all if possible :)
All the above bugs should be fixed in next weeks release, so I'm not
making patches available right now. Additionally, 0.96 has the TIOCCONS
ioctl that allows a pty to get the output intended for the console (so
that you see whan processes write directly to /dev/tty0 etc), as well as
a syslog() system call (syscall nr 103) that reads the messages printed
with printk(). The syslog syscall means you can get the kernel warning
messages to a window under X. Of course, the really bad messages
(notably kernel panics) don't get printed, but hopefully those aren't
that usual.
TIOCCONS was easy to add due to the better vfs routines. Similarly, 0.96
now supports dropping DTR when a serial line is finally closed. Thank
abc for goading me into adding the trivial fix.
In an earlier post I mentioned that 0.96 might have a new floppy-driver:
I just patched it in today, and it seems to work, so that's official.
The new floppy-driver finally allows formatting, and also has
auto-detect floppies (much nicer than under minix: they are quite as
fast as the non-auto versions from my limited testing) as well as
user-defined floppy-types (ie you can define 20-sector formats on the
fly etc..). The patches were courtesy of Werner Almesberger, so send
him a kind thought.
>is libobz.a going to be part of the 0.96 release? it's missing from
>the pre 96 + X patches release, making building any X apps impossible.
Hlu has already added them to the library: the newest version should
have them and some other syscalls ([f]truncate etc). I also think it now
supports multiple shared libraries: practical for X and math. I haven't
had time to try it out myself yet.
Linus
Newsgroups: comp.os.linux
From: obz@sisd.kodak.com (Orest Zborowski COMP)
Subject: Re: Wow! X is great!
Organization: Printer Products Eastman Kodak
Distribution: comp
Date: Fri, 8 May 92 12:50:46 GMT
>>is libobz.a going to be part of the 0.96 release? it's missing from
>>the pre 96 + X patches release, making building any X apps impossible.
>
>Hlu has already added them to the library: the newest version should
>have them and some other syscalls ([f]truncate etc). I also think it now
>supports multiple shared libraries: practical for X and math. I haven't
>had time to try it out myself yet.
>
> Linus
libobz.a is in the pre0.96-obz.cdif.Z package, but in source form only.
you need to compile it (depending on if you have hlu's latest compiler)
and make a symlink from /usr/lib/libobz.a to it.
zorst
--
zorst (orest zborowski)
[reply to obz@sisd.kodak.com]
From: scottd@cs.hw.ac.uk (Scott Dunn)
Newsgroups: comp.os.linux
Subject: X and supported VGA cards.
Date: 7 May 92 11:39:45 GMT
Organization: Dept of Computer Science, Heriot-Watt University, Scotland
Could someone please post a list of suported cards.
The only chipset that seems to be mentioned is the
et4000. I don't know of all the different chipsets
and I don't have a clue what's on my card - an
Orchid Pro Designer II. I`ll have a look tonight.
Assuming the Pro Designer is not supported is there
anyone working on a driver for it? I believe it's
quite a good card. At least, in it's price bracket.
Whether or not my card is supported, it would clear
up a lot of questions if a definitive list was posted.
5 megs is a lot to ftp :-)
Further, what is wrong with 800x600x16. That's the
resolution I used (past tense) MS-Windows in. The
extra colours add a considerable overhead, and unless
your wanting to display nice gifs in the background
I don't really see the need for them. (OK I've now
got my flak jacket on - hit me :-) )
How difficult is it to write a driver for X. If
no-one is planning to write one for the Pro Designer
I **might** look into it this summer. Athough I
doubt if I'll get anywhere.
Cheers,
Scott.
From: scottd@cs.hw.ac.uk (Scott Dunn)
Newsgroups: comp.os.linux
Subject: X and supported VGA cards.
Date: 7 May 92 11:39:45 GMT
Organization: Dept of Computer Science, Heriot-Watt University, Scotland
Could someone please post a list of suported cards.
The only chipset that seems to be mentioned is the
et4000. I don't know of all the different chipsets
and I don't have a clue what's on my card - an
Orchid Pro Designer II. I`ll have a look tonight.
Assuming the Pro Designer is not supported is there
anyone working on a driver for it? I believe it's
quite a good card. At least, in it's price bracket.
Whether or not my card is supported, it would clear
up a lot of questions if a definitive list was posted.
5 megs is a lot to ftp :-)
Further, what is wrong with 800x600x16. That's the
resolution I used (past tense) MS-Windows in. The
extra colours add a considerable overhead, and unless
your wanting to display nice gifs in the background
I don't really see the need for them. (OK I've now
got my flak jacket on - hit me :-) )
How difficult is it to write a driver for X. If
no-one is planning to write one for the Pro Designer
I **might** look into it this summer. Athough I
doubt if I'll get anywhere.
Cheers,
Scott.
0, unseen,,
*** EOOH ***
Newsgroups: comp.os.linux
From: obz@sisd.kodak.com (Orest Zborowski COMP)
Subject: Re: X and supported VGA cards.
Organization: Printer Products Eastman Kodak
Date: Fri, 8 May 92 22:41:03 GMT
scottd@cs.hw.ac.uk (Scott Dunn) writes:
>Could someone please post a list of suported cards.
>The only chipset that seems to be mentioned is the
>et4000. I don't know of all the different chipsets
>and I don't have a clue what's on my card - an
>Orchid Pro Designer II. I`ll have a look tonight.
>Assuming the Pro Designer is not supported is there
>anyone working on a driver for it? I believe it's
>quite a good card. At least, in it's price bracket.
>Whether or not my card is supported, it would clear
>up a lot of questions if a definitive list was posted.
>5 megs is a lot to ftp :-)
the stock x11r5 release of x386 (on which the linux port was
based) only supports et3000, et4000, pvga1 and gvga. i've
heard of pd extensions to the trident chip and maybe others,
but haven't gotten around to trying them.
>
>Further, what is wrong with 800x600x16. That's the
>resolution I used (past tense) MS-Windows in. The
>extra colours add a considerable overhead, and unless
>your wanting to display nice gifs in the background
>I don't really see the need for them. (OK I've now
>got my flak jacket on - hit me :-) )
the x386 server uses packed 8-bit mode by default. changing
this would probably be quite a job, and i've heard that there
is no guarantee that all x applications would honor the
restricted mode (which i consider a limitation of the app).
>
>How difficult is it to write a driver for X. If
>no-one is planning to write one for the Pro Designer
>I **might** look into it this summer. Athough I
>doubt if I'll get anywhere.
depends on how well you know your chip and how closely it
maps onto the model assumed by the default distribution.
the drivers for the chips themselves are not very large,
but they are all very similar. i don't have access to these
different chips (nor have any intention to support them),
so you're kindof on your own.
>
>Cheers,
>
>Scott.
some random ramblings...
my original intent was to provide x386 to a limited readership.
i guess it was my own fault for not restricting this more
forcefully (could it have been my intention :-)... i wanted to
make sure that it worked more often than not, that most of the
fatal bugs were fixed, and that people who wanted to obtain a
binary version of the server and clients could do so (compiling
x386 is not a one-night affair, unless you count all-night!).
since more and more people are discovering this "hidden" location
of the x386 port, i've placed my diffs on banjo.concert.net for
others to work with. these diffs are against a partial version of
the x11r5 release of x386, since i didn't have that much space and
wanted to get down to a bare minimum. with the tremendous advances
made with gcc2.1 and linux0.96 the problems associated with creating
a full-fledged distribution should be minimized.
i've been using x386 almost constantly since i finished the port and
it seems to run very well (for my needs). a friend has successfully
ported xv, xmail, spider and other clients, which has boosted my
confidence in the port.
there are problems with it, the greatest one being the screen blanking
after the server exits. i've not gotten around to trying some solutions
to the x386 server itself (which only affect the et4000 version) nor
applying the brute-force solution of writing a program (possibly using
the vgalib posted) which resets text mode. has anyone run x386 without
an et4000? and had the screen not blank out?
i'm probably going to wait until linux0.96 before working some more
on the server (it's been a long time of hacking nonstop and am getting
more pressure at work :-), since linus is running x386 and has solved
some of the kernel related problems with pty's, etc. hopefully at this
time the x shared libs will be working (i'm running a few clients
with shared libs and their sizes are stunning!), so we can begin
with a "real" distribution of x386.
zorst
[obz@sisd.kodak.com]
--
zorst (orest zborowski)
[reply to obz@sisd.kodak.com]
Organization: Sophomore, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA
Newsgroups: comp.os.linux
Date: Fri, 8 May 1992 23:58:29 -0400
From: Court Demas < cd2a+@andrew.cmu.edu>
Subject: X Problems..
Ugh. Everything has been running really well until I tried to put X on
my system..
I downloaded and installed the X386 release. I followed all (I hope)
of the instructions and proceeded to type 'startx'. I first got the
same error everybody else has been getting (no tty0), so I checked
c.o.l. tried 'mknod /dev/tty0 c ? ?' - whatever somebody had posted as a
solution. I tried startx again only to have my screen enter some
strange mode with vertical white-striped garbage all over the place.
Reboot. I tried a number of different modes (800x600, 640x480, etc) and
the only difference I saw was that the screen when black and hung in
800x600 (instead of the white stuff).
Could it have anything to do with my tty0? (I'm totally clueless about
Unix devices). My system is fairly standard:
-Zeos 486/33
-8mb
-Microsoft Mouse
-Samsung MultiSync (from a few years ago - does 800x600 Windows fine,
and 1024x768 @30hz or something- gross)
-Diamond Speedstar+ w/1mb
(seems like I have a Hi-Color too, but I'm not supposed to! I ordered
the normal one, but it came with a 32k driver and when I used it it
worked! I have modified the colors in windows and there is absolutely
no noticable dithering of any colors I try. Strange..)
After all the posting about Tseng4000 boards, I figured I be fine! Has
anybody else had problems like this? [I used the bootimage that was
included in the X386 release (I figured it would be my best bet).]
thanks,
-court
on another note:
I am going to try to get the Tierra simulator running. Has anybody
tried this yet?
From: liljeber@kruuna.Helsinki.FI (Mika Pekka Liljeberg)
Newsgroups: comp.os.linux
Subject: Re: X Problems..
Date: 9 May 92 12:40:46 GMT
Organization: Department of Computer Science, University of Helsinki, Finland
In-Reply-To: cd2a+@andrew.cmu.edu's message of 9 May 92 03: 58:29 GMT
In article < Ee2orZ_00VpZ81RUUW@andrew.cmu.edu> cd2a+@andrew.cmu.edu (Court Demas)
wrote:
>
> Ugh. Everything has been running really well until I tried to put X on
> my system..
>
>
> I downloaded and installed the X386 release. I followed all (I hope)
> of the instructions and proceeded to type 'startx'. I first got the
> same error everybody else has been getting (no tty0), so I checked
> c.o.l. tried 'mknod /dev/tty0 c ? ?' - whatever somebody had posted as a
> solution. I tried startx again only to have my screen enter some
> strange mode with vertical white-striped garbage all over the place.
> Reboot. I tried a number of different modes (800x600, 640x480, etc) and
> the only difference I saw was that the screen when black and hung in
> 800x600 (instead of the white stuff).
>
> Could it have anything to do with my tty0? (I'm totally clueless about
Nope. Only console input is handled through tty0.
> Unix devices). My system is fairly standard:
>
> -Zeos 486/33
> -8mb
> -Microsoft Mouse
> -Samsung MultiSync (from a few years ago - does 800x600 Windows fine,
> and 1024x768 @30hz or something- gross)
> -Diamond Speedstar+ w/1mb
> (seems like I have a Hi-Color too, but I'm not supposed to! I ordered
> the normal one, but it came with a 32k driver and when I used it it
> worked! I have modified the colors in windows and there is absolutely
> no noticable dithering of any colors I try. Strange..)
>
>
> After all the posting about Tseng4000 boards, I figured I be fine! Has
> anybody else had problems like this? [I used the bootimage that was
> included in the X386 release (I figured it would be my best bet).]
Well, I got sick of bitching and moaning about my Trident 8800 board
(I was pretty fed up with it anyway) and bought a Boca Super X VGA ;-),
which has an ET4000AX chip an 1MB of memory on it, as well as Sierra
DACs (surprise!).
Right. I plugged it in and tried X. Well, X386 won't play ball with me
either! :-( I tried the default modes and when they didn't work, I
calculated a bunch of new ones based on my monitor's (NEC Multisync II)
specs (automatic horizontal sync from 15.5 kHz to 35 kHz). I'm pretty
sure I did it right, too. I can easily get a stable picture, but instead
of a single beautiful one I get two ugly ones, side by side. Both contain
the visible desktop, only squeezed in half along the X axis. I suspect
it's the Sierra DAC chips that cause this behaviour. Can anyone confirm
this? How do I get around the problem?
And then there is the mousie, of course. ;-( I've got a Genius mouse,
which can act either as a Microsoft mouse or a MouseSystems mouse.
It works, too. Not under X386, though. In Microsoft mode the mouse
cursor gets whopping mad, moving in quick jerks in the same general
direction I'm pushing the mouse. I've got no control whatsoever over
the buttons. X seems to think someone's bouncing on them, though. ;-)
In MouseSystems mode I get no response at all. Is the X mouse driver
picky, or what? ;-)
>
>
>
> thanks,
> -court
>
>
> on another note:
> I am going to try to get the Tierra simulator running. Has anybody
> tried this yet?
Not me.
Mika
--
Mika Liljeberg Email: liljeber@kruuna.Helsinki.FI
Helsinki University Mika.Liljeberg@Helsinki.FI
Dept. of Computer Science
From: markh@ghostwheel.stcloud.msus.edu (Mark Holden)
Newsgroups: comp.os.linux
Subject: Re: X Problems..
Date: 9 May 92 19:43:19 GMT
Organization: Saint Cloud State University
Nntp-Posting-Host: 134.29.38.2
In article < LILJEBER.92May9144046@kruuna.Helsinki.FI>,
liljeber@kruuna.Helsinki.FI (Mika Pekka Liljeberg) writes:
|> sure I did it right, too. I can easily get a stable picture, but instead
|> of a single beautiful one I get two ugly ones, side by side. Both contain
|> the visible desktop, only squeezed in half along the X axis. I suspect
|> it's the Sierra DAC chips that cause this behaviour. Can anyone confirm
I doubt it's the Sierra DAC, the same thing has happened to me with Diamond
Speedstar w/o Sierra DAC, when I had the incorrect configuration in Xconfig.
With the Diamond Speedstar+ and the Gateway 2000 Crystal Scan monitor, it's
a simple process to set up X386, and I'd done it before under Mach anyhow :)
The important thing is to get the correct clocks for your card, the ones that
are included in the Xconfig probably aren't right for yours. To see what
they are (as far as X386 is concerned) take the "clocks" linne out of Xconfig,
and run xinit, preferably from a login on one of the serial ports (I used my
Linux machine to set up my Mach machine, then reversed the process later :)
then make sure you have a line in modedb that corresponds to one of the clocks
that X386 shows (probably the last one).
|> And then there is the mousie, of course. ;-( I've got a Genius mouse,
|> which can act either as a Microsoft mouse or a MouseSystems mouse.
|> It works, too. Not under X386, though. In Microsoft mode the mouse
|> cursor gets whopping mad, moving in quick jerks in the same general
|> direction I'm pushing the mouse. I've got no control whatsoever over
|> the buttons. X seems to think someone's bouncing on them, though. ;-)
|> In MouseSystems mode I get no response at all. Is the X mouse driver
|> picky, or what? ;-)
I've run into severe wierdness with mice under x386. On Mach, my
Microsoft Mouse works _almost_ correctly, except that it doesn't recognise
a button press until you move the mouse, and then doesn't notice that the
button is being held down anyhow. The same behavior exists under Linux,
except that it does recognise that the button is being held down after you
move the mouse. So, I can use my mouse under Linux, but I had to punt back
to X11R4 under Mach . . . Also, I've tried a Logitech Mouseman, with
absolutely no luck whatsoever.
Newsgroups: comp.os.linux
From: dje@sspiff.UUCP (Doug Evans)
Subject: X386: R4 or R5?
Organization: Edmonton, Alberta
Date: Sat, 09 May 1992 20:17:27 GMT
Is the X386 that has been ported to Linux R4 or R5?
Or, put another way, is it X386 1.1b or 1.2 (or ?) ?
Secondly, Thomas, are the vga drivers architected the same in 1.2
as they are in 1.1b? Or, put another way, if I have a driver for 1.1b,
how usable is it with 1.2? How much work is involved in changing a 1.1b
vga driver to a 1.2 critter?
Lastly, Thomas, if I want to post my driver, which is for 1.1b, to say,
alt.sources, can I do it (re: copyrights, etc.)? Must I post diffs
(I'd prefer to post the whole thing: driver.c and ban
Newsgroups: comp.os.linux
From: pmacdona@sanjuan (Peter MacDonald)
Subject: X, ET4000 and mice
Nntp-Posting-Host: sanjuan.uvic.ca
Organization: University of Victoria, Victoria, BC, CANADA
Date: Sat, 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.
Newsgroups: comp.os.linux
From: obz@sisd.kodak.com (Orest Zborowski COMP)
Subject: Re: X Problems..
Organization: Printer Products Eastman Kodak
Date: Sun, 10 May 92 06:11:41 GMT
markh@ghostwheel.stcloud.msus.edu (Mark Holden) writes:
>In article < LILJEBER.92May9144046@kruuna.Helsinki.FI>,
liljeber@kruuna.Helsinki.FI (Mika Pekka Liljeberg) writes:
>|> sure I did it right, too. I can easily get a stable picture, but instead
>|> of a single beautiful one I get two ugly ones, side by side. Both contain
>|> the visible desktop, only squeezed in half along the X axis. I suspect
>|> it's the Sierra DAC chips that cause this behaviour. Can anyone confirm
>
>I doubt it's the Sierra DAC, the same thing has happened to me with Diamond
>Speedstar w/o Sierra DAC, when I had the incorrect configuration in Xconfig.
>With the Diamond Speedstar+ and the Gateway 2000 Crystal Scan monitor, it's
>a simple process to set up X386, and I'd done it before under Mach anyhow :)
>The important thing is to get the correct clocks for your card, the ones that
>are included in the Xconfig probably aren't right for yours. To see what
>they are (as far as X386 is concerned) take the "clocks" linne out of Xconfig,
>and run xinit, preferably from a login on one of the serial ports (I used my
>Linux machine to set up my Mach machine, then reversed the process later :)
>then make sure you have a line in modedb that corresponds to one of the clocks
>that X386 shows (probably the last one).
that's right. it's probably up there on the x386 faq! i hoped i was clear
enough in the readme that you need to examine the xconfig very carefully.
the clock recognition in linux's x386 isn't stable because i had no clean
way to disable interrupts while the detection was going on. that's why i
provided the vga.dbase file with all the clocks. i'm afraid you have to
1. run x386 by itself, redirecting stderr to a file (i.e. x386 2>/tmp/OUT)
and then exit it to see what clocks it reads (after commenting out the
clocks in the provided xconfig)
2. run the clock.exe program hlu posted, which is much more stable because
there are no context switches in dos
3. lookup your card in the vga.dbase and plug it in, then try various
configurations until one works.
even after you get what you think are the right clocks, you still may not
get a stable display. this is because there could be multiple entries for
each resolution, with different clock values. since x386 chooses the last
one from the list (not the first, as advertised), that may well be wrong
(it was for me). so simply comment out the extras. this is also true for
entries with the same clock but different timings, as for the 1024x768 mode.
try with the lowest clock frequencies (25mhz) and at 640x480. this is
probably the safest bet (i ran this way for a while until i discovered
the multiple timing problems above) to get things to work. even at this
resolution you can still have a virtual space thats 1152x900, and pan
around.
>
>|> And then there is the mousie, of course. ;-( I've got a Genius mouse,
>|> which can act either as a Microsoft mouse or a MouseSystems mouse.
>|> It works, too. Not under X386, though. In Microsoft mode the mouse
>|> cursor gets whopping mad, moving in quick jerks in the same general
>|> direction I'm pushing the mouse. I've got no control whatsoever over
>|> the buttons. X seems to think someone's bouncing on them, though. ;-)
>|> In MouseSystems mode I get no response at all. Is the X mouse driver
>|> picky, or what? ;-)
>
> I've run into severe wierdness with mice under x386. On Mach, my
>Microsoft Mouse works _almost_ correctly, except that it doesn't recognise
>a button press until you move the mouse, and then doesn't notice that the
>button is being held down anyhow. The same behavior exists under Linux,
>except that it does recognise that the button is being held down after you
>move the mouse. So, I can use my mouse under Linux, but I had to punt back
>to X11R4 under Mach . . . Also, I've tried a Logitech Mouseman, with
>absolutely no luck whatsoever.
with two button mice x386 needs to do three button emulation (there is a
line in xconfig for that too). inside the server there is a state machine
which treats a single press as "ok, now what? the other button, to make the
missing middle one? or something else?". when you move the mouse, or release
it, it gives up waiting for the "middle" button. i guess there could be
a small timeout which could say "enough already, its a press". since i have
to contend with this, i'll look into how it can be done.
as for other mice, i don't have them, but i know you need to be careful about
the baud rate and bits-per-sample. i thought the kernel default was to
use cs8, passing 8 bit, but that may be incorrect, or may be modified if
you're sharing the line with a modem, etc. the server only uses cs7 with
the microsoft mouse, but the kernel doesn't honor this, so i plugged in
an istrip for this case (only if cs7 was asked for). one person wrote to
me and said that turning off istrip made his mouse work, so you may want
to try "stty -istrip >/dev/ttys2" in your startx script. if this is the
case, i may add the logic to turn off istrip if its cs8 mode.
zorst
[obz@sisd.kodak.com]
--
zorst (orest zborowski)
[reply to obz@sisd.kodak.com]
Newsgroups: comp.os.linux
From: obz@sisd.kodak.com (Orest Zborowski COMP)
Subject: Re: X386: R4 or R5?
Organization: Printer Products Eastman Kodak
Date: Sun, 10 May 92 06:32:57 GMT
dje@sspiff.UUCP (Doug Evans) writes:
>Is the X386 that has been ported to Linux R4 or R5?
>Or, put another way, is it X386 1.1b or 1.2 (or ?) ?
the linux x386 port was based on the stock distribution from x11r5, from
mit and was done by me, not thomas, although in terms of quantity of
effort, his was more inspiration while mine was more perspiration :-)
>
>Secondly, Thomas, are the vga drivers architected the same in 1.2
>as they are in 1.1b? Or, put another way, if I have a driver for 1.1b,
>how usable is it with 1.2? How much work is involved in changing a 1.1b
>vga driver to a 1.2 critter?
diffs for the linux distribution are available on banjo.concert.net, and
they don't touch much of the meat of the vga drivers, except to change
all asm global names from foo to _foo.
--
zorst (orest zborowski)
[reply to obz@sisd.kodak.com]
Newsgroups: comp.os.linux
From: obz@sisd.kodak.com (Orest Zborowski COMP)
Subject: Re: X, ET4000 and mice
Organization: Printer Products Eastman Kodak
Date: Sun, 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]
Newsgroups: comp.os.linux
From: fangchin@leland.Stanford.EDU (Chin Fang)
Subject: Re: X, ET4000 and mice
Organization: DSG, Stanford University, CA 94305, USA
Date: Sun, 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
Newsgroups: comp.os.linux
From: pmacdona@sanjuan (Peter MacDonald)
Subject: More ET4000: a bug?
Nntp-Posting-Host: sanjuan.uvic.ca
Organization: University of Victoria, Victoria, BC, CANADA
Date: Mon, 11 May 92 05:08:49 GMT
I have found that two ET4000 cards (Aamazing and VGA 2theMax) which both work
fine under DELL Unix at work, do not work under Linux at home. And I am seeing
some funny behaviour on the clock reporting. The Aamazing has a utility that
sets modes (dmode) and tells you the Video Clock associated. It reports a
set of 8 modes. Cooincedentally, the modes reported by X386 when it starts up
are "exactly half". Ie:
Aamazing Utility: 50 56 72 45 60 65 40 47
becomes
X386: 25 28 36 23 30 32 20 24
And no matter what I do, I always get multiple images (4 usually) on the screen.
Could this be a bug in the X386 server?
PS: Solved my mouse problem by switching to a different MS mouse.
From: pmacdona@sanjuan (Peter MacDonald)
Newsgroups: comp.os.linux
Subject: Re: More ET4000
Date: 11 May 92 18:36:50 GMT
Organization: University of Victoria, Victoria, BC, CANADA
Nntp-Posting-Host: sanjuan.uvic.ca
Thanks to Chin Fang for his tutorial, and his ideas on optimization.
Critique the following please:
Perhaps it would help if we fixed some of the parameters. After all,
finding the optimum configuration for our Card/Monitor pair is, to
most of us, secondary to getting the damn thing to work at all.
It seems to me, that most video cards cards can do "640x480" "800x600"
and "1024x768" and they just assume certain monitor characteristics.
Also, the video cards I have tried also provide a way of finding out
what the horiz freq and video clock used with these are, either in a
manual or under DOS utilities.
Since X386 can detect clocks itself (theoretically), a usable configuration
would just have to supply the monitor max horiz sync freq.
Perhaps the following could work:
---------------------------------------------------------------
Modes "640x480" "800x600" "1024x768"
MaxHorizFreq 35.5
vga256
#Resolution Clock H.Freq
"640x480" 25 35.5 640 672 699 728 800 810 830 850
"640x480" 28 38 640 ....
"640x480" 40 40 640 ....
"800x600" 28 35.5 800 ....
"800x600" 40 40 800 ....
...
---------------------------------------------------------------
Perhaps modes can be extended to specify exact clocks/freq like:
Modes "640x480"-28 "800x600"-40-40 "1024x768"
But the default could be to just assume a fairly log sync freq, like 35.
So, does this sound reasonable? Or am I coming from somewhere around
the orbit of europa?
pmacdona@tadpole.bcsc.gov.bc.ca
Newsgroups: comp.os.linux
From: pmacdona@sanjuan (Peter MacDonald)
Subject: X finally up
Nntp-Posting-Host: sanjuan.uvic.ca
Organization: University of Victoria, Victoria, BC, CANADA
Date: Tue, 12 May 92 03:14:01 GMT
After about 10 hours of trying, I finally have X up and running.
Except for losing a few chars now and then at 9600 with a large font
scrolling in an Xterm, I have no complaints. I have an uncached 386/25,
and am using an older (2 years) VGA Morse monitor.
Because so many others seem to be having the same kind of trouble I did,
I will quickly describe my experience:
1) Forget the timing parameters X reports, they are probably wrong.
2) Forget the timings "clock" gives, mine were divided by two.
3) Use "dmode" or whatever utility/manual comes with your video card
to figure out your clocks.
4) Try [Vendor "hicolor"] if you have a DAC.
5) I had to use interlace, because of my slow monitor.
6) Here is the config I ended with:
----------------------------------------------------------------
Microsoft "/dev/ttys2"
BaudRate 1200
# SampleRate 150
Emulate3Buttons
#
# The graphics drivers
#
vga256
Chipset "et4000"
Vendor "hicolor"
Virtual 1024 1024
ViewPort 0 0
Modes "1024x768i"
Clocks 50 56 72 45 60 65 40 47
ModeDB
# clock horzontal timing vertical timing
"640x480" 56 640 672 768 800 480 490 492 525
"1024x768i" 45 1024 1064 1224 1264 768 777 785 817 Interlace
From: pmacdona@sanjuan (Peter MacDonald)
Newsgroups: comp.os.linux
Subject: 0.96 praise
Date: 14 May 92 17:35:23 GMT
Organization: University of Victoria, Victoria, BC, CANADA
Nntp-Posting-Host: sanjuan.uvic.ca
Amidst the hail of criticism 0.96 has received, I thought I should
report that it has worked fine for me. In particular, X seems to
be much more stable, and the serial code no longer loses characters,
even in X with the largest font scrolling on my 386/25. Excellent.
Newsgroups: comp.os.linux
From: pmacdona@sanjuan (Peter MacDonald)
Subject: X, oleo, and shoelace
Nntp-Posting-Host: sanjuan.uvic.ca
Organization: University of Victoria, Victoria, BC, CANADA
Date: Fri, 15 May 92 17:25:07 GMT
Apologies in advance for the potpourri, but this newsgroup
is getting so busy, I am trying to minimize my postings.
First, seems I can not start X as root anymore. The video mode is
so screwed up, my screen shuts down. User mode works fine.
Also the "su" command doesn't work under X. I see the password
as I type it, but it rejects my login. Could be old SW, as I haven't
got the root disk lately.
Next, has anyone else who has no coprocessor, tried running "xv"?
It works fine for me until I go into the "coledit" area, then
my machine locks up tight. Could this be a floating point problem?
Oleo has a big problem. Copying areas doesn't usually adjust cells correctly.
I notice copying above the current area works, but below only adjusts the
column address and not the row address (aaargh). I will look at it this
weekend.
Now shoelace. The port I did of shoelace is partial, at best. Loading
kernel by parts is definitely a Minix anachronism. Also setting
bootdev, rootdev, etc may or may not work since device numbers do
not always map exactly from Linux to Minix. I have used shoelace since
I ported it, but don't get to attached to it. It reads the file system
directly and only understands Minix FS type. When VFS comes, and
you use a big partition as your boot partition (to get long filenames),
it will fail.
And of course, I provided almost no documentation with the port, mainly
because most of the features don't work. The only reason I ported it at
all was that at the time, many utilities were missing from Linux, so I
had to keep my Minix partition around, which meant I couldn't repartition
my drive for a Linux boot partition.
|