That's is normal and the intended behavior. The qcam backend uses
POSIX-style locking, _not_ the old Unix-style locking where the
presence of the file indicates a busy lock. With POSIX locking, there
is no point in removing the file.
Mark> OK, here it is... I started xcam, clicked "play", got one
Mark> image and the hang, then interrupted it with ^C:
Hmmh, there are lots of these:
Mark> [qcam] qc_send: sent 0x1d, camera echoed 0x78
Which indicates that the backend has a hard time reading the command
echos from the camera. You might want to play with qcam.c:qc_wait() a
little and see whether increasing the delay will fix the problem.
E.g., you could try something like this and then play with the loop
bound:
void
qc_wait (QC_Device *q)
{
extern void dummy (void);
int i;
for (i = 0; i < 50000; ++i)
dummy(); /* so this doesn't get optimized away */
}
void
dummy (void)
{
}
--david
-- Source code, list archive, and docs: http://www.azstarnet.com/~axplinux/sane/ To unsubscribe: mail -s unsubscribe sane-devel-request@listserv.azstarnet.com