From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Sun, 19 Sep 93 14:13:13 EDT Subject: Linux-Development Digest #109 Linux-Development Digest #109, Volume #1 Sun, 19 Sep 93 14:13:13 EDT Contents: AHA1542c Compatible with Linux??? (Kirby Koster) Re: Mouseless X for Linux notebook (Maurice S Barnum) Pro Audio Spectrum SCSI? (Le Mauvais Sophiste) Re: SCSI command linking (Bill Mitchell) Re: Mouseless X for Linux notebook (Brandon S. Allbery) Linux, Notebooks, XFree86, and LCDs (Peter C Olsen) Where is "fsync(2|3)"?? (Tim Peoples) Re: Where is "fsync(2|3)"?? (Tim Peoples) Re: Linux and DOS 6.0 compression? (Ed Haymore) Reference Guide for Windows Emulators. (CSHAULIS@DELPHI.COM) Re: How to write X11 programs (no Motif available?)? (David Channon) Re: Let's have a prog to restore screen state! (David Kastrup) Re: ftp and ftpd pretty broke (Christopher Lau) Re: Let's have a prog to restore screen state! (Risto Kankkunen) Re: AHA1542c Compatible with Linux??? (CSHAULIS@DELPHI.COM) ---------------------------------------------------------------------------- From: kkoster@ub.d.umn.edu (Kirby Koster) Subject: AHA1542c Compatible with Linux??? Date: 18 Sep 1993 15:57:22 -0500 After some hassles I managed to get an old ('88) Adaptec 1542 and finally have linux up and running!! I've noticed however that the floppy controller seems to be giving my QIC80 tape drive some trouble. I can't even get it to restore my dos partition now even after lowering the restore rate. I really like the adaptec so I was thinking of picking up a newer model. The only one that seems available however, is the AHA1542c bus mastering model. I've looked on the hardware compat list and it only lists the 1542 and 1542B. Does anybody know if the C is compatible? I already went through purchasing one scsi controller that wasn't compatible, and I'd hate to get raked again. Thanx Kirby Koster kkoster@ub.d.umn.edu University of Minnesota - Duluth Department of Computer Engineering ------------------------------ From: msb@cats.ucsc.edu (Maurice S Barnum) Subject: Re: Mouseless X for Linux notebook Date: 18 Sep 1993 22:26:32 GMT In <27foki$qno@news.u.washington.edu> verzani@bunuel.math.washington.edu (John Verzani) writes: > There is a window manager FWM which says it can be run >under Linux wothout a mouse. There is a combination of >keystrokes which can move you about. olwm/olvwm and probably even the *twm window managers can be configured to run mouseless also. -- Maurice S. Barnum + There is no confusion like the msb@cats.ucsc.edu | confusion of a simple mind. mbarnum@eis.calstate.edu + --- F. Scott Fitzgerald PGP fingerprint: 26 46 7A 02 F0 5C C1 67 76 3D 53 39 79 D3 C9 26 ------------------------------ From: myddryn@netcom.com (Le Mauvais Sophiste) Subject: Pro Audio Spectrum SCSI? Date: Sat, 18 Sep 1993 22:52:04 GMT Has anyone done any work on a SCSI driver for the Pro Audio Spectrum Card? Alternativly, an one of the exisiting drivers be made to work with it? -- "Maturity is a slow death." "If Jesus died for our sins, would it not be disrespectful to live a life without sin, thus rendering his sacrafice in vain?" - Jules Feiffer Adam Sussman - myddryn@netcom.COM - asussman@ucsd.edu Chairman, UCSD chapter of the ACM ------------------------------ From: mitchell@mdd.comm.mot.com (Bill Mitchell) Subject: Re: SCSI command linking Reply-To: mitchell@mdd.comm.mot.com (Bill Mitchell) Date: Sat, 18 Sep 1993 23:12:28 GMT in comp.os.linux.development, eric@tantalus.nrl.navy.mil (Eric Youngdale) said: >In article <1993Sep18.150616.7417@mdd.comm.mot.com> mitchell@mdd.comm.mot.com (Bill Mitchell) writes: >>[.. story of SCSI timeout woes ..] > > My guess is that you have the bus improperly terminated. [...] All devices are internal. Controller is at one end and is terminated, then the two disks, neither terminated, then the tape which is terminated. I've replaced the cable, and have tried different device orderings along the cable - always terminating the last device on the cable. >[..] > I have tried operating scsi busses in the past that were not properly >terminated. I would get read errors, medium errors, timeouts, the whole nine >yards. Fixing the termination makes the bus rock solid, at least in terms of >the distribution kernel. I sold a Sun system to move to linux. That system had two external SCSI disk/tape boxes daisy-changed on a long SCSI cable. It would work reliably only if all terminators were removed and the bus left unterminated. I didn't expect that to work with my linux system, but I tried it. My expectations were fulfilled - it didn't work :-). -- mitchell@mdd.comm.mot.com (Bill Mitchell) ------------------------------ From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: Mouseless X for Linux notebook Date: Sat, 18 Sep 1993 23:37:52 GMT In article <27g1uoINNbm4@darkstar.UCSC.EDU> msb@cats.ucsc.edu (Maurice S Barnum) writes: >In <27foki$qno@news.u.washington.edu> verzani@bunuel.math.washington.edu (John Verzani) writes: >> There is a window manager FWM which says it can be run >>under Linux wothout a mouse. There is a combination of >>keystrokes which can move you about. > >olwm/olvwm and probably even the *twm window managers can be >configured to run mouseless also. fvwm was designed for laptop use, if I recall correctly. You can run ol(v)wm, certainly, but unless you've 12-16MB RAM in your laptop it'll be really slow. If you have only 4MB, fvwm and rxvt (and, preferably, XF86_Mono to really reduce the memory requirements) are the only sensible way to go unless you want to die of old age while your machine thrashes.... ++Brandon -- Brandon S. Allbery kf8nh@kf8nh.ampr.org bsa@kf8nh.wariat.org "MSDOS didn't get as bad as it is overnight -- it took over ten years of careful development." ---dmeggins@aix1.uottawa.ca ------------------------------ Crossposted-To: comp.os.linux.help,comp.windows.x.i386unix From: pcolsen@super.org (Peter C Olsen) Subject: Linux, Notebooks, XFree86, and LCDs Date: Sun, 19 Sep 1993 00:27:20 GMT I'm looking for anyone who has ever successfully installed Linux and XFree86 on an LCD laptop. I have a laptop that I carry for school and Reserves and I have been told that getting XFree to run on an LCD will be non-trivial. I have read the FAQ. I'm using XFree86 version 1.3. The mono server runs on my laptop driving an external monitor but does not drive the LCD. I have tried Xega, but cannot get it to run. I'm willing to invest substantial time, but I would like an existance proof before I do so. Peter -- Peter Olsen, n2ell, pcolsen@super.super.org ...!uunet!super!pcolsen P.O. Box 410, Simpsonville, MD 21150-0410; 410-997-8584 "Engineering is the art of applying a professional knowledge of mathematics and the physical sciences to improve the quality of life" ------------------------------ From: tep@rzrbyte.fay.ar.us (Tim Peoples) Subject: Where is "fsync(2|3)"?? Date: Sun, 19 Sep 1993 02:56:55 GMT This post may very well be in vain, but, here goes. I tried to compile something using the new Berkeley db-1.6 library but, alas, ld complained that it could not find "fsync". I'll have to admit that I am still using the 4.3.2 library with GCC 2.3.3 (I know, I know, but every thing has worked fine so far and "if it ain't broke, don't fix it). Also, this is all happening on a 0.99.10 kernel. Anyway, what do I need to upgrade (kernel, libs, or both) in order to get the elusive "fsync". Thank you one and all for your patience and understanding. Ciao, Tim -- Timothy E. Peoples tep@rzrbyte.fay.ar.us ------------------------------ From: tep@rzrbyte.fay.ar.us (Tim Peoples) Subject: Re: Where is "fsync(2|3)"?? Date: Sun, 19 Sep 1993 03:53:27 GMT tep@rzrbyte.fay.ar.us (Tim Peoples) writes: > This post may very well be in vain, but, here goes. > > I tried to compile something using the new Berkeley db-1.6 library >but, alas, ld complained that it could not find "fsync". I'll have >to admit that I am still using the 4.3.2 library with GCC 2.3.3 (I Correction: I am using libc 4.4 not 4.3.2 >know, I know, but every thing has worked fine so far and "if it ain't >broke, don't fix it). Also, this is all happening on a 0.99.10 kernel. > > Anyway, what do I need to upgrade (kernel, libs, or both) in order >to get the elusive "fsync". > > Thank you one and all for your patience and understanding. > >Ciao, >Tim > >-- > >Timothy E. Peoples >tep@rzrbyte.fay.ar.us > -- Timothy E. Peoples tep@rzrbyte.fay.ar.us ------------------------------ Date: Sat, 18 Sep 93 23:30:19 MDT From: haymoree@hawaii.et.byu.edu (Ed Haymore) Subject: Re: Linux and DOS 6.0 compression? Matt Welsh (mdw@sunSITE.unc.edu) wrote: | From what I understand, Linux dosfs is not compatible with DOS 6.0 | compression utilities (Stacker et. al.). This also appears to cause | problems with LILO; i.e. because the DOS filesystem is compressed, | LILO can't chain to boot MS-DOS. (I really know nothing about DOS 6.0, so | I could be wrong). LILO boots my DOS 6 compressed filesystem without any trouble. -- Ed Haymore ed@byu.edu ------------------------------ From: cshaulis@news.delphi.com (CSHAULIS@DELPHI.COM) Subject: Reference Guide for Windows Emulators. Date: 19 Sep 1993 02:30:46 -0400 The following is transcribed from page 372 of the October 1993 issue of Windows magazine. It appears without the permission of the publishers, so sue me. Or even better yet, see if you can't talk Letterman into letting me do "Copyright Infringement Theater" the next time he needs to fill time. :) --- Book o' the Month Windows Internals, by Matt Pietrek, belongs on the reference shelf of every serious Windows programmer. It lets you see the source code to each and every documented Windows 3.1 API function. No, the author didn't sneak into Microsofts offices in the dark of the night and abscond with a pile of printouts. Instead, the same approach was used as in Undocumented Windows -- the API functions were reverse-engineered with a disassembler, and pseudo-C code was generated for each function. So, while you see source for every function, it is not necessarily the same source used by Microsoft. Windows Internals, $29.95; Addison-Wesley, Reading, Mass.; (800) 358-4566, (617) 944-3700, ext. 2431. --- Christopher cshaulis@delphi.com ------------------------------ From: dchannon@peach.newcastle.edu.au (David Channon) Subject: Re: How to write X11 programs (no Motif available?)? Date: Sun, 19 Sep 1993 00:55:39 GMT neumann@watson.ibm.com (Gustaf Neumann) writes: >In article <1993Sep15.123924.21164@dcs.warwick.ac.uk> from [Wed, 15 Sep 1993 12:39:24 GMT] you wrote: > |> In <8yVV0B3w165w@cybernet.cse.fau.edu> dnewcomb@cybernet.cse.fau.edu (Dan Newcombe) writes: > |> > What would be perfect would be header files to mimic Motif calls and > |> > translate them into Tcl/Tk calls :) > |> > |> There was an announcement that such a thing existed, and had been uploaded > |> to export. I have heard nothing further (nor attempted to try it). You could use wxwin150e for development, This is a C++ wrapper for Motif widget or XView, It supports also windows3.1 and NT in the works. This is a great package, Cross platform for it's main objective but its so functional for single platform development aswell. The shared lib will be announced soon, I thank Juian smart and those involved in the shared lib port (Xview widgets). Cheers Dave. ------------------------------ From: dak@messua.informatik.rwth-aachen.de (David Kastrup) Subject: Re: Let's have a prog to restore screen state! Date: 19 Sep 1993 13:33:43 GMT dwex@mtgzfs3.att.com (David E. Wexelblat) writes: >In article <27dauq$osn@klaava.Helsinki.FI> kankkune@klaava.Helsinki.FI (Risto Kankkunen) writes: >> >> >Remember that bank switching is something that would affect screen >> >"normality," yet I wouldn't want the X server having to do a bunch >> >of ioctl()s every time my mouse crossed a bank boundary. >> >> There aren't so many banks on a screen, and it would probably be one >> ioctl with an array. It might not be too bad, I don't know (and it can >> heavily depend on the screen mode). >You don't have any idea how this stuff works, do you? Bank switchs occur >often during graphics operations. It doesn't have anything to do with >mouse behavior, it has to do with where things are drawn on the screen. Oh, and I *always* assumed that the mouse cursor gets drawn in some way on the screen. And of course, if a window headline lights up when I enter its window, this has *nothing* to do with drawing and bank switching, but occurs magically because of an intelligent video card. -- David Kastrup dak@pool.informatik.rwth-aachen.de Tel: +49-241-72419 Fax: +49-241-79502 Goethestr. 20, D-52064 Aachen ------------------------------ From: clau@acs.ucalgary.ca (Christopher Lau) Subject: Re: ftp and ftpd pretty broke Date: Sun, 19 Sep 1993 16:51:14 GMT dak@messua.informatik.rwth-aachen.de (David Kastrup) writes: > This is SLS 1.03, the NET-2 type excutables. When trying mput *, > an error message like Improper directory sth comes, and after that, > even put does no longer work, with an occasional Segmentation > Violation and core dump. > > mput * is BROKE,BROKE,BROKE! > Try 'mput ./*' instead.. there's a one-line hack-fix for this, but I don't recall what it is right now.. > Furthermore, when ftping into the thing, and listing a directory, > sometimes the thing simply breaks down. > Never had this happen to me yet.. > N*O*W, I am going into linux with an ftp/ out of linux with a telnet from > a DOS box (NCSA telnet/ftp). It just *might* be that this program is > not *too* standard, BUT it should not be able to *break* ftp and ftpd, > especially since another Unix (isc) is getting along fine with that. > > Linux/linux connections seem to work better (I have not checked the > mput bug, though), but this behaviour is intolerable. > Furthermore, ftp for some reason reads username/password from > (I guess) /dev/tty, making ftp shell scripts non-working. > > And not too seldom the thing just crashes. That's because of the net-2 kernel in general.. I'm using the telnet and ftp clients from net-2 on a 0.99pl9 kernel, and the only problems I've had to date are the mput/mget and the wierd problem at login where the "331 Password required for .." message comes *after* the password prompt (Has anyone found a fix for this?? This is a particularly wierd problem since the source shows that the password prompt is printed *after* it tries to get the reply from the remote, but the opposite happens when you run it.. ) > -- > David Kastrup dak@pool.informatik.rwth-aachen.de > Tel: +49-241-72419 Fax: +49-241-79502 > Goethestr. 20, D-52064 Aachen -- Christopher Lau | Dammit Jim, I'm a doctor, The University of Calgary | not an engineer! Dept. of Electrical & Computer Engg. | Well, you're an engineer now.. lau@enel.ucalgary.ca -OR- clau@acs.ucalgary.ca -OR- root@fusion.cuc.ab.ca ------------------------------ From: kankkune@klaava.Helsinki.FI (Risto Kankkunen) Subject: Re: Let's have a prog to restore screen state! Date: 19 Sep 1993 20:11:57 +0300 >The performance will be completely unacceptable. [etc.] Thanks for the numbers. >> >Remember that bank switching is something that would affect screen >> >"normality," yet I wouldn't want the X server having to do a bunch >> >of ioctl()s every time my mouse crossed a bank boundary. >> >> There aren't so many banks on a screen, and it would probably be one >> ioctl with an array. It might not be too bad, I don't know (and it can >> heavily depend on the screen mode). > >You don't have any idea how this stuff works, do you? Bank switchs occur >often during graphics operations. It doesn't have anything to do with >mouse behavior, it has to do with where things are drawn on the screen. Yes, I have, but I haven't programmed one for ages and I haven't checked out what XFree does. Other X servers I'm pretty familiar with. I wasn't the one talking about mouse, if you can see, but that's irrelevant. The point was that a relatively light operation like drawing the mouse cursor would be unacceptably slow, if every port access went through kernel. My hunch was that redrawing the cursor wouldn't need many bank switches (unless your card is in a mode, where each plane is in separate bank). Anyway, whether or not this particular case was costly isn't important enough for you to start shouting. >> But one of those speed hacks might be that programs handling VC switches >> on their own might have the responsibility to save their screen state >Gee, now why didn't we think of this? Guess what. This is how it works >NOW. If you're still following me, I thought about a scheme where "normal" programs (i.e. text mode) would operate completely through ioctl (that wouldn't be too costly) and others would access the screen directly _after reserving the screen_. I don't think this is how it works NOW, because there isn't a single video driver, nor ioctl, nor does any program that uses the display reserve it in any way. The most important point in my original article was to suggest that the screen access goes through kernel so it can be coordinated. Whether it is at the port level or by allocating/freeing the screen isn't so important, I presented just some examples and was expecting some discussion. >> Things like blanking a positive screen etc. belong to the driver. > >But VGA, EGA, CGA, MDA, HGA are all trivial to do in a console driver. You would like the support for all of these to be in console.c, or what? I think it would be a bit cleaner, if there were video drivers for (some of) these cards. For example, I have this NDC (Nokia display card) that has some proprietary blanking etc. functions. I wouldn't like to patch every kernel release (console.c) to support that, nor do I think support for this obscure card would go into the standard distribution. It would be much easier for me to write a small driver for this card that I could install with a stock kernel. Having a real driver would allow me to write a 90x30 mode for my Hercules (by using graphics to emulate that text mode, for example). Etc. Etc. >Yes, we have some numbers. Suffice it to say that EVERY X server that I >am aware of on Intel hardware does things the way XFree86 does them. Now I must plead my ignorance, but I'm not familiar with the drivers of other PC unixes. I'm not that interested in how XFree works for them, but what kind of devices these OSes offer. Do they have any frame buffer devices, what kind of operations they offer and is it necessary to by-pass (some of) them for performance reasons? >> That would mean the driver had to know the adapter pretty intimately for >> it to know when the screen is in graphics mode. This wouldn't, however, >> help you much if you switch to a non-default text mode. > >You really don't know what you're talking about, do you? There is basically >one bit in one register that says whether or not a VGA-class board is in >text or graphics mode. Well, there's the bit 0 of index 0x10 at port 0x3c0 in regular VGAs, but I have heard so much about how the different SVGAs are so different that I don't know if inspecting that bit is reliable. That was, however, the most irrelevant part of the chapter you quoted. Point one was that it would be very limited to have such a driver, as it would only restore the screen correctly when you switch to a VC that has the default text mode. Furthermore, it shouldn't be necessary for the kernel to check the VT you are switching from, the kernel (driver) should just set the card to the (text) mode it knows the target VT to be in. >Give it a shot. Maybe you'll learn something. What you'll learn is >(a) this stuff is really hard, (b) we do it this way for a reason, and >(c) what you hope to accomplish is impossible without using the BIOS. I might start making the framework for this, but I would not have the resources to verify if it would work with all or any of the SVGAs. This is why I'm asking these things here, so I wouldn't start making a totally useless framework. With a) I agree, but b) I don't understand at all. It wouldn't change the way XFree works very much, even if there were the video drivers. And I cannot see, how XFree could work any other way currently, when there are no drivers it could use. Could you elaborate. About c), I'd say it's hard but not impossible. After disassembling my hard disk BIOS know it takes a lot of time. There has been a lot of talk about a BIOS hd driver for linux. The answer to that seems every time to be that it would be messy and you'd better write a real driver for linux based on the BIOS of your card. Isn't it the same with video cards? >I assume that you think the XFree86 developers are idiots, becasue we haven't >gotten it all right yet. No (unless they're all like you ;-). I haven't really said or even thought anything bad about XFree, I don't understand where you get ideas like above. I even haven't found any major problems with XFree. My articles in this thread did not refer XFree in any way except it was used as an example of a program operating in graphichs mode by others. So gimme a break. What I'd like to do is make the linux environment more robust and modular and video access is one of those areas that might be improved. I think this would benefit XFree, too. You might offer your expertise to tell what linux features would help XFree, what problems there are getting a complete state of SVGA cards in general or with particular models etc. -- It's that time of the year again ------------------------------ From: cshaulis@news.delphi.com (CSHAULIS@DELPHI.COM) Subject: Re: AHA1542c Compatible with Linux??? Date: 19 Sep 1993 13:14:20 -0400 kkoster@ub.d.umn.edu (Kirby Koster) writes: :After some hassles I managed to get an old ('88) Adaptec 1542 and finally :have linux up and running!! I've noticed however that the floppy controller :seems to be giving my QIC80 tape drive some trouble. I can't even get it to :restore my dos partition now even after lowering the restore rate. I really :like the adaptec so I was thinking of picking up a newer model. The only one :that seems available however, is the AHA1542c bus mastering model. :I've looked on the hardware compat list and it only lists the 1542 and 1542B. :Does anybody know if the C is compatible? I already went through purchasing :one scsi controller that wasn't compatible, and I'd hate to get raked :again. :Thanx :Kirby Koster :kkoster@ub.d.umn.edu :University of Minnesota - Duluth :Department of Computer Engineering In section 3.D of the SCSI HOW-TO, they not only list 1542C as compatible, they give some special settings fro the BIOS. As for getting stuck with incompatible cards, most mail-order houses will let you return cards fro thirty days, although some charge a small restocking fee to do so. I'm planning to buy one myself. Christopher cshaulis@Delphi.Com ------------------------------ ** FOR YOUR REFERENCE ** The service address, to which questions about the list itself and requests to be added to or deleted from it should be directed, is: Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.development) via: Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU Linux may be obtained via one of these FTP sites: nic.funet.fi pub/OS/Linux tsx-11.mit.edu pub/linux sunsite.unc.edu pub/Linux End of Linux-Development Digest ******************************