On Wed, Jan 15, 2014 at 11:41:05PM -0800, Philip Guenther wrote: > On Wed, Jan 15, 2014 at 11:07 PM, patrick keshishian <[email protected]> > 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 +0000, 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
