Tim Waugh wrote:
> On Sat, 19 Feb 2000, Gunther Mayer wrote:
>
> > Highlights:
> > - Support for Winbond Super-IO chips (expandable to other manufacturers)
> > "insmod parport_pc superio=1 irq=auto dma=auto" to autodetect and
> > report it
>
> This is quite neat. I wonder if it's possible to detect it without
> needing 'superio=1'..?
Of course, I just considered poking at these ports (0x3f0, 0x2e,...) too
agressive
to make it standard. The next version will detect some SMSC chips too; this
shows linux doesn`t detect EPP-mode on37c669 when operated as "ECP+EPP"
(it is detected correctly when set to "EPP" in the BIOS).
>
>
> > - Provide more human-readable output on assorted places, to
> > assist further progress on debugging and features
> > - Correct very minor glitches concerning ECP/ISA standard obeyance
> > (major glitches not yet addressed :-)
>
> Can you send these to me as separate patches please?
I will rearrange the patch...
>
>
> > Other Changes
> > - Print the complete IEEE1284 Device ID (unmangled) and
> > be merciful to devices that didn't get everything right
>
> I don't think this is really necessary -- it's already available in /proc
> anyway. I quite like the pretty printing.
It`s just the pretty-printed Device ID in
/proc/sys/dev/parport/parport0/autoprobe !
I just want to KNOW the raw Device ID (the standard even says it must be
ASCII).
>
>
> > The idea is switching DPRINTK off as done in this patch.
>
> I'd like to keep that on a while longer.
OK. I plan to add more DPRINTKs to find my ECP+LJ1100A crash.
>
>
> > - The "lp" driver registers itself to "/proc/driver/lp" and gives some
> > fancy human-readable output. Here I can see how slow my printer is :-)
>
> Let's be careful about adding more file formats! (There's always tunelp
> for this sort of thing..)
The advantage of /proc is it's easy availability, no need to hunt for the
newest tools...
I'd even like a generic layer at device level that counts the reads/writes
for every device!
Every driver should provide information about it's current state
and paramters, so we either have a /proc-entry or a separate tool per
driver...
>
>
> > Actually I wonder if I can use ECP to speak to my printer, that does
> > currently only 20K/sec in SPP mode. A quick hack only hung both linux
> > and the printer completely.
>
> I've wondered about this too, but I don't have a printer that speaks ECP.
Even so it should not hang completely. I will add debugging to see why...
Regards, Gunther
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2b29 : Tue Feb 22 2000 - 16:07:57 EST