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 =