I'm not sure what could be causing the first problem.  It might be a calibration issue, and the flashplayer is causing the click event to happen at the very bottom of the screen.  Or it could be that the hitarea is oddly shaped for those buttons.  Duane might have to comment on that.

As for the second problem, I think that's just how the hardware is built.  The rotary coder used in these devices has 16 positions (i.e. one full rotation will send 16 events), but there are 32 clicks.  So every other tactile "click" is ignored.  It has no way of knowing if you're rotating it forward or rocking it back and forth.  I'm not sure what can be done about that.

Alright, here's a proof of concept change for the rotary decoder driver that seems to work.  It actually provides four times the resolution, which I divide down by 2 to get one step per click.  Change output_divider to 4 and it'll behave as before, but without the back-and-forth bug.

edit: one small change that I just thought about (and now I can't overwrite that file for some reason).  case 0x30 should be:

        case 0x30:
        if (cnt < 0)
            cnt = cnt*4+2;
        else 
            cnt = cnt*4-2;
        break;

Without the if it counts down by 6 instead of two if you rotate it back two steps and land on state 0.  Technically most of the cases should have tests like this to handle rotating by 3 steps between polls correctly.

If you're seriously considering it, grab the new version I just put up.  I added a lot more logic to handle rarer cases, and discovered a bug (it was assuming state 3->state 0 meant rotate up 2, when it could mean either direction). 

All said, this is really a horrible hardware rotary decoder - I knew something was wrong when they had debounce circuitry in a gray code decoder .  They should have either made it count on each state transition, or up and down across symmetric state edges (10->00 and 00->10 instead of 10->00 and 01->00)

edit: on futher testing it still seems to be tracking rather inconsistently.

edit2: I think the problem was the sampling was too slow.  I turned up the sampling rate of the decoder hardware by a factor of 4 and it seems to be working better.  It still seems to trend upwards a bit if you rotate the knob back and forth rapidly, but at least a given rotation results in about the same change in volume.  New version uploaded.