nanogui: Problem using tslib with microwindows


Previous by date: 21 May 2012 07:46:09 -0000 Re: How to get configure to find NXlib, Georg Potthast
Next by date: 21 May 2012 07:46:09 -0000 Test, Alex Holden
Previous in thread:
Next in thread: 21 May 2012 07:46:09 -0000 Re: Problem using tslib with microwindows, Greg Haerr

Subject: Problem using tslib with microwindows
From: "Luca Marzolla" ####@####.####
Date: 21 May 2012 07:46:09 -0000
Message-Id: <002e01cd3725$c7d3da40$577b8ec0$@carel.com>

Hi,

I'm porting an old microwindows application on a new device: a Cortex AM3505
processor (Linux 2.6.37) using touch screen controller TSC2004 from TI.

I successfully compiled my application, which now use tslib (TSLIBMOUSE in
config file) to detect touch screen events. The application runs well on the
new device, but sometimes it seems it get stuck when a button is pressed
(the button seems to be pressed but never released!). Pressing one more
time, (everywhere) the touch-screen the application seems to be unblocked,
running normally. I have to say I have tested tslib using a simple
standalone program and everything (HW and driver) is ok; microwindows
application is also ok since it runs well on many different platforms (an
Ubuntu pc using X11 and other embedded devices using directly the frame
buffer + ZEFEERMOUSE driver).

 

I noted that when new samples are available, select() returns a positive
value and if the mouse file descriptor belongs to the select() set, mouse
events will be acquired until GsCheckMouseEvent() returns a non zero value
(see GsSelect() from srvmain.c):

 

    if(mouse_fd >= 0 && FD_ISSET(mouse_fd, &rfds))

        while(GsCheckMouseEvent())

 

GsCheckMouseEvent() returns the result of GdReadMouse() (devmouse.c) which
calls PD_Read() (mou_tslib.c) to get the samples. Finally, PD_Read() calls
ts_read() from tslib library:

GsCheckMouseEvent() -> GdReadMouse() -> PD_Read() -> ts_read()

 

I noted that sometimes GdReadMouse() returns 0, when it detects "nothing
changes". This happens when two consecutive pressures are detected, without
a release in the meanwhile: for example with a classic mouse this means the
user click down the button, moves around the mouse but doesn't release the
button so we have to update the mouse position but we don't have to generate
a button-release event:

 

GdReadMouse(MWCOORD *px, MWCOORD *py, int *pb){

 

    /*At this point, we should have a valid mouse point...    

    ...

    

    /* Finally, move the mouse */

    ...

    GdMoveMouse(dx, dy);

    ...

        

    /* anything change? */

    if (!changed)

        return 0;

    ...

               return 1;

}

 

so GsCheckMouseEvent() sometimes returns zero, breaking the while loop
above; but it is possible that some data is still pending and has to be read
(for example, a pending release sample). Normally, data will be read at next
invocation of GsSelect(), but all pending samples have been alredy read and
buffered from tslib, so the select returns 0, even if there is some sample
to read from tslib! Since I don't have any other input device (mouse or
keyboard), data remains inside tslib until someone touchs the screen,
unlocking the application (so select will return a positive value and all
samples, including the old one, will be retrieved using tslib "ts_read"
routine).

 

I think the problem is due to the fact that microwindows uses the mouse file
descriptor to detect if data is available (a low level method), but in
contrast also uses tslib (which provide high level routines and a buffered
access) to retrieve samples. In fact, I noted that when I press and release
the screen I can generate many samples: many pressure samples and one
release sample; if tslib read all the samples and bufferize them all,
microwindows driver has to read all the samples (while ts_read() returns
EAGAIN) BEFORE to check again the mouse file descriptor.

 

I removed the code:

 

    /* anything change? */

    if (!changed)

        return 0

 

from GdReadMouse() routine and everything seems to be ok, application never
stays stuck, but I suspect this is not the right way, since it affects the
behaviour of all the mouse/touch-screen drivers. Moreover, in this way, if
two pressures and one release have been generated, will be reported 3 new
mouse datas rather than 2 (2 pressures and 1 release rather than 1 pressure
and 1 release).

Probably the best solution is, if nothing changes, continue to read data
from tslib while no data arrives anymore, moving the mouse (GdMoveMouse())
but updating mouse data only when something changes:

 

 

               READ_MOUSE_POSITION:

               /* read the mouse position */

               

               ...

 

               /* anything change? */

               if (!changed)

                              goto READ_MOUSE_POSITION;

 

 

Is this the right fix? 

Any suggestion? 

 

 

I think I found this problem because my new device is very fast (expecially
the processor) and the tslib can acquire and store many samples for each
read-request; if tslib read exactly one sample (i.e. one pressure and one
release, and this happens most of the times), the application runs as
expected.

 

Thanks in advance.

Luca

 

 

 

 

 


Previous by date: 21 May 2012 07:46:09 -0000 Re: How to get configure to find NXlib, Georg Potthast
Next by date: 21 May 2012 07:46:09 -0000 Test, Alex Holden
Previous in thread:
Next in thread: 21 May 2012 07:46:09 -0000 Re: Problem using tslib with microwindows, Greg Haerr


Powered by ezmlm-browse 0.20.