LinuxQuestions.org - Device Node Assignment at Boot, Parallel Printer via USB adapter

- Linux - Hardware (https://www.linuxquestions.org/questions/linux-hardware-18/)

- - Device Node Assignment at Boot, Parallel Printer via USB adapter (https://www.linuxquestions.org/questions/linux-hardware-18/device-node-assignment-at-boot-parallel-printer-via-usb-adapter-879075/)

Device Node Assignment at Boot, Parallel Printer via USB adapter

I have a printer that is not getting a device node assigned at boot.

The printer is attached with a USB to Parallel (IEEE-1284) adapter cable. When I plug in the usb cable when the machine is running, the printer is assigned the device node: /dev/usb/lp0

I am guessing that during startup, the printer device is not detected since it is plugged in over an adapter cable which may be considered a device in itself?

This is for a retail store, and we rely on the printer to pop the cash drawer open, so it kinda has to work without a "secret handshake" :)

Unfortunately our workstations do not have Parallel ports. I would be happy to share terminal output, udev info, I'll write you a poem… but I could sure use a helping hand- I'm stumped!

If you do:

dmesg | grep lp

or

dmesg | grep usb

Does the kernel report finding anything relevant? (Like maybe the adapter?)

I have a usb-to-parallel adapter, and it's always just worked as a printer -- the adapter itself isn't detected as a separate device or anything.

I'll check the output of dmesg as soon as I am back in the store! I saved the `lsusb` output below, which is what started making me think the cable was considered a device, because of the name of the device. The device IS present in `lsusb` output after reboot, but the device node is not assigned until after unplugging and re-plugging the cable. Powering the machine off and on has no effect. Weird huh?

Code:

fingerprints@skylark:~$ lsusb

Bus 005 Device 003: ID 093a:2510 Pixart Imaging, Inc. Hama Optical Mouse

Bus 005 Device 002: ID 067b:2305 Prolific Technology, Inc. PL2305 Parallel Port

Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Bus 004 Device 002: ID 04ca:004b Lite-On Technology Corp. 

Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Bus 001 Device 003: ID 0781:5530 SanDisk Corp. 

Bus 001 Device 002: ID 04f2:b18b Chicony Electronics Co., Ltd 

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Hmmm, it does mention a printer once, and it's vid & pid match the id of the device highlighted blue in the lsusb output I posted above... Do you think that tells us anything?

using `dmesg | grep lp` outputs a few hundred entries of the following line

Code:

[32858.320354] usb 5-1: usbfs: interface 0 claimed by usblp while 'usb' sets config #1

I wonder if that corresponds to the number of times I've unplugged it and plugged it back in :)
and these entries appear consecutively in the middle, looks like is referring to the printer:

Code:

[31717.820323] usblp 5-1:1.0: no reset_resume for driver usblp?

[31717.820503] usblp0: removed

[31723.389669] usblp0: USB Bidirectional printer dev 2 if 0 alt 1 proto 2 vid 0x067B pid 0x2305

[31723.389923] Modules linked in: binfmt_misc ppdev snd_hda_codec_realtek fbcon tileblit font bitblit softcursor vga16fb vgastate snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq joydev snd_timer snd_seq_device i915 usbhid snd drm_kms_helper uvcvideo videodev hid usblp v4l1_compat psmouse serio_raw drm intel_agp soundcore atl1c rt3090sta(C) i2c_algo_bit video output snd_page_alloc agpgart lp parport

If this tells you anything else I could check on, I would appreciate the advice! Thanks a bunch for responding in the first place.

Perhaps the procedure here:

https://wiki.archlinux.org/index.php...klisting_usblp

would be useful?

It sounds like there are two different conventions for talking to the printer: The old usblp driver way and the newer libusb way. But the two methods fight with each other, so the usblp modules have to be disabled so the libusb driver can talk to the printer.

Might have to look at speeds of services starting up. Put in a huge delay for printing. It seems (maybe) that it has to wait until the usb is hotplugged.