An ICC_STATE_BLOCK sounds reasonable. But can I add it there without
breaking the PC/SC specification?
Do you know a better solution at the top of your head, if the reader
has interrupt support?
>From my point of view, the reader *does* support interrups. It just
shares this interrupt with the serial driver, which complicates things
a bit. Maybe not worth it just so save a 4 Hz poll loop, but I have
reasons to fiddle with the serial driver anyway. (This smartcard
reader happens to be a V.90 modem too, and it supports simultaneous
operation on one COM port, with the proper driver.)
Thanks
Morten
At 08:56 1999-01-18 -0600, you wrote:
>I merely call the IFD_GetCapabilities function in the IFD_Handler to get the
>card status from SCARDTRACK. I'm currently using the Tag ICC_STATE. If you
>want to block at the driver level you might use the tag ICC_STATE_BLOCK or
>something. You would do this in the IFD_Handler's GetCapabilities function.
>That is the best I can come up with since there is really no function listed to
>do this.
>
>When your block
>finishes, the higher level block will see the change and return. There is
>probably a better way of doing this for readers that support interrupts.
>
>Thanks
>Dave
>
>
>On Mon, 18 Jan 1999, you wrote:
>>>The function GetStatusChange just blocks until this event occurs using a
>>>simple select statement and then the
>>>function returns. I'm currently checking card status every 1/4 second and
>>>blocking until change occurs.
>>>
>>
>>Is it possible to add an option to forward this "blocking call"
>>to the smartcard readers' driver?
>>
>>I'm about to write a driver for the Intertex readers, and they can signal
>>a status change by sending two characters over the serial line.
>>
>>I'm too new to this to tell the best implementation, but I guess a new (?)
>>CT-API command will do. (CT_Data() probably needs to be reentrant then.)
>>
>>GetStatusChange() calls it:
>>
>> If supported, it waits for the reader and returns at status change.
>>
>> If "unknown command" is returned, there is no support from the reader,
>> and you have to loop instead.
>>
>>Or a new CT_GetStatusChange() maybe? But this breaks backward compa-
>>tibility with all of the current drivers.
>>
>>Thanks
>>
>>Morten Norman
>>
>>---------------------------------------------------------------------------
>>Looking for the best modem in the world? [EMAIL PROTECTED]
>>Judge for yourself, but don't miss our candidates. http://www.intertex.se
>>---------------------------------------------------------------------------
>>
>>***************************************************************
>>Linux Smart Card Developers - M.U.S.C.L.E.
>>(Movement for the Use of Smart Cards in a Linux Environment)
>>http://www.linuxnet.com/smartcard/index.html
>>***************************************************************
>--
>******************************************************************
>David Corcoran Internet Security/Smartcards
>
>Work: School:
>205 Industrial Blvd 2252 US Highway 52 West Apt C4
>Sugar Land, TX 77478 West Lafayette, IN 47906
>
>Quotes:
> If it's a hobby for us and a job for you, then why are you doing
> such a shoddy job (Microsoft) ? ~ Linus Torvalds
>
> If you can't make it work, at least make it look good.
> ~ Bill Gates
>******************************************************************
>***************************************************************
>Linux Smart Card Developers - M.U.S.C.L.E.
>(Movement for the Use of Smart Cards in a Linux Environment)
>http://www.linuxnet.com/smartcard/index.html
>***************************************************************
>
>
***************************************************************
Linux Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux Environment)
http://www.linuxnet.com/smartcard/index.html
***************************************************************