Touch screen (stylus) input offset in certain software applications ONLY. No hardware issue, but qui


porg

Active Member
Joined
Oct 6, 2008
Messages
792
Location
Vienna, Austria
Over time I realized that certain apps' absolute input (touch input aka stylus) do "catch" a little offset, if you click within some few (or many) unlucky areas.

This certainly is a software issue, as the stylus works perfectly accurate on i.e. my XFCE desktop, regardless of wether clicking or dragging (=click, hold & move).

And after I return from the faulty app, the stylus is still properly aligned on the XFCE desktop, no system-wide stylus corruption occurred.

It would be wonderful if we could find their common weakness. I.e. using the same misbehaving library or API.

Below I list some working/failing touch apps. If I easily detirmined the used libraries, API or programming language I noted it in brackets.

I cannot recall all apps but googling the repo may give you a broader list, if necessary.

In the forum I found only 1 app-specific stylus complaint, the majority rather concerning system-wide stylus issues.

Here are some examples for touch controlled apps which can suffer stylus offset:

Sorted from most easily comprehensible (only 1 unlucky area causes always the same offset) to most incomprehensible (complex offset genesis).

Color lines: Touching the music or volume control in the left-bottom corner area offsets your stylus about 1cm left to its real touching position. Equal offset everywhere on the screen (no proportional offset).


Monkey VS Robots: As soon as you touch the black area (letterbox) of the screen the pointer is offset. The offset differs on the situation. Anything from slightly off, to way off. It can be compensated by moving into the edges of the visible area. But not completely reset, only weakening the offset.

Widelands: a) As soon as you reach the border areas of your screen, you "catch" a stylus offset.

B) As soon as you touch a button in a windows (i.e. in the tutorial, when some button in the action dialog is pressed).

The offset differs each time in both cases.

Some examples for touch apps where the stylus is always perfectly aligned:

(Regardless of most extreme stylus movements or positions)

Native pandora apps: Dino Defense, Frootopia

Ported apps: Fireworks (C++, Allegro), Albion (notaz SDL, tested mode "Touchscreen - right handed")

UPDATE: The issue was confirmed as being app-specific, no firmware (operating system) bug.

For developers who are encouraged to fix the stylus offset bugs:

Please use the SDL patch by DJWills or the improved SDL by notaz.
 
Last edited by a moderator:
This is an old and known bug and the developers just need to use notaz sdl if they arw lazy, or incoorperate DJWillis fix to make it go away.
 
Last edited by a moderator:
@mcobit:

1) Thanks for your clarification! I will henceforth point developers whose apps are affected here.

2) One last request. Could you please give a more descriptive name of "DJWIllis fix" and/or URLs to both fixes? A simple re-edit of your post would do it. I will then remove nr 2 from this my post as well. Thanks.
 
@notaz, that would actually be pretty appreciated, as for example qemu doesn't grab the mouse with your sdl and I couldn't get my head around how the mousesdlinput works there as it is wrapped into some ps/2 mouse emulation as it seems.
 
PS/2 mouse emulation will never work properly with absolute input devices like the touch screen. (Mouse acceleration, DPI, and the unknown offset...)
 
Back
Top