Loss of mouse interaction with "Client" read

Help
Maria Cruz
2003-06-03
2003-06-09
  • Maria Cruz

    Maria Cruz - 2003-06-03

    I am running gpsd on an ADS Graphics Master running Linux.  I have a gps device attached to "serial" port.  the Client class is reading this constantly (ok).  BUT then i get NO mouse interaction!!!  i think Client is hogging CPU and nothing else can happen....
    any suggestions?

     
    • Ralf Haselmeier

      Ralf Haselmeier - 2003-06-04

      Some ideas:

      Communication is like this:
      GPS->serialPort->gpsd<->socket,qpegps
      gpsd is a daemon (=> check if the daemonizing works..)
      the socket of qpegps is event driven => data is read, if data arrives. gpsd sends data after receiving a request from qpegps. This request is sent in a fix intervall of 500ms.

      Please try the new gpsd of version 0.9.1 (from a previous post I assume that You are still using a former gpsd version together with a workaround in the client => remove this workaround). I don't know the ADS Graphics Master, but I assume that it is not much slower than a Sharp Zaurus.
      I don't have such a problem, if I start gpsd and qpegps in a Qtopia framebuffer on my (old) laptop (running linux, too).
      The only thing I can think of  is, that the mouse is somehow connected to the  serial port of Your GPS.
      You may also try to use a different port for the communication with gpsd (adjustable in qpegps and gpsd; and may be, that there is another program sending data to used port or...).

       
    • Maria Cruz

      Maria Cruz - 2003-06-05

      I have tried without using the mouse, but using touch screen.  I have the same issue.  When I change

      void MapDisp::paintEvent( QPaintEvent *p )
      {
        /* pmc 6/2/03 this method is called for each "MapDisp->update()" AHHH!!
           I think this is why the mouse interaction stops (mouse events cant get thru!)
        */
        if (mBadpaint < 10) {
          createMap();

          mBadpaint++;
        }
        else {
          QWidget::paintEvent( p );
        }

        bitBlt(this, 0, 0, mapdisp);
      }

      Then I do not loose control of the cursor.  What I actually meant from the first was "Loss of cursor".  sorry.    The above code is NOT meant to be a "fix" for my problem.  Just to help be diagnose.  Do you have any suggestion as to what to do?  (1) Have Client::socketReadyRead() emit newData(); "slower"?  (2)have Qpegps::updateData() check lat/long and only call mapDisp->repaint(); if some predefined difference in values from last lat/long gathered by socketReadyRead()?  (3) i am barking up the wrong tree and you have any other hint for me...

       
      • Ralf Haselmeier

        Ralf Haselmeier - 2003-06-06

        Whenever new data arrives from the gpsd, the new map is drawn (createMap) and the display is updated (bitBlt). The gpsd sends the data in a fix intervall (500ms) caused by a QTimer. You may try to change this to a higher value (10s for testing and up to 1s without loosing to much performance on the moving map => value is set in qpegps.cpp).
        BTW I once had a test version, where the update intervall was calculated depending on the relation of speed and scale of the map => in theorie much better, but practically this causes only an improvement if You are using the wrong map for your movement (driving with a map for hiking, hiking with a street (car) map...).
        One improvement would be, if createMap returns if the position (in pixels) has changed (except for pure altitude changes,Balloon,Heli;-)=> but then your cursor problem would depend on the current movement => a constant and unconditioned algrithm is much more reliable.
        In client.cpp is a QPE_DEBUGTIMEDESC. You may use this, to analyse how long it takes to fetch the gps data and to draw the map (this is Qtopia specific, but there might be a similiar one for Qt/embedded or You write your own small function with gettimeofday).
        If I'm completely wrong in this issue (e.g. setting the QTimer to 10s doesn't change anything) just post again and I'll think this over.

         
    • Maria Cruz

      Maria Cruz - 2003-06-09

      I changed time to 10s.  There was an improvement. 

      Also changed MapDisp::createMap() to follow "if createMap returns if the position (in pixels) has changed".  This works fine.  I will deal with the "cursor problem would depend on the current movement" later; if it is a problem.  Here is my code change:

          if (lastPos.longitude && lastPos.longitude) {
            double lastLg,lastLt; 
            /* pmc Return if no position change */
            lastLg = lastPos.longitude * M_PI / 180.0;
            lastLt = lastPos.latitude * M_PI / 180.0;
            if (lastLg == lg &&  lastLt ==  lt) {
              return;
            }
          }
          lastPos.setLat(gpsData->currPos.latitude);
          lastPos.setLong(gpsData->currPos.longitude);   
      etc...

      And I left the 500ms for the GPS time.  Thanks for your advice. 
      maria

       

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks