# HPLIP HP PSC 1510 ink jet printing trouble with ver 2.7.x

## captwiggum

I've emerged 10 times over the past six months or thereabouts. net-print/hplip 1.7.x worked fine. The ebuilds 1.7.x are gone, so I can not go backwards. I would rather figure out the problem with 2.7.x. I've read all the related posts here, and on HP's preferred forum for HPLIP at launchpad.net.  I have been stepping up with each new 2.7 ebuild to see if it fixes my problem. The latest I've tried is  net-print/hplip-2.7.12-r1.

In summary, the hplip build is clean, the USB device is wide open, mode 666, hp-check is perfect with no errors nor warnings, I know the hardware/cables/printer are good because it was working fine with 1.7. hp-toolbox show the devices, and reads the ink levels, but printing from hp-toolbox, cups, and other apps just queues up the jobs, and the below error appears in the log. Also scanning on the device still works with 2.7.x, so the device is recognized and communications with the device is possible. The crux of the printing matter is this error from /var/log/messages:

Jan 13 19:59:58 lisa PSC_1500_series?serial=MY647C30Y104GG: io/hpmud/musb.c 135: unable get_string_descriptor -1: Operation not permitted

Jan 13 19:59:58 lisa PSC_1500_series?serial=MY647C30Y104GG: io/hpmud/musb.c 603: invalid product id string ret=-1

Jan 13 19:59:58 lisa PSC_1500_series?serial=MY647C30Y104GG: io/hpmud/musb.c 1057: unable to open hp:/usb/PSC_1500_series?serial=MY647C30Y104GG

Jan 13 19:59:58 lisa PSC_1500_series?serial=MY647C30Y104GG: prnt/backend/hp.c 625: INFO: open device failed; will retry in 30 seconds...

I think there is a little k'winky'dink in the ebuild that over looks something. I have all details on my launchpad post: https://answers.launchpad.net/hplip/+question/22114

Any help much appreciated.

----------

## kimmie

If your kernel isn't recent, you could try upgrading it. Seeing as that's where the -EPERM (-1) is coming from. I know it's a long shot, but after reading your other post, that's all I could think of.

----------

## captwiggum

Thanks for the thought. I keep up with the kernels. I use vanilla kernels rather than the Gentoo sources. The problem has persisted through several kernels, including 2.6.20, 2.6.21, 2.6.23.1, and I'm now on 2.6.23.12.

----------

## kimmie

Ok, here's another thing, you say permissions are 666, looking at /dev/bus/usb/002

```
1) In response to one suggestion, I have tweaked my udev rules to make the dev mod 666:

root@lisa~# lsusb

Bus 002 Device 003: ID 03f0:4c11 Hewlett-Packard

root@lisa~# dirl /dev/bus/usb/002

crw-rw-rw- 1 root lp 189, 130 Jan 13 20:41 003

This did not fix the problem
```

But HP-Setup is actually checking /dev/bus/usb/002/004, and it's reporting 664.

```
HP Device 0x4c11 at 002:004:

    Device URI: hp:/usb/PSC_1500_series?serial=MY647C30Y104GG

    Device node: /dev/bus/usb/002/004

    Mode: 0664
```

Maybe that points to something? What happens if you manually chmod /dev/bus/usb/002/004?

----------

## captwiggum

Thanks for the good eye on the hp-check output. I went back and checked, and those posts were cut-n-pasted from several different times and tests, thus the differing usb device id's. I just checked, and hp-check is looking at the correct device, and it is mode 666. The hplip ebuild maintainer instructed me to open a bug. We'll see what comes of it. https://bugs.gentoo.org/show_bug.cgi?id=207981

----------

## captwiggum

It works as USB backend! In other words, this works (setup with cups):

HP_PSC_1500_series_USB_1

Description: HP PSC 1500 series

Location: Local Printer

Make and Model: HP PSC 1510 Foomatic/hpijs (recommended)

Printer State: idle, accepting jobs, published.

Device URI: usb://HP/PSC%201500%20series?serial=MY647C30Y104GG

And this does NOT work (setup either with cups or hp-toolbox):

PSC_1500

Description: HP Ink Jet

Location: John's Desk

Make and Model: HP PSC 1500 Foomatic/hpijs (recommended)

Printer State: idle, accepting jobs, published.

Device URI: hp:/usb/PSC_1500_series?serial=MY647C30Y104GG

I had read that many users used this solution, and I had previously tried this by changing the device in cupsd.conf (and restarting cups of course). But at that time it did not fix it. I don't understand. This time I added the usb backend via cups, as you suggested, and it works. 

Now, more interesting...

I left the previous hp:/ printer in tact, so I have two printers defined for same device, one using hp:/ (hplip) backend, and one using cups usb backend (non-hplip). Now, hp-toolbox reads ink levels from the hp:/ printer, but can not print to it. Also, once anything accesses the hp:/ printer, such as hp-toolbox or a print attempt to the hp:/ printer, then the previously working usb backend printer no longer works, with cups saying "device not connected."

To fix this state I did this:

-I deleted both printers. 

-killed /usr/share/hplip/hpssd.py (which was started by hp-toolbox, in trying to access the hp:/ device)

-stopped cups

-turned off the printer

-start cups

-start the printer

-wait a minute for the usb device to be recognized

-in cups, click "Administration", you will see two "news printers found", one as hplip backend, one as usb backend.

-Added the usb backend printer again

It works now! So in other words, I can print, but can not check ink levels nor use hp-toolbox at all. Any ideas what's up with this?

----------

## henningml

As a sidenote, I've had exactly the same problem, and did exactly as you describe here, and still no go.

Then I remembered someone mentioning group and access-level on the usb-node, and I did a "chmod 777 /dev/usb/lp0" and all of a sudden it all works.

Hence, the sollution might be a combination of installing as an usb URI and fixing the wrong access-mask set on the usb-node either by udev or cups.

----------

## jstead1

I had several different indications of problems trying to print or scan with my usb printer (hp psc 1310)

First I couldn't scan (don't know if I couldn't print, I don't print that often)

I tried scanimage -L as a user, no scanner

tried scanimage -L as root, got a scanner

Did a little digging and found /etc/udev/rules.d/99-libsane.rules and added

```
# Hewlett-Packard PSC 1310

ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="3f11", MODE="660", GROUP="scanner"
```

That fixed my scanning problem.

The next day, my daughter is trying to print nothing comes out.

CUPS has varying messages, depending on how I install the printer ranging from it's not ready to it's disconnected or nothing at all, just no printing.

I changed the line in /etc/udev/rules.d/99-libsane.rules to

```
# Hewlett-Packard PSC 1310

ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="3f11", MODE="777", GROUP="scanner"
```

the change is in the permissions from 660 to 777

Printing works, scanning works, everything is good, except that this should really be fixed for everyone, but I really don't understand enough about udev, permissions, and cups, to write a bug report that would be of any use.

Further mucking around in /etc/udev/rules.d/70-hpmud.rules, I find 

```
# Check for AiO products (0x03f0xx11).

ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="??11", GROUP="lp"
```

This would set the group of my printer/scanner to lp, though I change it to scanner once I modified 99-libsane.rules

The problem may have been that I changed the group on the printer/scanner from lp to scanner

Although all my users are in the lp and scanner group, maybe the "user" (maybe it's lp, I don't know what user cups uses to print) trying to print isn't in the scanning group, so with 660 permissions and the group on the printer/scanner, set to scanner, , it doesn't work.

Previously, when I tried to scan with the device in the lp group, the scanning user couldn't do it.  I don't understand why this would be since the user was in the lp group.  It seems, that if the model that is sought after, that only people in the lp group should be able to print, and only people in the scanner group can scan, that a printer/scanner device should be owned by both groups, but I don't think that is possible.

So my solution works for me, since I don't care who prints, or who scans, but some people might.

Anyone understand enough about this to know if this is a bug, or if it is to write a coherent bug report?

----------

