* USB-Printer status flags question @ 2003-01-12 10:17 Alexander Puchmayr 2003-01-13 4:30 ` Randy.Dunlap 0 siblings, 1 reply; 4+ messages in thread From: Alexander Puchmayr @ 2003-01-12 10:17 UTC (permalink / raw) To: linux-kernel After looking at cups (1.1.18) backend/usb.c and the kernel's (2.4.19-gentoo-r10) drivers/usb/printer.c I've found some different interpretations of the LP_* flags from linux/lp.h While the kernel seems to use the 8255 status port definitions, which use (amongst others) the flags, #define LP_PSELECD 0x10 /* unchanged input, active high */ #define LP_PERRORP 0x08 /* unchanged input, active low */ the same bits are defined by POSIX guidelines a few lines above in linux/lp.h: #define LP_OFFL 0x0008 #define LP_NOPA 0x0010 Obviously, this leads the cups usb-backend to incorrectly report an empty media tray when the printer is online, idle and has enough paper. This doesn't seem to be something serious, its just a wrong message in cups log-file. Greetings Alex PS: Since two different specifications are mixed up, this problem could also be a kernel problem. -- Alexander Puchmayr Systemadministrator for Theoretical Physics University Linz, Austria e-mail: alexander.puchmayr@jku.at Altenbergerstrasse 69 phone: +43/732/2468-8633 A-4040 Linz-Auhof FAX: +43/732/2468-8585 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: USB-Printer status flags question 2003-01-12 10:17 USB-Printer status flags question Alexander Puchmayr @ 2003-01-13 4:30 ` Randy.Dunlap 2003-01-13 8:09 ` Alexander Puchmayr 0 siblings, 1 reply; 4+ messages in thread From: Randy.Dunlap @ 2003-01-13 4:30 UTC (permalink / raw) To: Alexander Puchmayr; +Cc: linux-kernel Hi Alex, On Sun, 12 Jan 2003, Alexander Puchmayr wrote: | After looking at cups (1.1.18) backend/usb.c and the kernel's | (2.4.19-gentoo-r10) drivers/usb/printer.c I've found some different | interpretations of the LP_* flags from linux/lp.h | | While the kernel seems to use the 8255 status port definitions, which use | (amongst others) the flags, | | #define LP_PSELECD 0x10 /* unchanged input, active high */ | #define LP_PERRORP 0x08 /* unchanged input, active low */ | | the same bits are defined by POSIX guidelines a few lines above in | linux/lp.h: | | #define LP_OFFL 0x0008 | #define LP_NOPA 0x0010 Does anyone know where I can find these POSIX guidelines? I tried SUSv3 but didn't see them there. I'm not sure if the comment about POSIX guidelines is referring only to the LP* and lp* namespace (prefixes) or to the bit definitions also. Are you saying that there are apps that depend on the POSIX bit definitions? | Obviously, this leads the cups usb-backend to incorrectly report an empty | media tray when the printer is online, idle and has enough paper. | | This doesn't seem to be something serious, its just a wrong message in cups | log-file. The (Linux 2.4.20) kernel drivers/char/lp.c and drivers/usb/printer.c modules use the 8255 parallel port definitions to read/test the status port. This matches the USB printer spec (I'm looking at the USB v1.1 printer spec). USB & parport then return that 8-bit value to userspace via an ioctl (LPGETSTATUS). Is CUPS using a different ioctl, possibly LPGETFLAGS? | PS: Since two different specifications are mixed up, this problem could also | be a kernel problem. Um, it would have been a good thing if a "standard" interface were used for this instead of one that just matches some device's registers, as long as the standard interface weren't severe overkill. -- ~Randy ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: USB-Printer status flags question 2003-01-13 4:30 ` Randy.Dunlap @ 2003-01-13 8:09 ` Alexander Puchmayr 2003-01-13 16:34 ` Randy.Dunlap 0 siblings, 1 reply; 4+ messages in thread From: Alexander Puchmayr @ 2003-01-13 8:09 UTC (permalink / raw) To: Randy.Dunlap; +Cc: linux-kernel On Monday 13 January 2003 05:30, you wrote: > Hi Alex, > > On Sun, 12 Jan 2003, Alexander Puchmayr wrote: > | After looking at cups (1.1.18) backend/usb.c and the kernel's > | (2.4.19-gentoo-r10) drivers/usb/printer.c I've found some different > | interpretations of the LP_* flags from linux/lp.h > | > | While the kernel seems to use the 8255 status port definitions, which > | use (amongst others) the flags, > | > | #define LP_PSELECD 0x10 /* unchanged input, active high */ > | #define LP_PERRORP 0x08 /* unchanged input, active low */ > | > | the same bits are defined by POSIX guidelines a few lines above in > | linux/lp.h: > | > | #define LP_OFFL 0x0008 > | #define LP_NOPA 0x0010 > > Does anyone know where I can find these POSIX guidelines? > I tried SUSv3 but didn't see them there. > I'm not sure if the comment about POSIX guidelines is referring > only to the LP* and lp* namespace (prefixes) or to the bit > definitions also. > > Are you saying that there are apps that depend on the POSIX bit > definitions? > Get cups (I'm using 1.1.18), see backend/usb.c and have a look at the piece of code #ifdef __linux /* * Show the printer status before we send the file; normally, we'd * do this while we write data to the printer, however at least some * Linux kernels have buggy USB drivers which don't like to be * queried while sending data to the printer... */ if (ioctl(fd, LPGETSTATUS, &status) == 0) { fprintf(stderr, "DEBUG: LPGETSTATUS returned a port status of %02X...\n", status); if (status & LP_NOPA) fputs("WARNING: Media tray empty!\n", stderr); else if (status & LP_ERR) fputs("WARNING: Printer fault!\n", stderr); else if (status & LP_OFFL) fputs("WARNING: Printer off-line.\n", stderr); } #endif /* __linux */ LP_NOPA, LP_ERR and LP_OFFL are from the POSIX-Part. > | Obviously, this leads the cups usb-backend to incorrectly report an > | empty media tray when the printer is online, idle and has enough paper. > | > | This doesn't seem to be something serious, its just a wrong message in > | cups log-file. > > The (Linux 2.4.20) kernel drivers/char/lp.c and drivers/usb/printer.c > modules use the 8255 parallel port definitions to read/test the status > port. This matches the USB printer spec (I'm looking at the USB > v1.1 printer spec). > USB & parport then return that 8-bit value to userspace via an > ioctl (LPGETSTATUS). Is CUPS using a different ioctl, possibly > LPGETFLAGS? > See the code piece above - its using LPGETSTATUS > | PS: Since two different specifications are mixed up, this problem could > | also be a kernel problem. > > Um, it would have been a good thing if a "standard" interface were used > for this instead of one that just matches some device's registers, > as long as the standard interface weren't severe overkill. I agree. Greetings Alex ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: USB-Printer status flags question 2003-01-13 8:09 ` Alexander Puchmayr @ 2003-01-13 16:34 ` Randy.Dunlap 0 siblings, 0 replies; 4+ messages in thread From: Randy.Dunlap @ 2003-01-13 16:34 UTC (permalink / raw) To: Alexander Puchmayr; +Cc: linux-kernel On Mon, 13 Jan 2003, Alexander Puchmayr wrote: | On Monday 13 January 2003 05:30, you wrote: | > Hi Alex, | > | > On Sun, 12 Jan 2003, Alexander Puchmayr wrote: | > | After looking at cups (1.1.18) backend/usb.c and the kernel's | > | (2.4.19-gentoo-r10) drivers/usb/printer.c I've found some different | > | interpretations of the LP_* flags from linux/lp.h | > | | > | While the kernel seems to use the 8255 status port definitions, which | > | use (amongst others) the flags, | > | | > | #define LP_PSELECD 0x10 /* unchanged input, active high */ | > | #define LP_PERRORP 0x08 /* unchanged input, active low */ | > | | > | the same bits are defined by POSIX guidelines a few lines above in | > | linux/lp.h: | > | | > | #define LP_OFFL 0x0008 | > | #define LP_NOPA 0x0010 | > | > Does anyone know where I can find these POSIX guidelines? | > I tried SUSv3 but didn't see them there. | > I'm not sure if the comment about POSIX guidelines is referring | > only to the LP* and lp* namespace (prefixes) or to the bit | > definitions also. | > | > Are you saying that there are apps that depend on the POSIX bit | > definitions? | > | Get cups (I'm using 1.1.18), see backend/usb.c and have a look at the piece | of code Well, thanks for posting it... | #ifdef __linux | /* | * Show the printer status before we send the file; normally, we'd | * do this while we write data to the printer, however at least some | * Linux kernels have buggy USB drivers which don't like to be | * queried while sending data to the printer... | */ | | if (ioctl(fd, LPGETSTATUS, &status) == 0) | { | fprintf(stderr, "DEBUG: LPGETSTATUS returned a port status of | %02X...\n", status); | | if (status & LP_NOPA) | fputs("WARNING: Media tray empty!\n", stderr); | else if (status & LP_ERR) | fputs("WARNING: Printer fault!\n", stderr); | else if (status & LP_OFFL) | fputs("WARNING: Printer off-line.\n", stderr); | } | #endif /* __linux */ | | LP_NOPA, LP_ERR and LP_OFFL are from the POSIX-Part. and they are the wrong bits to be testing. LPGETSTATUS doesn't return POSIX-bits for LP status AFAI can see, in drivers/char/lp.c or in drivers/usb/printer.c. It returns 8255-style status bits. I wouldn't be surprised to find some part of the kernel returning POSIX LP-status bits and another part returning 8255-status bits, but I don't see that here. I see them returning only 8255-status bits and cups looking for the other. Is there some reason that cups isn't just testing for 8255-style status bits instead of the POSIX style? Go ahead, enlighten me. | > | Obviously, this leads the cups usb-backend to incorrectly report an | > | empty media tray when the printer is online, idle and has enough paper. | > | | > | This doesn't seem to be something serious, its just a wrong message in | > | cups log-file. | > | > The (Linux 2.4.20) kernel drivers/char/lp.c and drivers/usb/printer.c | > modules use the 8255 parallel port definitions to read/test the status | > port. This matches the USB printer spec (I'm looking at the USB | > v1.1 printer spec). | > USB & parport then return that 8-bit value to userspace via an | > ioctl (LPGETSTATUS). Is CUPS using a different ioctl, possibly | > LPGETFLAGS? | > | | See the code piece above - its using LPGETSTATUS | | > | PS: Since two different specifications are mixed up, this problem could | > | also be a kernel problem. | > | > Um, it would have been a good thing if a "standard" interface were used | > for this instead of one that just matches some device's registers, | > as long as the standard interface weren't severe overkill. | | I agree. -- ~Randy ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2003-01-13 16:29 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-01-12 10:17 USB-Printer status flags question Alexander Puchmayr 2003-01-13 4:30 ` Randy.Dunlap 2003-01-13 8:09 ` Alexander Puchmayr 2003-01-13 16:34 ` Randy.Dunlap
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®