Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CD5220 driver very blinky #105

Open
vladkorotnev opened this issue Sep 2, 2018 · 2 comments
Open

CD5220 driver very blinky #105

vladkorotnev opened this issue Sep 2, 2018 · 2 comments

Comments

@vladkorotnev
Copy link

The title says it all. The CD5220 driver seems to redraw the whole screen every frame, so the display is very stuttery. Possibly it's needed to calculate the difference between frames and upload just that.

I have written a Mac driver for my CD7220 display back in the day which doesn't have the issue: https://bitbucket.org/vladkorotnev/vfd-osx/src/master/

However, I'm not sure if it's possible to backport that into lcdproc?

@shenghaoyang
Copy link
Contributor

shenghaoyang commented Sep 2, 2018

Hi!

Thanks for reporting this issue. I did write the CD5220 driver recently, and this behaviour is really a compromise to function on as many displays as possible. I presume you're running a build straight off the master branch?

CD5220 driver very blinky

Possibly it's needed to calculate the difference between frames and upload just that.

The redraw here is implemented using the atomic display line update commands, and they seem to enable the display to update without having to observe the sequential update of the screen from left to right when sending characters directly.
The driver does do delta updates, but always at least updates a whole line instead of a single character.

The problem here is that multiple displays emulate the CD5220 protocol and do it in many different ways. Some are slower, and drop characters when you perform delta updates, while some can keep up. Also, remember that this a serial link with no error detection and correction, for the most part. (Unless your display is actually USB driven, with no USB to serial converter built-in to the display) - you're bound to get data corruption sometime. Sending a whole line helps ensure that no data is lost. Even in the event that some characters are dropped, they may get sent again when another update comes around for the same line.

Some logic to fully redraw the screen every few delta updates can deal with data loss / dropped characters in the event that we're doing delta updates on the single character level - but your display would flash during the full screen update anyway, so I'm not really sure of the benefits.

I'm not really keen about increasing the complexity of the driver to calculate and perform single character delta updates - you need some cost evaluation there, and it can get quite messy - Unless this is indeed implemented in some generic way that can be shared among all the serialPOS drivers and toggled on and off. Otherwise we'd have some bloat in the CD5220 driver even though this concept is something that can be applied to most displays capable of it.

Now, you could do a few things to mitigate the issue:

  • Lowering the brightness might help to reduce the flashing effects (try sending the backlight off command from your client). The driver now alternates between max and min brightness when the backlight on / off commands are sent, but some configuration options to change that can be added, if this workaround seems okay for you.

  • Increasing the screen update interval in LCDd may help as well.

Let me know if this helps.

Shenghao

@haraldg
Copy link
Collaborator

haraldg commented Jun 8, 2019

I guess working on issue #75 would help with this issue a lot too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants