Re: pyramid display timer/highres issue

On 03.10.2009 10:23, Markus Dolze wrote:
> J=F6rg Hohwieler wrote:
>> Dear all,
>>
>> Pyramid Computer ships an LCD display which is also supported by
>> LCDproc. The driver is called pyramid.
>>
>> The hardware consists of an FTDI chip, thus you've to use the ftdi_sio
>> kernel module to have an usb-to-serial converter.
>>
>> I have some customers that have problems with the display. The customers
>> said the display is very slow, so it doesn't really make fun using it.
>>
>> I also found out that the display doesn't work flawlessly with recent
>> kernels. It is very slow and it seems to be some kind of luck if the
>> server screen comes up. Also some screens won't be shown during rotation.
>>
>> The last kernel that worked perfect was 2.6.20.
>>
>> To get the display working properly with recent kernel I have to
>>
>> - make sure that timer freq. is < 1000 Hz - 100 Hz works best
>>
>> - disable high resolution timers by adding highres=3Doff to kernel cmd
>> line if ACPI is activated in the kernel. Adding acpi=3Doff would also he=
lp.
>>
>> Kernel 2.6.20 worked perfect because it doesn't have the high resolution
>> timers. They were added with kernel 2.6.21.
>>
>> Are there any know issues with lcdproc and this timer issue or is it
>> just related to the pyramid lcd?
>>
>> Is it possible to workaround this problem from within lcdproc?
>>
>>
>> Best regards
>> Joerg Hohwieler
>>   =

> =

> Hi,
> =

> LCDd accesses the pyramid device using a serial port without any special
> timings (unlike i.e. parallel port devices).
> =

> However, there are two timing related parts:
> =

>   1. The pyramid driver uses gettimeofday() to ensure that screen
>      updates to not occur more often than 40 msec.
>   2. LCDd core uses gettimeofday() and usleep() to achieve a frame rate
>      of 8Hz.
> =

> I have not seen any reports about problems with newer kernel versions.
> =

> You may try to use a different driver (e.g. curses) to see if it is a
> problem related to the server core (2 above). You may also try to remove
> the check mentioned in (1 above) - look at
> server/drivers/pylcd.c:pyramid_flush().
> =

> Regards
> Markus


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 too
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	=