After looking through the code I believe I see what is going on. The connection to the tablet appears to be fine -- there is no problem there. The bug appears to be in sdl_event_loop when determining if the SDL_MOUSEBUTTONDOWN event should be ignored or not. The code for that is as follows:
1 2 3 4 5 6 7 8 | case SDL_MOUSEBUTTONDOWN: {
if ( event.button.windowID != platform_state->window_id ) {
break;
}
if ( (event.button.button == SDL_BUTTON_LEFT && ( EasyTab == NULL || !EasyTab->PenInProximity))
|| event.button.button == SDL_BUTTON_MIDDLE
// Ignoring right click events for now
/*|| event.button.button == SDL_BUTTON_RIGHT*/ ) {
|
Note that this code is checking to see if the pen for the tablet is in proximity (touching the surface) and discards the event if this is the case. This works most of the time. However, if the SDL events come in an unexpected order (SDL_MOUSEBUTTONDOWN followed by SDL_SYSWM_WINDOWS) then the PenInProximity flag has not yet been set. This causes the pressure array to get filled with NO_PRESSURE_INFO (which later ends up drawing a really thick line with pressure 1.0). On top of that, the flag MiltonInputFlags_CLICK gets set which puts Milton in a state where it is adding strokes as if they are originating from the mouse (also with maximum pressure = 1.0).
One possible fix would be to check for this case in SDL_SYSWMEVENT after the call to EasyTab_HandleEvent. Maybe something like:
1 2 3 | if (EasyTab && EasyTab->PenInProximity) {
input_flags &= ~MiltonInputFlags_CLICK;
}
|
Though you probably know of the best way to handle this. Hope this helps.
Thanks.
~x13pixels