I’m writting a driver for a custom printer. Before
testing the driver and the printer I decided to get
acquited with the printer device driver in the kit.
I hook up a epson printer and started the driver.
Everything looked fine, I could print without any problem.
I then wrote a small program that did:
open()
ioctl (DCMD_CHR_LINESTATUS, &status);
printf(“status %x\n”, status );
close()
To see how the whole think behave under various
condition.
I created a paper out condition by printing without
any paper. Once that paper out condition was created,
I started my small test program. The status indeed
showed a paper out condition, but the close() did
not return !?!
After some digging around I notice the prn_io_close()
does a transmit of 0 lenght on the bulk out endpoint.
For reason unknow to me this call does no return.
Resolving the paper out condition unblocks the close().
I’m surprise by this behavior and am wondering if
this is “by design” ?
Sorry this belongs to USB, please ignore.
“Mario Charest” <mcharest@deletezinformatic.com> wrote in message
news:9blf0b$sco$1@inn.qnx.com…
I’m writting a driver for a custom printer. Before
testing the driver and the printer I decided to get
acquited with the printer device driver in the kit.
I hook up a epson printer and started the driver.
Everything looked fine, I could print without any problem.
I then wrote a small program that did:
open()
ioctl (DCMD_CHR_LINESTATUS, &status);
printf(“status %x\n”, status );
close()
To see how the whole think behave under various
condition.
I created a paper out condition by printing without
any paper. Once that paper out condition was created,
I started my small test program. The status indeed
showed a paper out condition, but the close() did
not return !?!
After some digging around I notice the prn_io_close()
does a transmit of 0 lenght on the bulk out endpoint.
For reason unknow to me this call does no return.
Resolving the paper out condition unblocks the close().
I’m surprise by this behavior and am wondering if
this is “by design” ?