| Line 292... |
Line 292... |
len = 26;
|
len = 26;
|
|
|
// printf("USBI::RAW-READ(%d, was %d)\n", len, clen);
|
// printf("USBI::RAW-READ(%d, was %d)\n", len, clen);
|
memcpy(m_txbuf, REQ_RX_BITS, REQ_RX_LEN);
|
memcpy(m_txbuf, REQ_RX_BITS, REQ_RX_LEN);
|
|
|
|
// I have chased process hangs to this line, but have no more
|
|
// information than that somewhere within libusb_bulk_transfer,
|
|
// libusb_handle_events_completed,
|
|
// libusb_handle_events_timeout_completed, ?, poll(), there seems
|
|
// to be a bug.
|
|
//
|
|
// I'm not certain if the bug is in the Linux kernel, or in the
|
|
// Xess tools. I will note that, when a followup attempt is made
|
|
// to read from the device, previously unread data may still get dumped
|
|
// to it. Therefore, be careful to clear the device upon starting
|
|
// any process.
|
|
//
|
|
// fprintf(stderr, "[");
|
int r = libusb_bulk_transfer(m_xula_usb_device, XESS_ENDPOINT_OUT,
|
int r = libusb_bulk_transfer(m_xula_usb_device, XESS_ENDPOINT_OUT,
|
(unsigned char *)m_txbuf, REQ_RX_LEN, &actual_length,
|
(unsigned char *)m_txbuf, REQ_RX_LEN, &actual_length,
|
timeout_ms);
|
timeout_ms);
|
|
// fprintf(stderr, "]");
|
|
|
if ((r==0)&&(actual_length == REQ_RX_LEN)) {
|
if ((r==0)&&(actual_length == REQ_RX_LEN)) {
|
} else if (r == -7) {
|
} else if (r == -7) {
|
// Nothing to read in the timeout provided
|
// Nothing to read in the timeout provided
|
// We'll have to request this data again ... later
|
// We'll have to request this data again ... later
|
return;
|
return;
|
