https://bugs.winehq.org/show_bug.cgi?id=42225
--- Comment #21 from Aric Stewart aric@codeweavers.com --- (In reply to Samuele from comment #19)
(In reply to Aric Stewart from comment #18)
Is this meaning there are 2 leading 0s on the feature report (0,0,194) or is it just (0, 194) and that 0 is being removed and re-added?
First two bytes are 0 and 194, so that 0 is being removed and re-added
Humm, ok that seem right. At least according to the spec.
Actually I was more thinking of just dumping the raw data and looking to see if thing changed. Something like this for the reports
I think that's what I did.. In process_hid_report I'm printing an hex string of the report buffer. Using this table http://www.hhhh.org/~joeboy/resources/magcards/trackdata_ANSI-ISO_ALPHA.html I can see that the data in that buffer is what's supposed to be on the magstripe (with the addition some bytes at the beginning and some bytes at the end). And yes the content of that buffer changes when I swipe a different card. So it looks like the data is sent by the reader back to the application, but the application keeps waiting like nothing happened.
Raw data is good, Curious if there is a report ID leading the byte string. You said there where some extra bytes at the beginning, What would those be? are the same with different cards? The report descriptor just seems to state it will be 64 bytes. The reportID is 0, so I wonder if there is a leading 0 or not. Shouldn't be.
-aric