Trying to get status via cupsBackChannelRead does not work with thiscode.

Michael Sweet msweet at apple.com
Mon Feb 13 07:16:31 PST 2012


The usual way of dealing with this is to flush all of your output, send a "drain" side-channel command, and then wait for back-channel data (up to 2 seconds in your case).

See:

    http://www.cups.org/documentation.php/doc-1.5/api-filter.html#COMMUNICATING_BACKEND

specifically the sub-section titled "Forcing All Output to a Printer".


On Feb 13, 2012, at 12:46 AM, Johan Henselmans wrote:

> Op 2/6/12 9:53 PM, Johan Henselmans schreef:
>> I am having problems trying to get the status from the printer I am writing a filter for.
>> 
> 
> I have found out the answer myself: as it appears, the printer does not send replies directly, but withing .5 to 2 seconds.
> 
> That explains why I am not getting the reply directly. This also implies that I will not be able to use the filter to
> pick up status codes. Sometimes the filter executable is already shut down when the status codes will arrive.
> 
> Now I have to find another way to pick up the status messages from the printer. First I was thinking about setting up a
> port monitor to pick up the status messages, as per http://www.cups.org/documentation.php/spec-design.html.
> 
> However, I suppose that the port monitor as described in this spec will also shut down after all the info has been sent
> to the printer.
> 
> Should I run a separate daemon to pick up the status codes that the printer sends via the backend?
> 
> 
> 
> 
>> The code I am using is:
>> 
>> 				
>> 	status = cupsSideChannelDoRequest(CUPS_SC_CMD_GET_BIDI, &data, &datalen, 5.0);
>> 
>> 	// Read the response if the output was sent
>> 	if (status == CUPS_SC_STATUS_OK & datalen==1){
>> 	  bidi=(cups_sc_bidi_t)data;
>> 	  // drain the pending output
>> 	  status = cupsSideChannelDoRequest(CUPS_SC_CMD_DRAIN_OUTPUT, &data, &datalen, 5.0);
>> 
>> 	  fprintf(stdout, "   <S2>"); //send status request, returns seven digit ticket count and prom version
>> 	  fflush(stdout);
>> 	  count = cupsBackChannelRead(backbuffer, sizeof(backbuffer), 0.0);
>> 	  fprintf(stderr, "DEBUG: ***** backbuf  Read %i backchannel bytes in Setup*****\n", count);
>> 	  if (count > 0){
>> 	    fprintf(stderr, "DEBUG: ***** backbuffer: [");
>>            int i = 0;
>>            while (i < count){
>> 	      fprintf(stderr, "%c", backbuffer[i]);
>> 	      i++;
>> 	    }
>> 	    fprintf(stderr, "] *****\n");
>> 	  }
>> 	fflush(stderr);
>> 	}
>> 		
>> 
>> This should return 23 bytes of data. The result is that I do not get 23 bytes of data, but -1, and after that I get a
>> bunch of messages that some data is received. It seems that the cupsBackChannelRead is not waiting long enough for the
>> answer. I varied with different settings for the time-out, from 20.0 to 0.0 to -1.0 as per
>> 
>> http://www.cups.org/documentation.php/api-filter.html#cupsBackChannelRead
>> 
>> But the results are not what I would expect, sometimes I get 1 bytes, sometimes -1 bytes, sometime I get the full 23
>> bytes. Is there something that I am missing here?
>> 
>> 
>> D [06/Feb/2012:20:59:09 +0100] [Job 1786] ***** backbuf  Read -1 backchannel bytes in Setup*****
>> D [06/Feb/2012:20:59:09 +0100] [Job 1786] Read 1 bytes of back-channel data...
>> D [06/Feb/2012:20:59:09 +0100] [Job 1786] Read 1 bytes of back-channel data...
>> D [06/Feb/2012:20:59:09 +0100] [Job 1786] Read 1 bytes of back-channel data...
>> D [06/Feb/2012:20:59:09 +0100] [Job 1786] Read 1 bytes of back-channel data...
>> D [06/Feb/2012:20:59:09 +0100] [Job 1786] Read 1 bytes of back-channel data...
>> D [06/Feb/2012:20:59:09 +0100] [Job 1786] Read 2 bytes of back-channel data...
>> D [06/Feb/2012:20:59:09 +0100] [Job 1786] Read 1 bytes of back-channel data...
>> D [06/Feb/2012:20:59:09 +0100] [Job 1786] Read 1 bytes of back-channel data...
>> D [06/Feb/2012:20:59:09 +0100] [Job 1786] Read 1 bytes of back-channel data...
>> D [06/Feb/2012:20:59:09 +0100] [Job 1786] Read 1 bytes of back-channel data...
>> D [06/Feb/2012:20:59:09 +0100] [Job 1786] Read 1 bytes of back-channel data...
>> D [06/Feb/2012:20:59:09 +0100] [Job 1786] Read 1 bytes of back-channel data...
>> D [06/Feb/2012:20:59:09 +0100] [Job 1786] Read 1 bytes of back-channel data...
>> D [06/Feb/2012:20:59:09 +0100] [Job 1786] Read 1 bytes of back-channel data...
>> D [06/Feb/2012:20:59:09 +0100] [Job 1786] Read 1 bytes of back-channel data...
>> D [06/Feb/2012:20:59:09 +0100] [Job 1786] Read 1 bytes of back-channel data...
>> D [06/Feb/2012:20:59:09 +0100] [Job 1786] Read 1 bytes of back-channel data...
>> D [06/Feb/2012:20:59:09 +0100] [Job 1786] Read 1 bytes of back-channel data...
>> D [06/Feb/2012:20:59:09 +0100] [Job 1786] Read 1 bytes of back-channel data...
>> D [06/Feb/2012:20:59:09 +0100] [Job 1786] Read 1 bytes of back-channel data...
>> D [06/Feb/2012:20:59:09 +0100] [Job 1786] Read 1 bytes of back-channel data...
>> D [06/Feb/2012:20:59:09 +0100] [Job 1786] Read 1 bytes of back-channel data...
>> 
> 
> 
> Kind Regards,
> 
> Johan Henselmans
> _______________________________________________
> cups-ddk mailing list
> cups-ddk at easysw.com
> http://lists.easysw.com/mailman/listinfo/cups-ddk

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair





More information about the cups mailing list