Re: pyramid display timer/highres issue

Jörg Hohwieler <[email protected]> Thu, 13 Feb 2014 08:38:35 +0100
Newsgroups gmane.comp.sysutils.lcdproc
Message-ID <[email protected]>
On 12.02.2014 21:19, Markus Dolze wrote:
> On 11.02.2014 15:11, J=F6rg Hohwieler wrote:
>> On 13.01.2014 21:20, Markus Dolze wrote:
>>> On 09.01.2014 12:52, J=F6rg Hohwieler wrote:
>>>> It's a long time since I started this thread, but finally I found a
>>>> solution.
>>>>
>>>> --- pylcd.c.orig        2013-11-19 13:02:20.733699143 +0100
>>>> +++ pylcd.c     2013-11-19 13:02:28.629900897 +0100
>>>> @@ -208,7 +208,7 @@ real_send_tele(PrivateData *p, char *buf
>>>>      write(p->FD, buffer2, len);
>>>>
>>>>      /* Take a little nap. This works as a pacemaker */
>>>> -    usleep(50);
>>>> +    usleep(30000);
>>>>
>>>>      return 0;
>>>>  }
>>>>
>>>>
>>>> Before introduction of high resolution timers I think the timer
>>>> granularity was not fine enough for usleep(50). So I guess usleep(50)
>>>> took always much more time than intended.
>>>>
>>>> With introduction of highres timers the granularity became much finer,
>>>> resulting in the intended sleep time of usleep(50).
>>>>
>>>> Running with usleep(50) the displays processor becomes overloaded as t=
oo
>>>> much commands are coming in.
>>>>
>>>> Running the kernel now with highres=3Doff and usleep(30000) behaves the
>>>> same as with highres=3Don.
>>>>
>>>> Btw, I've determined the value empirically but it seems to be fine.
>>>>
>>>> Please include my patch above.
>>>>
>>>> thank you.
>>>>
>>>>
>>>> Best regards
>>>> Joerg	=

>>>>
>>>
>>> Hi J=F6rg,
>>>
>>> I will be happy to commit this. Before that I'd like to test with some
>>> 'non Linux' OS. Just for curiosity.
>>>
>>> Regards,
>>> Markus
>>>
>>
>> Hi Markus,
>>
>> were you able to run some tests on "non linux" systems?
>>
>>
>> Best regards
>> Joerg	=

>>
> =

> Hello J=F6rg,
> =

> sorry - I almost forgot about this.
> =

> Yes, I tested with the longer delay and was not really happy with it.
> Updating the LCD slows down a lot. Title scrolling and fast changing bar
> graphs like the CPU screen slow down noticeable.
> =

> If we need this longer delay, I suggest to make it a configuration
> option (e.g. delay in ms) so users can adjust as necessary.
> =

> Regards,
> Markus
> =


Hi Markus,

can you please describe your test environment (OS details and lcdproc
screen configuration) ?


Thank you.	=



Best regards
Joerg	=