Update Jan. 2019: Apologies, this was written with #sdramThingZero - 133MS/s 32-bit Logic Analyzer in-mind, and therefore is *way* overcomplicated for most projects. If you just want to write some outputs (blink LEDs, control a text-LCD, etc.) please check out the link in the comments. You could probably control a 7-segment LED with a little wiring and "echo x > /dev/usb/lp0". Input, however, may be a little more difficult, I don't know.

However, brief note as to the main point, here... the parallel port may've been scanned by linux for attached-devices, which may leave your parallel port in an unknown mode.

This is about checking and changing the parallel port mode. 

(Similar to setting the baud-rate of a serial port.)

--------

So, you've got a USB-to-Parallel adapter that you'd like to use for a project (not a printer)...

(Hey, I'm no expert, here... so take this as the ramblings of a newb):

First: There are Major Limitations... These adapters are *nothing* like the ol' Parallel Port built into old motherboards or on ISA cards... So, don't be getting high-hopes about bit-banging this thing. (There's lots of info about this all 'round the interwebs).

BUT: If your project *can* work within those limitations, then you'll first need to figure out how to set the adapter into the right mode...

So, what're those limitations?

I'm no expert, here, but it seems there are three "modes" these things can work in...

1. Unidirectional
2. EPP/ECP compatible
3. IEEE-1284 compatible

1: Unidirectional -- Might work for your project... If *timing* isn't particularly-sensitive, you should have access to the 8-data-bits as outputs, and 3 control lines as inputs (if I understand correctly)... It could probably be done-ish... but nothing like the level of functionality the ol' ISA cards had.

3. IEEE-1284 -- This guy looks pretty gnarly and basically requires a microcontroller on the "peripheral"-side to handle the protocol. There ain't much to bit-bang with this method, unless, maybe, you're a truly-1337 haxor.

2. EPP/ECP -- This is the one I'm looking at.

So this guy doesn't look *so* complicated. And, in fact, it looks like it might be darn-near exactly the sort of interface I need for #sdramThingZero - 133MS/s 32-bit Logic Analyzer, and really not that much different from, say, the interface on an HD44780 Character-LCD.

The basic idea is to use the Data I/Os bidirectionally. This gets a bit more complicated with the whole USB thing, since you've got to send a request for a certain number of *reads* or *writes*... which means, for *reads*, your peripheral has to be able to respond with acknowledgements... (I think I can get around that with an OR gate, in my case)... and has to set-up the next byte to be transmitted, etc.

Anyways, sidetracked. The point is, when you plug in the USB-parallel adapter, it doesn't look to the computer like merely a parallel port (like a USB-serial adapter looks like nothing more than a serial port)... instead, Linux tries to look for a *printer* connected to that parallel port.

In a high-level sense, it makes sense... it's just another bus; parallel, USB, PCI, SCSI, whatever...

But that means it's got a procedure for looking for attached devices, and when it can't find one, it might just leave your new "parallel port" in a mode you don't want...

So, there're some settings you might want to send your new "parallel port"... but how do you do that when all you've got is /dev/usb/lp0, fopen(), fclose(), fread(), and fwrite()...? Yeah, no... ioctl() is the way to go.

That's, basically, the same thing used for e.g. setting a serial port's baud-rate... you can't do that by just sending some ASCII characters to /dev/ttyUSB0, you have to use ioctl(). 

(or use a utility like stty or setserial, which calls ioctl() as-appropriate. I have yet to find a similar utility for parallel-ports.)

OK, then... But this USB-adapter needs a mode-setting, and with my search-fu there's basically *Zero* documentation on the IOCTL arguments available to USB dongles.

SO, you've gotta look into <Kernel Source>/drivers/usb/class/usblp.c and, sure-nough, there are some IOCTLs listed. Awesome.

Then you'll discover that there's no Header File for usblp... And, again, it seems no one actually uses these IOCTLs, so how do *We* use them?

Yeahp, you gotta copy a bunch of #define's from usblp.c to your own code (rather than #including some standard-ish system header-file). Don't believe me? Take a look at http://hpoj.sourceforge.net/ which is the *only* thing I could find through all of the google (and actually didn't find it through there) that used these IOCTLs... And, lo-and-behold, that's exactly what they did (copied those #defines into their code).

So, it's a bit of work, but it does appear to work...

Here's the goods... (and the bads...)

//Pondering using a USB-to-Parallel adaptor 
//They seem to have three modes:
// One-directional
// EPP/ECP
// IEEE-1284

// One-directional likely won't work
//  (Would with an *internal* and bit-banging)
// IEEE-1284 looks a bit too complicated for my needs
//
// EPP/ECP looks to be the way to go...
//  Bidirectional, using the same 8-bit data lines
//  Strobe, etc...

//First we need to make sure it's *possible* to set it in EPP/ECP mode!
#include <stdio.h>
#include <sys/ioctl.h>
//#include <linux/drivers/usb/class/usblp.h>

//ALL THESE for open()?!
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

#include <errno.h>
#include <string.h> //strerror

#if 0
#ifndef IOCNR_GET_PROTOCOLS
 #error "YEP"
#endif
#endif

int onError(char *location)
{
   if(errno)
   {
      printf("%s: Error %d, '%s'\n", location, errno, strerror(errno));
      return 1;
   }
   else
      return 0;
}

int printerPort_FD;

//These are defined in drivers/usb/class/usblp.c
// But there doesn't appear to be an associated header-file!
//This similar manual-entry (rather'n #including) is done in hpoj-0.91
#define IOCNR_GET_DEVICE_ID      1
#define IOCNR_GET_PROTOCOLS      2
#define IOCNR_SET_PROTOCOL    3
#define IOCNR_HP_SET_CHANNEL     4
#define IOCNR_GET_BUS_ADDRESS    5
#define IOCNR_GET_VID_PID     6
#define IOCNR_SOFT_RESET      7
   /* Get device_id string: */
#define LPIOC_GET_DEVICE_ID(len) _IOC(_IOC_READ, 'P', IOCNR_GET_DEVICE_ID, len)

/* The following ioctls were added for http://hpoj.sourceforge.net: */
/* Get two-int array:
  * [0]=current protocol (1=7/1/1, 2=7/1/2, 3=7/1/3),
  * [1]=supported protocol mask (mask&(1<<n)!=0 means 7/1/n supported): */

#define LPIOC_GET_PROTOCOLS(len) _IOC(_IOC_READ, 'P', IOCNR_GET_PROTOCOLS, len)

/* Set protocol (arg: 1=7/1/1, 2=7/1/2, 3=7/1/3): */
#define LPIOC_SET_PROTOCOL _IOC(_IOC_WRITE, 'P', IOCNR_SET_PROTOCOL, 0)

void getProtos(void)
{
   //Huh, isn't this architecture-dependent...?
   int twoInts[2];

   //WHOA DIGITY:
   //Bug in hpoj...?
   //int twoints[2];
   //ioctl(llioInterface[EX_INTERFACE_MLC].fdDevice,LPIOC_GET_PROTOCOLS,
   //      &twoints) <---- twoints is already an address... &(twoints[0])!
   ioctl(printerPort_FD, LPIOC_GET_PROTOCOLS(sizeof(int[2])), 
         (void*)twoInts);

   onError("GET_PROTOCOLS");

   printf("Current Protocol: %d\n"
          "Supported Protocols (Mask): 0x%x\n", twoInts[0], twoInts[1]);
}

int main(int argc, char* argv[])
{
   //ioctl requires a file-descriptor not a FILE*...
   // And we might want some of those other O_ options, as well.
   //FILE *printerPort;
   //printerPort = fopen("/dev/usb/lp0", "r+");

   //int 
   printerPort_FD =
      open("/dev/usb/lp0", O_RDWR); //Maybe O_NONBLOCK?
   
   if (printerPort_FD == -1)
   {
      if( onError("Open") )
         return 1;
      //printf("Open: Error %d, '%s'\n", errno, strerror(errno));
      //return 1;
   }




#define STRING_LEN  1000

   char ioctl_return[STRING_LEN] = { [0 ... (STRING_LEN-1)] = '\0'};
   
   ioctl(printerPort_FD, LPIOC_GET_DEVICE_ID(STRING_LEN), 
         (void*)ioctl_return);

   onError("DEVICE_ID");

   printf("DEVICE_ID: '%s'\n", ioctl_return);



   getProtos();

   if(argc > 1)
   {
      int newProto = atoi(argv[1]);
    
      printf("Per Request: Setting Protocol to %d\n", newProto); 

      //man ioctl is a bit confusing... or this is implemented weird
      // don't send a pointer to newProto, send newProto itself.
      ioctl(printerPort_FD, LPIOC_SET_PROTOCOL, newProto);

      onError("SET_PROTOCOL");

      getProtos();
   }

   close(printerPort_FD);
}

note that it has to be run 'sudo' on my system, despite having added myself to the 'lp' group... huh.

So, now you can set your usb-parallel dongle's port to whatever mode you like. SPP should be the easiest, allowing you to e.g. 

"echo x > /dev/usb/lp0" 

and see the binary value of 'x' displayed on those output-pins.