Oliver Neukum wrote: > > > You are right. Unfortunately they _have_ accepted it. > > > Can we now be confident that no other printers will implement it > > > and put a workaround into printer.c ? > > > > While I can't comment on non-HP printers or future HP products, I can say > > that it's not safe to assume that none of them will also do the same thing. > > Therefore, it's best to go with my more open-ended solution for printer.c, > > and leave it to me to handle the rest in user mode for HP MFPs. (Did I > > understand and answer your question correctly?) > > And what do we do if somebody makes a printer that accepts only 1284.4 ?
If the peripheral only advertises 7/1/3, then printer.c has no choice but to bind to it, which is the behaviour with the existing version as well as my modified version. This is the case today with the HP OfficeJet G series and K series MFPs (they're 7/1/3-only). Then it's a simple matter for my user-mode 1284.4 driver (ptal-mlcd) to start up and maintain a 1284.4 session. Another daemon (ptal-printd) sets up a named pipe under /dev/ptal-printd/ that takes raw print data (read: "/dev/lp* semantics") and routes it through the 1284.4 protocol stack on to the peripheral. David _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
