Messages in this thread | | | From | Robert Abel <> | Subject | Re: [PATCH 1/3] auxdisplay: charlcd: fix hex literal ranges for graphics command | Date | Mon, 26 Feb 2018 00:52:32 +0100 |
| |
The following patch set fixes the x/y coordinate addressing issue I mentioned earlier as well as not marking the two-line command sequence as processed resulting in a confusing state.
I implemented the logic around using kstrtoul by terminating the substrings that contain numbers for each command separately and then restoring the command character following the number that was overwritten.
Additionally, the code now doesn't write live to the x and y address fields and will bail out if an unknown command character or an invalid number was encountered.
I did try to keep it backwards compatible, so sequences of the form ^[[Lx0y1x2y4; will still work (and result in x2y4).
Additionally, I noticed that the ^[[H home function was just resetting the x/y coordinates but not the display shift, which results in a situation where the display cannot be programmatically unshifted (except for init ^[[LI). So I implemented the HOME command 0x02 for charlcd_home. The old behavior can be simulated using ^[[Lx0y0; (just reset x/y, don't unshift).
I tested on my Raspberry Pi Zero W with a clone 1602 display.
Robert Abel (4): auxdisplay: charlcd: fix two-line command ^[[LN not marked as processed auxdisplay: charlcd: name x/y address struct auxdisplay: charlcd: fix x/y address commands auxdisplay: charlcd: make home command unshift display
drivers/auxdisplay/charlcd.c | 76 ++++++++++++++++++++++++++++++++++---------- 1 file changed, 60 insertions(+), 16 deletions(-)
-- 2.11.0
| |