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
***************************************************************

Reply via email to