Date: Sun, 14 Feb 1999 13:16:11 -0500 (EST) From: Chuck Robey <chuckr@mat.net> To: Nicolas Souchu <nsouch@teaser.fr> Cc: freebsd-current@FreeBSD.ORG Subject: Re: New print interface Message-ID: <Pine.BSF.4.05.9902141309290.340-100000@picnic.mat.net> In-Reply-To: <19990214190015.52233@breizh.prism.uvsq.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 14 Feb 1999, Nicolas Souchu wrote: > >There are a couple of things that have happened that strike me as worthy > >of comment. Here's my relevant dmesg part: > > > >ppc0 at 0x378 irq 7 drq 3 on isa > >ppc0: SMC FDC37C665GT chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode > >ppc0: FIFO with 16/16/15 bytes threshold > >ppb0: IEEE1284 device found /NIBBLE/ECP > >Probing for PnP devices on ppbus0: > >ppbus0: <HEWLETT-PACKARD DESKJET 690C> MLC,PCL,PML > >plip0: <PLIP network interface> on ppbus 0 > >lpt0: <generic printer> on ppbus 0 > >lpt0: Interrupt-driven port > >ppi0: <generic parallel i/o> on ppbus 0 > >lppps0: <Pulse per second Timing Interface> on ppbus 0 > > > >Notice how the ppbus finds and correctly IDs my printer (yea!) but then > >the lpt0 and ppi0 lines find generic ... this is a little odd, isn't it? > >Even if the lpt0 and ppi0 parts are less intelligent, they should share > >info to at least some degree, shouldn't they? > > i/o is generic here. If IO is generic, then printing the type of printer it finds is meaningless, right? It's going to announce "generic" no matter what, then it should stay silent, right? Better to say nothing than to get it wrong every time, especially with the correct info sitting mere lines above, advertising the mistake. > >2nd note ... you said I should use lptcontrol -e. I did that, exactly, > >and it came back to tell me that it had switched me to extended mode > >(which I expected) AND to polled mode (which I neither expected nor > >wanted). The man page says that only one action is taken at a time. I > >was able to switch on the interrupt mode again (which I did want) by > >using the -i switch (advertised correctly on the man page now) but isn't > >this wrong, switching to polled mode like that on entering the -e? > > Hmm, yes. It is interrupt driven tough. Then the lptcontrol command should not announce, when you enter 'lptcontrol -e' that it's setting polled mode (which it did). If it's still in interrupt mode (which is good) then it's fibbing to me, right? > > But, can you print with extended mode set?! I can't cat /dev/lpt0 and get any status. I did the lptcontrol -e, so I *think* I;m in extended mode, and it *does* print. I guess I have to find out what I can buy to play with this further. I would like to have some logic level outputs, so I can do some direct machine control, and doing it via my printer port sounds cool. Know anything like that? Having my computer be my alarm clock would be neat. I have 5 different wakeup times (because of odd class schedules) and that would, in fact, be a real nice win. If true, imagine you use > DMA+FIFO when printing! If not convinced, enable PPC_DEBUG when compiling > i386/isa/ppc.c. OK, experimenting. What about 'cat /dev/lpt0' doing nothing? Am I doing that right? What did you expect me to see, when you asked that? ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9902141309290.340-100000>