Forgot to mention... In order to execute the program, you should provide the full path for the USB device and the interrupt endpoint. I wanted to keep it as simple as I could so I did not copied static logic.
At my configuration it is: ./a.out /dev/bus/usb/002/025 131 I don't know why 131... But this is what the code at ifdhandler produces. Alon. On 12/20/08, Alon Bar-Lev <alon.bar...@gmail.com> wrote: > Hello All, > > CC you as I changed the subject, to meet the discussion. > > On 12/19/08, Peter Stuge <pe...@stuge.se> wrote: > > USB is completely driven by the host, so unless an app keeps a > > transfer pending for the interrupt pipe, nothing will be transfered. > > The USB function (reader) detects that it couldn't send and takes > > some action, typically either throwing the message away, or queueing > > it for a retry later. > > Well... I must say I do not understand the low level implementation of > USB... I wrote a sample program you can play with, and see that it > actually work. > > I tried to keep as much code as I could from OpenCT. > > At least with the SCR335 sample I have it detects card removal and > card insert with no CPU footprint. It also handles termination signal > and reader detach. > > I will be happy to know if I did something wrong. > > Thanks. > > Alon. > > _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
