Lower Level (Than Xlib) "mouse" Events

[chris_c]

xlib is commonly laggy with its mouse events - and in turn so is sdl etc

I'm directly using xlib and not happy with the laggyness (invented a word!) I'm experiencing with mouse events

Basically I want pen down / up and pen x,y coordinates when it touches or drags...

I'm already accessing /dev/input/event for gpio-keys to monitor lid closing events is that the way to go for touch screen
events? anyone noticed any laggyness (liking my new word) there?

anyone used tslib whats that like?

 

[crow_riot]

i've used tslib on the wiz, it's just straight forward usage: open the device, read raw data, close it when you're done.

nothing spectactular, but i think that's what you want.

i don't know if any filters are applied on the data by xlib; the data i received on the wiz was very jittery, so you maybe need to write your own smoothing filter to work around that and maybe the filters on xlib aren't the best

 

[chris_c]

interestingly tslib and xlib are 1:1 in their results both seem laggy

if I could work out what the numbers in /etc/pointercal were I'd have a look at converting the raw data to see if there is any lag there....

 

[chris_c]

further results - just did a quick and dirty ahem "calibration" and looks like the kernel interface (/dev/input/eventn) displays the same lag

mx=(4000-tsx)/5;
my=(4000-tsy)/8.3;

basically a mouse pointer done with events from xlib, tslib or the raw kernel interface show exactly the same lag

oddly if I show the xlib cursor that exhibits less lag, so where the flip is that getting its data from!!!

 

[notaz]

ADC readings are noisy so the driver is doing it's own smoothing, maybe it's causing that lag (personally I haven't noticed any)..

 

[chris_c]

ADC readings are noisy so the driver is doing it's own smoothing, maybe it's causing that lag (personally I haven't noticed any)..

if you drag the pointer slowly its fine whoosh it from one side of the screen to the other and back again its at least 1/4 of a screen width behind, individual pointer stabs seem fine tho so I don't think I'm going to worry too much about it, odd though that the xorg cursor has less lag!

 

[whynodd]

The touchscreen driver generally is buggy. it loses data somewhere,maybe priority issues. Draw some circles in xournal... My very old 100mhz pda performed 1000times better at drawing.
And touchscreen clicks always twice quickly on touch and not as long as you touch. Maybe two drivers interfere or so, don't know, i just guess. In my opinion that should be adressed soon. Thats why we can't maximize and why drag'n'drop often fails.
Also nubclicks, they click for a predefined time instead as long as you keep the nub pressed left.

Anyway, try the folowing to lessen the touchscreen lag A BIT: Edit /etc/ts.conf to this:

ts.conf for the OMAP3-PANDORA default touchscreen.
module_raw input  module pthres pmin=1
# module variance delta=3000
# module dejitter delta=0
module linear

That comments out some filters. Also the cursor seems to be faster without window manager compositing.

Hmm, shouldn't an input driver have higher priority than everything else?

 

[chris_c]

The touchscreen driver generally is buggy. it loses data somewhere,maybe priority issues. Draw some circles in xournal... My very old 100mhz pda performed 1000times better at drawing.
And touchscreen clicks always twice quickly on touch and not as long as you touch. Maybe two drivers interfere or so, don't know, i just guess. In my opinion that should be adressed soon. Thats why we can't maximize and why drag'n'drop often fails.
Also nubclicks, they click for a predefined time instead as long as you keep the nub pressed left.

Anyway, try the folowing to lessen the touchscreen lag A BIT: Edit /etc/ts.conf to this:

ts.conf for the OMAP3-PANDORA default touchscreen.
module_raw input  module pthres pmin=1
# module variance delta=3000
# module dejitter delta=0
module linear

That comments out some filters. Also the cursor seems to be faster without window manager compositing.

Hmm, shouldn't an input driver have higher priority than everything else?

aahhh is that why on a value with an up down arrow, click it more than a few times and the value goes through the roof?
I assumed for reason that it was an xlib problem but a buggy touch driver does make more sense!

 

[Rockthesmurf]

I've noticed a bug on input, I just haven't got around to making a cut down case for it, essentially I am interested in press, drag and release events, and I get regularly occurring drag events that do not have a corresponding a press event. I'm using xlib. For now my input code just pretends a press event has occurred in this case, but it certainly feels like a bug to me. My game is a touch screen based game, involving lots of quick movements and reasonably fast reactions. I too find the Pandora screen rather laggy, the game is just about playable, but doesn't feel anywhere near as nice as on other platforms (IPhone/Android/PC/Mac/etc.) I have started to think maybe this is as good as it gets, but certainly I'd be very interested if there are any developments that improve the touch screen input!

Steve

 

[PokeParadox]

interestingly tslib and xlib are 1:1 in their results both seem laggy

if I could work out what the numbers in /etc/pointercal were I'd have a look at converting the raw data to see if there is any lag there....

You can see what to do with the numbers here:
http://code.google.com/p/penjin/source/browse/trunk/SimpleJoy.cpp#305

 

[chris_c]

interestingly tslib and xlib are 1:1 in their results both seem laggy

if I could work out what the numbers in /etc/pointercal were I'd have a look at converting the raw data to see if there is any lag there....

You can see what to do with the numbers here:
http://code.google.com/p/penjin/source/browse/trunk/SimpleJoy.cpp#305

I ended up doing a simple scale as a quick hack which was enough to verify it also tracks 1:1 with xlib events - but also lags behind the xorg cursor - most odd....