Comment 7 for bug 113640

I have some more information and a solution to the problem; well, at least a work-around and a hypothesis about the underlying bug. My Brother HL-1440 works perfectly (so far) when connected with the parallel port instead of USB. That's a cheap alternative compared with buying a different printer. I checked the Brother-USA web site regarding the models that have been reported in bug 113640 and the related (duplicate) bug 35638. These models all come with both USB and parallel connections. The printer senses which cable is plugged in. Until the USB problem is solved, these models and perhaps all the Brother HL series of printers should be connected by parallel port or ethernet interface if available in that model, rather than USB.

I tried some other experiments to help tunnel in on the nature of the USB "invisibility" problem I've described. I don't think its a bug in the kernel, but rather a bug in the way that the printer driver or CUPS interprets the printer status data it receives from the printer when probed on the USB port. As data supporting this hunch, consider this. I plugged in a different USB printer to the same USB cable instead of the Brother printer. This test printer was a printer/scanner Lexmark (model X2250). I did not install a driver yet. I just plugged it in, turned it on, and booted into Ubuntu 7.04. When I was logged in, I executed the "watch 'lpinfo -v'" command and watched. The printer was seen as a local usb printer with the correct model name. It was solidly visible, never going invisible from the lpinfo output. So what's different about the Brother printer? The Brother is a laser printer and the Lexmark X2250 is inkjet. Lasers have a fuser roller, which is heated by a heating element inside the roller so that the roller can melt the dry ink powder into the paper (fusing it to the paper), but inkjet printers do not. The heating element is temperature regulated by the printer so it maintains the correct fusing temperature. To do this, it turns the heater on and off as needed. I have a strong suspicion that the status data reported on the USB port includes some indication whether the fuser is at the correct temperature or not, or perhaps whether current is flowing in the heater element or not. This would be useful information for a diagnostic program that figures out whether the printer is functioning correctly, so it's possible that Brother provided this status data in the USB status dialog, for diagnostic purposes. If that's true, perhaps the Linux printer driver developers have mis-interpreted the status data coming in on the USB port, using the fuser status information as a printer presence indication (or perhaps as a printer ready or not ready indication). There probably is a different bit of data in the status message that is the correct indicator of the printer-ready state, one which corresponds to the "ready" LED on the printer itself. If I am correct about this, the behavior of cycling between visible and invisible would be explained -- when the fuser cools down and needs to be heated, the fuser status bit would be interpreted by the driver as printer not present or not ready, but when the fuser is hot enough and the fuser status bit changes, then the driver would see the printer as ready. Most likely this status bit is not present on the parallel cable, which typically uses one of the pins to indicate printer ready status and there Brother must be using the correct status. The true ready status or presence status is surely somewhere in the USB status message, but not where the driver is looking for it. Please pass this information to the appropriate printer driver developer somewhere.

Another bug I've noticed during this testing should be reported (if not already reported yet -- I haven't checked). The Printers window (brought up by the Printing menu item) shows icons for the printers and indicates "Ready" under them. When I unplugged the printer from the USB cable, or when I added a non-existant printer to the Printers, or when I turned off the parallel printer, the indication remained "ready". Even when the printer disappears from the lpinfo output, the Printers window shows it as 'ready". That's not right.