From mboxrd@z Thu Jan  1 00:00:00 1970
From: Eric Nelson <eric.nelson@boundarydevices.com>
Date: Sat, 24 Mar 2012 15:39:56 -0700
Subject: [U-Boot] [PATCH] i.MX6: mx6qsabrelite: Add keypress support
In-Reply-To: <4F6D740B.40903@googlemail.com>
References: <1330732824-15345-1-git-send-email-eric.nelson@boundarydevices.com>
	<201203030318.25048.marex@denx.de>
	<4F52390C.4080108@boundarydevices.com>
	<20120303154851.823CC126F3B0@gemini.denx.de>
	<4F523DF9.90502@boundarydevices.com>
	<4F6D740B.40903@googlemail.com>
Message-ID: <4F6E4D3C.2020607@boundarydevices.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On 03/24/2012 12:13 AM, Dirk Behme wrote:
> Hi Eric,
>
> On 03.03.2012 16:51, Eric Nelson wrote:
>> On 03/03/2012 08:48 AM, Wolfgang Denk wrote:
>>> Dear Eric Nelson,
>>>
>>> In message<4F52390C.4080108@boundarydevices.com> you wrote:
>>>>
>>>>> Why not make it an STDIN device as any other keyboard?
>>>>>
>>>> Is there a non-blocking read from stdin available to boot script?
>>>>
>>>> How would we represent keys like "Menu", "Home", "Volume up" and
>>>> "Volume down"?
>>>>
>>>> Through ANSI escape sequences?
>>>
>>> No. You don't have to. Mapping key presses to functions (bind them to
>>> commands) is a different thing. Keys could be "1", "2", "3" and "4",
>>> and could be mapped to "run cmd_1", ... "run cmd_4" respectively.
>>> Then the user can define what "cmd_1" etc. does.
>>>
>> That's perfect. All that's left is the details...
>
> Do you plan an update of this patch?
>

Yes I do. I'm just having trouble finding time these days.

And I seem to be buttonless (without a button board) at the moment.

I even have a fledgling README for keyboard support so the next person
can find out what to do with grep!

Regards,


Eric