Received: by 10.223.185.116 with SMTP id b49csp3169352wrg; Sun, 25 Feb 2018 15:53:42 -0800 (PST) X-Google-Smtp-Source: AH8x227NgOkE35koxy3PGaeoWnYHtaw8AsBgRXyB03+4eiYmsnjJK3ptGIY+D81IQkvdBNGDagKn X-Received: by 10.98.155.93 with SMTP id r90mr8751601pfd.132.1519602822066; Sun, 25 Feb 2018 15:53:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519602822; cv=none; d=google.com; s=arc-20160816; b=ArGKOC8hlcTxJeA/yi5ZtOKpjtqcqUXGELybv9KQkrJ3HerkwVScYiF8bENSP47fWx Qhswih85NgGewSH7Wacw3JZv1U+kvcodFAdNIibNF4TMwGqyfYC1ZcUDCYZrHBHeO10j SVxXlINATLoEIDeMZIBDNIsucqtUacRQsKUmAPtzlY7ji7oXr0MljQ6hq4x/lCBLtlFJ 1kZqX3eg2Pn1bdMZrb8PEfIhIJbZxxgNDwOx0/yf3bOkWJEFS9FjHmnQ7MVrllOhOqmE 0M/a/M+IL7aKWRPW5QawpbAneyd9M37lBcPIpgM6Ah8EWphEjio+Ejn2yg8J7g5EZqSl j4ag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=C6q9dj3tVrQ6VPBpeF+6ntWtoTc2o07FJ5Is8iim5PM=; b=0DOcSo2RS/qYRqSrIjZ+/e2ce05ITPIW0nJwa2v8MFgmOwtoqQm2MqE8efnESynx3C BArnZ/edtHqoWmwPMwelkByB+rnxHvZKtWp9XfnCB89jAYH9h/PLvkaY51XZu1pTrzT0 BFB2a9KDLBA7RcStc3+98/Y+QDNe55aInvJ5UFP91xi/5sYa9G34w6XIah7YxpSxOnTG nj/YPLuqOqilzQCE049XI/9glgLkxqRKFqlvWho94dPJVNFZKwX6/F8BcT+SLGwOHNhR Ft8Uz9DfQwz3n3H3Nr+yPeHmdGT8CtqLyK+hRpLliuK5K+kkJgdzLmseWV4BQz7wwd/9 8Xsg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z4si4760702pgc.367.2018.02.25.15.53.27; Sun, 25 Feb 2018 15:53:42 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751935AbeBYXws (ORCPT + 99 others); Sun, 25 Feb 2018 18:52:48 -0500 Received: from mxf98a.netcup.net ([46.38.249.138]:39752 "EHLO mxf98a.netcup.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751884AbeBYXwr (ORCPT ); Sun, 25 Feb 2018 18:52:47 -0500 Received: from buildbert.robertabel.eu (x4d076501.dyn.telefonica.de [77.7.101.1]) by mxf98a.netcup.net (Postfix) with ESMTPSA id E75A514073B; Mon, 26 Feb 2018 00:52:45 +0100 (CET) Authentication-Results: mxf98a; spf=pass (sender IP is 77.7.101.1) smtp.mailfrom=rabel@robertabel.eu smtp.helo=buildbert.robertabel.eu Received-SPF: pass (mxf98a: connection is authenticated) From: Robert Abel To: linux-kernel Cc: Robert Abel , Miguel Ojeda , Willy Tarreau , Geert Uytterhoeven , Andy Shevchenko Subject: Re: [PATCH 1/3] auxdisplay: charlcd: fix hex literal ranges for graphics command Date: Mon, 26 Feb 2018 00:52:32 +0100 Message-Id: <20180225235236.31162-1-rabel@robertabel.eu> X-Mailer: git-send-email 2.11.0 In-Reply-To: <9ec3c54c-f8fe-22d7-783e-8cf9862405bb@robertabel.eu> References: <9ec3c54c-f8fe-22d7-783e-8cf9862405bb@robertabel.eu> X-PPP-Message-ID: <20180225235246.31196.58550@mxf98a.netcup.net> X-PPP-Vhost: robertabel.eu Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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