Re: ulpt question
On 2014/01/15 23:07, patrick keshishian wrote: Setting that aside, it doesn't look like I can use ulpt device to write a dedicated driver for this printer. Is this correct? Do I need to fudge the kernel to not attach this device to ulpt but instead as ugen? Is there a better way? I rather not diverge from GENERIC. There's some support in libusb for accessing non-ugen(4) devices, specifically control transfers and synchronous reads. But if this code is to do some necessary initialization for a particular printer that can be matched by IDs, adding support right in the ulpt(4) driver would probably be better, there's already some framework for matching things by ID for printers which need firmware to be uploaded, so you could possibly hook into this.
Re: ulpt question
On Thu, Jan 16, 2014 at 09:02:21AM +, Stuart Henderson wrote: But if this code is to do some necessary initialization for a particular printer that can be matched by IDs, adding support right in the ulpt(4) driver would probably be better, Agreed. there's already some framework for matching things by ID for printers which need firmware to be uploaded, so you could possibly hook into this. In particular, the ulpt_ucode_loader_hp() function writes a firmware image as raw bytes to the printer. Re-using code from this function you should be able to write arbitrary data to the printer. Fun fact: The implementation of ulpt_ucode_loader_hp() was based on code from ugen_do_write(), i.e. ulpt behaves like ugen while it uploads firmware to HP printers.
Re: ulpt question
On Wed, Jan 15, 2014 at 11:41:05PM -0800, Philip Guenther wrote: On Wed, Jan 15, 2014 at 11:07 PM, patrick keshishian pkesh...@gmail.com wrote: Now here, I need an expert's help. I must be looking at this upside down or sideways, because I don't see where ulpt_do_write() is called, well, it is called from ulptwrite() (ulpt.c), but I can't find who, or where it gets called from. Need a pointer here please. ulptwrite is referenced via the d_write member for ulpt in the cdevsw array, and is thus invoked via spec_write() in kern/spec_vnops.c. (How does it get into cdevsw? Look for ulpt in sys/conf.h and in arch/*/*/conf.c; the latter uses the macros defined in the former.) Thanks for the pointer! That was a fun exercise! :-) On Thu, Jan 16, 2014 at 09:02:21AM +, Stuart Henderson wrote: On 2014/01/15 23:07, patrick keshishian wrote: Setting that aside, it doesn't look like I can use ulpt device to write a dedicated driver for this printer. Is this correct? Do I need to fudge the kernel to not attach this device to ulpt but instead as ugen? Is there a better way? I rather not diverge from GENERIC. There's some support in libusb for accessing non-ugen(4) devices, specifically control transfers and synchronous reads. I'll take a look a libusb. But if this code is to do some necessary initialization for a particular printer that can be matched by IDs, adding support right in the ulpt(4) driver would probably be better, there's already some framework for matching things by ID for printers which need firmware to be uploaded, so you could possibly hook into this. I did notice the HP firmware load routines, also mentioned by Stefan Sperling. On Thu, Jan 16, 2014 at 10:35:05AM +0100, Stefan Sperling wrote: there's already some framework for matching things by ID for printers which need firmware to be uploaded, so you could possibly hook into this. In particular, the ulpt_ucode_loader_hp() function writes a firmware image as raw bytes to the printer. Re-using code from this function you should be able to write arbitrary data to the printer. Fun fact: The implementation of ulpt_ucode_loader_hp() was based on code from ugen_do_write(), i.e. ulpt behaves like ugen while it uploads firmware to HP printers. I'll look more closely at those again. Thank you Philip, Stuart and Stefan for quick responses! --patrick
ulpt question
Hello, $ sysctl kern.version kern.version=OpenBSD 5.4-current (GENERIC.MP) #222: Fri Dec 27 22:33:50 MST 2013 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP I just got this USB printer and I'm trying to write some code to directly control it. It attaches as ulpt, which is good. Baby steps for me: write a very basic C program that opens the appropriate /dev/ulpt* device, and write the initialize command for this printer. Things Look OK. Next write Status Information Request command sequence. write(2) succeeds. I try to read(2) the response back, but it fails with ENODEV (Operation not supported). The status is actually printed in /var/log/messages. Looking at sys/dev/usb/ultp.c, i see this done in ulpt_statusmsg() which is called in ulpt_do_write(). Now here, I need an expert's help. I must be looking at this upside down or sideways, because I don't see where ulpt_do_write() is called, well, it is called from ulptwrite() (ulpt.c), but I can't find who, or where it gets called from. Need a pointer here please. $ pwd /usr/src/sys/dev/usb $ grep -r ulptwrite ../.. ../../dev/usb/ulpt.c: DPRINTF((ulptwrite\n)); ../../dev/usb/ulpt.c: DPRINTFN(1, (ulptwrite: transfer %d bytes\n, n)); ../../dev/usb/ulpt.c: DPRINTF((ulptwrite: error=%d\n, err)); ../../dev/usb/ulpt.c:ulptwrite(dev_t dev, struct uio *uio, int flags) $ grep -r ulpt_do_write ../.. ../../dev/usb/ulpt.c:int ulpt_do_write(struct ulpt_softc *, struct uio *uio, int); ../../dev/usb/ulpt.c:ulpt_do_write(struct ulpt_softc *sc, struct uio *uio, int flags) ../../dev/usb/ulpt.c: error = ulpt_do_write(sc, uio, flags); As for the ENODEV on read(2), I guess I misunderstood what is meant by bi-directional: Jan 15 20:55:28 puter /bsd: ulpt0: using bi-directional mode bi-directional does not mean *I* get to read and write to this device. Setting that aside, it doesn't look like I can use ulpt device to write a dedicated driver for this printer. Is this correct? Do I need to fudge the kernel to not attach this device to ulpt but instead as ugen? Is there a better way? I rather not diverge from GENERIC. Requesting any and all advice. --patrick p.s., if this belongs to misc@ I'll happily move it there.
Re: ulpt question
On Wed, Jan 15, 2014 at 11:07 PM, patrick keshishian pkesh...@gmail.com wrote: ... Now here, I need an expert's help. I must be looking at this upside down or sideways, because I don't see where ulpt_do_write() is called, well, it is called from ulptwrite() (ulpt.c), but I can't find who, or where it gets called from. Need a pointer here please. ulptwrite is referenced via the d_write member for ulpt in the cdevsw array, and is thus invoked via spec_write() in kern/spec_vnops.c. (How does it get into cdevsw? Look for ulpt in sys/conf.h and in arch/*/*/conf.c; the latter uses the macros defined in the former.) Your other questions are out of my league; sorry. Philip Guenther
