[<<] [<] Page 1 of 1 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: [nanogui] Problem using tslib with microwindows
From: Greg Haerr ####@####.#### Date: 2 Jun 2012 18:00:06 -0000 Message-Id: <AFC84460-51FD-4914-BA33-FF3A05E28A7B@censoft.com> > > I removed the code: > > > > /* anything change? */ > > if (!changed) > > return 0 This should work fine (as it does). My only comment would be that the driver buzz-loops while data is present, thus it is theoretically possible to delay any other code from running should the driver get data constantly. That's probably a minor problem considering that this fixes your initial problem. Regards, Greg | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 1 [>] [>>] |