I've tried dumping the registers returned from USB during key press event transactions a fiddled with the handset a bit, and I think I see where the stray "key press" events are coming from. The trial explanation below is based on reading usbb2k_get_key, in light of what I see in the register dump.
At the driver end, each transaction takes place in two stages. First the registers are queried to see if there has been a key press. This transaction returns a key press event number, which is the number of key presses made while in the current session of the current mode. This event number is then used in a query to get the actual key pressed. The response to the query is a URB (data[0 to 15]) that contains the key press event number at data[3], and the key code at data[4]. Both numbers are significant, because there is repeated traffic checking for the event, so the key code alone would not be enough. That is, we identify whether there has been a fresh key press by checking whether the key event number on data[3] has changed (and therefore needs to be reported to the socket), and we get the key code separately from data[4], and report it to the socket as "KEY 0b\n", or whatever.
So far, so good. The key press event number is the starting point for this rigamarole, so we might wonder by what logic it is generated in the box. It looks as though the first response of the box after a switch to USB mode is a response with a key event number of 0. Subsequent increments (i.e. > 0) are actual key presses. If that's reading the patterns correctly, then usbb2k_api is mishandling these events, and that's where the extraneous key press events are coming from. What should be happening is that key press event 0 is dropped on the floor, and everything > 0 is reported to the socket. Instead, the driver is *decrementing* the key press event, so this first event becomes -1. It then checks to see if the event is less than zero, and if it is, bumps it up to 1F (in the 32nd key press patched version) or 7E (in the unpatched version). This is then fed back to the box in the query URB, to obtain a key press response. Unsurprisingly, the box response -- but since the key event number is out of sequence, it reports a key press from some other time (or maybe just cruft clinging to a register someplace in the silicon).
It seems pretty clear that the query based on the first key event number (0) should not be happening.
If this query were skipped, it would not be handled as a key press event, and the machinery would not cycle around and ask the box for another key press event number. This would mean that the key press event number used in the query *before* this event (which will be the * key, if switching modes using my patch to kb2kskype) will be the same as that used in the query *after* the event. And what I see in the register dump is that the key code reported in both of these events is always identical -- only the key press event number differs. If the key press event number were the same, the second event *would* be* *ignored*. As a result, the phantom key presses would vanish.
I'm going to go out on a limb here and say that I think I've got this one cornered. I have other things on this weekend, but in between times I'll try out the changes that follow from this (both usbb2k_api and kb2bkskype will need to be repatched), and report back on what happens.
Meanwhile, I discovered yesterday that I messed up Simon's dialing logic pretty badly in the first ADNAMS patch with a bunch of gratuitous changes that seem, in retrospect, to be perfectly senseless. I'll put up a second supplementary patch on the tracker now, which I think will restore things to a more sensible state. It will be untested, so as ever, proceed with caution.
More later ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for all your input on this project, unfortunately I'm very very busy at work and going out to sea next week, so haven't had time to look at your patches that you submitted. On that note which patches need to be applied and which should I just remove, or have you done this already? I will do some testing of them on sunday and if all goes well on my setup as well I release the new build.
Also have you tried the new 1.4 Skype yet ? I saw they has released a new version with x11 but couldn't find the download on the blog.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No rush on anything. I've removed the old patches, so no need to clean that up. There might be one more today or tomorrow, if my intuitions about mode-switching dialogs with the box turn out to be correct; but if it emerges, that one will just be an i-dotting, t-crossing thing. It should not affect behaviour at user end. It just bugs me that there is not a 1-1 correspondence between keys pressed and events on the socket.
I haven't tried Skype 1.4, but I did see the developer's note about x11 support. Very much looking forward to trying it out when they get a release of that out for inspection.
The main thing I'm curious (well, okay, a little worried) about is the way the patched code handles inbound calls. It is possible that I've broken the answering logic, but I haven't gotten around the testing that yet.
Be careful out there, I hope you have a productive excursion. (It's a trivial aside, but we lived in London 1988-1998, and we still miss Leicester cheese omelettes some mornings.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Cracked it! With patches I am about to upload to the tracker, usbb2k_api no longer reports extraneous key press events after a switch from PSTN to USB mode. Instead, it reports "USB OK". A fresh patch for kb2kskype looks for this event, and issues a USB dialtone when the * key is pressed as per normal.
The transaction logic was a little different from my description above, but my hunches were more or less right. The fixed required only one additional line of code. :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The one outstanding issue is inbound Skype calls. I finally had the obvious thought this morning and created a second Skype account for myself to try this out. In the current patched version, the box will kick from PSTN to USB mode, but the phone will not pick up. The problem is not particularly major; the problem is that the call handling routine is not waiting for an answer from the box (USB OK) before attempting to start the ring. I tried inserting a "sleep(1)" to let the box catch up, and ringing works. So this should be easy to fix when I find a little time to do the work. As far as I can see, this should only be a problem when the default is set to PSTN; in USB mode, there is not mode switch, so the box doesn't need to catch up.
Once I've sorted through this and done a bit of testing, I'll submit a patch to tracker.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the above, "the phone will not pick up" should read "the phone will not ring". If you pick up the call during the ring (that you can only hear from the other end of the connection), the call proceeds normally.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've put up a fourth supplement to the big ADNAMS patch, that gets incoming calls working. If this works in other environments too, this pretty much rounds out the functionality to match the Windows driver.
When I get around to it, I'll stir in a couple of command line options that will be useful to us in our environment here. But for the mo, this looks like a wrap.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've tried dumping the registers returned from USB during key press event transactions a fiddled with the handset a bit, and I think I see where the stray "key press" events are coming from. The trial explanation below is based on reading usbb2k_get_key, in light of what I see in the register dump.
At the driver end, each transaction takes place in two stages. First the registers are queried to see if there has been a key press. This transaction returns a key press event number, which is the number of key presses made while in the current session of the current mode. This event number is then used in a query to get the actual key pressed. The response to the query is a URB (data[0 to 15]) that contains the key press event number at data[3], and the key code at data[4]. Both numbers are significant, because there is repeated traffic checking for the event, so the key code alone would not be enough. That is, we identify whether there has been a fresh key press by checking whether the key event number on data[3] has changed (and therefore needs to be reported to the socket), and we get the key code separately from data[4], and report it to the socket as "KEY 0b\n", or whatever.
So far, so good. The key press event number is the starting point for this rigamarole, so we might wonder by what logic it is generated in the box. It looks as though the first response of the box after a switch to USB mode is a response with a key event number of 0. Subsequent increments (i.e. > 0) are actual key presses. If that's reading the patterns correctly, then usbb2k_api is mishandling these events, and that's where the extraneous key press events are coming from. What should be happening is that key press event 0 is dropped on the floor, and everything > 0 is reported to the socket. Instead, the driver is *decrementing* the key press event, so this first event becomes -1. It then checks to see if the event is less than zero, and if it is, bumps it up to 1F (in the 32nd key press patched version) or 7E (in the unpatched version). This is then fed back to the box in the query URB, to obtain a key press response. Unsurprisingly, the box response -- but since the key event number is out of sequence, it reports a key press from some other time (or maybe just cruft clinging to a register someplace in the silicon).
It seems pretty clear that the query based on the first key event number (0) should not be happening.
If this query were skipped, it would not be handled as a key press event, and the machinery would not cycle around and ask the box for another key press event number. This would mean that the key press event number used in the query *before* this event (which will be the * key, if switching modes using my patch to kb2kskype) will be the same as that used in the query *after* the event. And what I see in the register dump is that the key code reported in both of these events is always identical -- only the key press event number differs. If the key press event number were the same, the second event *would* be* *ignored*. As a result, the phantom key presses would vanish.
I'm going to go out on a limb here and say that I think I've got this one cornered. I have other things on this weekend, but in between times I'll try out the changes that follow from this (both usbb2k_api and kb2bkskype will need to be repatched), and report back on what happens.
Meanwhile, I discovered yesterday that I messed up Simon's dialing logic pretty badly in the first ADNAMS patch with a bunch of gratuitous changes that seem, in retrospect, to be perfectly senseless. I'll put up a second supplementary patch on the tracker now, which I think will restore things to a more sensible state. It will be untested, so as ever, proceed with caution.
More later ...
Thanks for all your input on this project, unfortunately I'm very very busy at work and going out to sea next week, so haven't had time to look at your patches that you submitted. On that note which patches need to be applied and which should I just remove, or have you done this already? I will do some testing of them on sunday and if all goes well on my setup as well I release the new build.
Also have you tried the new 1.4 Skype yet ? I saw they has released a new version with x11 but couldn't find the download on the blog.
No rush on anything. I've removed the old patches, so no need to clean that up. There might be one more today or tomorrow, if my intuitions about mode-switching dialogs with the box turn out to be correct; but if it emerges, that one will just be an i-dotting, t-crossing thing. It should not affect behaviour at user end. It just bugs me that there is not a 1-1 correspondence between keys pressed and events on the socket.
I haven't tried Skype 1.4, but I did see the developer's note about x11 support. Very much looking forward to trying it out when they get a release of that out for inspection.
The main thing I'm curious (well, okay, a little worried) about is the way the patched code handles inbound calls. It is possible that I've broken the answering logic, but I haven't gotten around the testing that yet.
Be careful out there, I hope you have a productive excursion. (It's a trivial aside, but we lived in London 1988-1998, and we still miss Leicester cheese omelettes some mornings.)
Cracked it! With patches I am about to upload to the tracker, usbb2k_api no longer reports extraneous key press events after a switch from PSTN to USB mode. Instead, it reports "USB OK". A fresh patch for kb2kskype looks for this event, and issues a USB dialtone when the * key is pressed as per normal.
The transaction logic was a little different from my description above, but my hunches were more or less right. The fixed required only one additional line of code. :)
The one outstanding issue is inbound Skype calls. I finally had the obvious thought this morning and created a second Skype account for myself to try this out. In the current patched version, the box will kick from PSTN to USB mode, but the phone will not pick up. The problem is not particularly major; the problem is that the call handling routine is not waiting for an answer from the box (USB OK) before attempting to start the ring. I tried inserting a "sleep(1)" to let the box catch up, and ringing works. So this should be easy to fix when I find a little time to do the work. As far as I can see, this should only be a problem when the default is set to PSTN; in USB mode, there is not mode switch, so the box doesn't need to catch up.
Once I've sorted through this and done a bit of testing, I'll submit a patch to tracker.
In the above, "the phone will not pick up" should read "the phone will not ring". If you pick up the call during the ring (that you can only hear from the other end of the connection), the call proceeds normally.
I've put up a fourth supplement to the big ADNAMS patch, that gets incoming calls working. If this works in other environments too, this pretty much rounds out the functionality to match the Windows driver.
When I get around to it, I'll stir in a couple of command line options that will be useful to us in our environment here. But for the mo, this looks like a wrap.