Anybody know anything about libusb? It's giving me grief (again).
As a standalone, the code works fine. As a .device, usb_find_devices never returns (I think it's getting stuck in a loop)
I got some debug out of libusb, and the devices are being found: Quote:
Setting debugging level to 9 (on) usb_os_find_busses: Found usb0 usb_os_find_devices: Found 5fe54790 on usb0 usb_os_find_devices: Found 5fe54b50 on usb0 usb_os_find_devices: Found 5fcda380 on usb0 usb_os_find_devices: Found 5fcda540 on usb0 usb_os_find_devices: Found 5fe546d0 on usb0 usb_os_find_devices: Found 5fcda1c0 on usb0 usb_os_find_devices: Found 5fe54610 on usb0 usb_os_find_devices: Found 5fe54d50 on usb0 usb_os_find_devices: Found 57961280 on usb0 usb_os_find_devices: Found 579612c0 on usb0
libusb must be working, so I haven't done anything completely stupid.
It looks like libusb.library has a _manager_Init function which does all the setup (loadng newlib.library etc). I'm not getting any debug out of this to say it has been called.
I thought the OS was supposed to call this, although I'm not sure, as usually that sort of setup is in the Open or Obtain functions.
edit: oh, wait, that's the "manager" interface. somewhat confused now. I'll try obtaining it regardless and see if anything interesting happens.
edit2: opening the "manager" interface makes no difference, BUT if I disconnect the printer it stops the device getting stuck.
edit3: Hmm, if I run dot4print and then try to use my .device, I don't get the freeze. There's definitely something that is getting initialised by the command line tool that I'm missing in the .device. In the meantime, I've created a little init command which is an adequate workaround for now.
Edited by Chris on 2013/2/23 11:55:06 Edited by Chris on 2013/2/23 11:59:59 Edited by Chris on 2013/2/23 12:25:30 Edited by Chris on 2013/2/23 12:43:46
OK, thanks. I don't think the problem is libusb, I think it is my ineptitude with writing .devices. I'm using a stripped-down lpr.device as a template, and have never written a .device before so don't really know what I'm doing.
I have a mostly-working port of libhpmud (supports Dot4 protocol on HP printers, amongst other things), I just need to get a sequence of six commands called from it in UnitOpen/CMD_WRITE/UnitClose (I'm not entirely sure whether printer.device opens and closes the unit around each job, but I assume it does).
Quote:
char uri[100]; int bytes = 0; int ret; HPMUD_DEVICE dd; HPMUD_CHANNEL cd; /* Open unit */ ret = hpmud_make_usb_serial_uri(serial, &uri, 100, &bytes); if(ret == HPMUD_R_OK) { ret = hpmud_open_device(uri, HPMUD_DOT4_MODE, &dd); if(ret == HPMUD_R_OK) { ret = hpmud_open_channel(dd, HPMUD_S_PRINT_CHANNEL, &cd); if(ret == HPMUD_R_OK) { /* CMD_WRITE */ ret = hpmud_write_channel(dd, cd, buf, size, 60, &bytes); if(ret == HPMUD_R_OK) { // io_Actual = bytes } } /* Close unit */ ret = hpmud_close_channel(dd, cd); } ret = hpmud_close_device(dd); }
That's literally it! The serial number comes out of a config file, and is the only bit which reliably works.
I can provide my libhpmud port if anybody wants to have a crack at it? I'm geting nowhere here.
Maybe I'm mixing up something here ('cos I only use network based printing - PCL/PS): What's the difference between this Dot4 driver* and your fresh upload?
cha05e90 wrote: Maybe I'm mixing up something here ('cos I only use network based printing - PCL/PS): What's the difference between this Dot4 driver* and your fresh upload?
That Dot4 driver is a proper .device, however it doesn't work for me and was never completed.
Mine is a print spooler device, which just chucks the printer.device's output into a spool directory. It then has a commodity which grabs the data from there and chucks it to the printer - either via a device such as PAR: or using built-in Dot4 printing. The Dot4 support on this does work for me, properly, in all cases that I've tried (bar the annoying habit it has of losing or not communicating with the printer when printing starts).
The advantage of the dot4.device is that it is the standard OS4 way of doing things and it is simple to install. The advantage of my approach is that you get a print spooler for free (and you can use it as that and ignore the Dot4 stuff if you want). The disadvantage is it has an extra component to install/run.
I've taken a completely different approach: * ipp.device (Internet Printing Protocol driver - I've had limited success with LPR, but this thing seems rock solid) * A Linux netbook being deployed as a print server
Set the printer driver in OS4 to PostScript, et voila! I don't even need a native OS4 driver for my printer (although the LJ4 one I'd been using previously was perfectly good).
I'm intending to deploy a Raspberry Pi as a permanent print server, and maybe a scanner server too. Problem permanently fixed.
I've taken a completely different approach: * ipp.device (Internet Printing Protocol driver - I've had limited success with LPR, but this thing seems rock solid) * A Linux netbook being deployed as a print server
Set the printer driver in OS4 to PostScript, et voila! I don't even need a native OS4 driver for my printer (although the LJ4 one I'd been using previously was perfectly good).
I'm intending to deploy a Raspberry Pi as a permanent print server, and maybe a scanner server too. Problem permanently fixed.
I have cumulating problems with lpr myself (cumulating after more OS updates roll in) as it seems the device gets more and more unstable.
Where can i get that ipp.device (i take it it's working in AmigaOS4?) Could you refrain the steps you took to make it work? I too would like to put the lpr to rest.
Using a printer with it's own IP through a router here.