got it to log, so what am I looking for? I'll try to log what happens when I move like you told me to... need more time to do that since that is time consuming to do a good logging of this 😀
Should I play with the motion-> settings in sdlmain?
The behaviour of the pen can be described that it really doesn't want to move around the screen but prefers to snap to the edges when you touch the screen. It CAN be moved across the screen but not in a controllable fashion.

got it to log, so what am I looking for?

There should be small in/decrements in the relative mouse movement when
using a regular mouse, and large ones for the tablet (the jumping).

Should I play with the motion-> settings in sdlmain?

Depends on what you mean with "play" 😀
You could try to generate the rel movement yourself, like putting the last value
of x and y into a static var and putting the difference into the rel x and y each time.

I recently bought a Viliv S5, a UMPC with a touchscreen. Aside from browsing the web and watching videos, it's primary purpose is to play games - mostly DOSBox. To my dismay it seems that DOSBox (SDL, really, but there's not an available workaround as far as I can tell) can't handle touchscreen input properly? It's fixed in SDL 1.3 as far as I can tell, but DOSBox can't compile (and none of the devs have the slightest interest in changing this) on the latest SDL, as I keep being reminded whenever I ask questions about a feature that's been implemented or fixed in SDL 1.3.

It's been nearly two years since this issue was reported, and the status is unchanged.

Anybody got (or could anybody write) a patch to rectify this? If not, perhaps it's time to seriously look at making DOSBox SDL 1.3-compilable, since there are now two features 1.2 suffers from the lack of (the other being multi-screen support), and this one is quite game-breaking for those of us with touchscreens.

I do not know C, nor C++, or I would be happy to fix this myself. I am a coder (Python), and (depending on the nature of the faulty input) believe this should be a relatively simple thing to fix, so forgive me if I seem in any way ignorant or insolent in the nature of my request - it is not meant that way.

You'd need to put a function (toggle-able via conf variable, possibly) that would then sit between mouse input and mouse input to DOSBox's DOS and interpret the wild flailing data as calmer, smoother data (this would be easier or harder depending on the incoming data's present smoothness). Judging visually, it would seem that all of the motion data is just fine (i.e., smooth), but it's being exaggerated so that a tiny movement ends up tossing the cursor to the edge of the window - if this assessment is correct, this should not be difficult to work around, just add a dynamic divisor to any mouse movement based on the native resolution of the touchscreen, chopping the movement down to a manageable size based on the sensitivity of the touchscreen (guessed via native resolution, best I could think of).

That or completely remove relative mouse motion - I tried the SDL environment variables suggested earlier in the thread, and they did not improve the issue one iota... The second solution I present would be far easier, and would allow for tapping around on a touchscreen, allowing the majority of mouse-requiring games to be played just fine (Civilization, Abuse, Master of Orion I & II, etc.)..

The very surprising aspect of this whole thing is that it exhibits the same behavior in windowed mode, with the mouse unlocked, etc.. SDL 1.2 ignorantly takes the movement or new coordinates and applies them to the previous ones from what I can visually see, regardless of the situation (windowed, freed mouse, etc.)..

Anybody got suggestions, or is willing to help? Please?

Edit: Apparently SDL 1.2 supports a library for touchscreens called "tslib" (transparently, provided you compile it with said support), so that is a possible workaround method as well, unless it's not crossplatform (all references I've seen are Linux, and googling "tslib windows" reveals no trace)..

Problem with sdl 1.3 is that it has no release yet, marking it unstable still. Maybe in another two years this will change...

Well unstable or not, it could still be compiled against after code changes, and will need to be moved to at some point down the line anyway. You could even recommend a particular revision to compile DOSBox against once this were done, to avoid problems with people attempting compilation.

Anyway, that's not the only possible solution, and I expect one of the others would be more palatable anyway.