Resend II(SMTP Server Issues) : keypad support question and patch.

[Denis 'GNUtoo' Carikli]

Hi,

I tried many times to find a good way to integrate our keypad driver
for the calypso platform, but each time that I grep the source I don't
succeed at finding a good example for integrated keyboard/keypad
drivers that is similar enough to ours.

There seem to be an hid keyboard in
nuttx/drivers/usbhost/usbhost_hidkbd.c, but that's for USB keyboards
and we have a platform specific keypad controller...
Beside it has a public function named usbhost_kbdinit which makes it
sounds like the fact that there is no generic kbdinit. Despite of all
theses problems, should I clone and adapt this driver to our specific
keypad?

I've compiled hexdump and tried it against /dev/keypad produced by our
driver, and it produced the following output while pressing a key
multiples times(it produces a different letter for a different key):
0000: 69 i
/dev/keypad at 0000023d:
0000: 49 I
/dev/keypad at 0000023e:
0000: 69 i
/dev/keypad at 0000023f:
0000: 49 I

I've also found that in shenzhou/nxwm/defconfig in the old config
system(Alan should work on the new Kconfig system for our devices, I'm
not sure of the status of his work):
#
# Keyboard device settings
#
CONFIG_NXWM_KEYBOARD_DEVPATH="/dev/console"
CONFIG_NXWM_KEYBOARD_SIGNO=6
CONFIG_NXWM_KEYBOARD_BUFSIZE=16
CONFIG_NXWM_KEYBOARD_LISTENERPRIO=50
CONFIG_NXWM_KEYBOARD_LISTENERSTACK=1024

But that's for NXWM,however it takes a dev path... and the driver we
have produces some characters, obviously it has to be fixed to produce
the right characters/numbers.

I've attached the current keypad driver.

Beside that I've a small compilation fix for the calypso platform,
using the old config system.

Denis.

[Gregory N]

Hi, Denis,

Post by Denis 'GNUtoo' Carikli
I tried many times to find a good way to integrate our keypad driver
for the calypso platform, but each time that I grep the source I don't
succeed at finding a good example for integrated keyboard/keypad
drivers that is similar enough to ours.

This is a really good topic and I think it points to an area in NuttX that has not really been thought through very carefully. It has not gotten very much attention because there are not very many good keyboards for embedded devices out there.

Post by Denis 'GNUtoo' Carikli
There seem to be an hid keyboard in
nuttx/drivers/usbhost/usbhost_hidkbd.c, but that's for USB keyboards
and we have a platform specific keypad controller...
Beside it has a public function named usbhost_kbdinit which makes it
sounds like the fact that there is no generic kbdinit. Despite of all
theses problems, should I clone and adapt this driver to our specific
keypad?

Yes, the HID keyboard is one example. The driver is at drivers/usbhost/usbhost_hidkbd.c. When a USB HID keyboard is attached, it will export a character device like /dev/kbda. There is a test for the HID keyboard here: apps/examples/hidkbd

I believe that the problem with this driver is that is does not support most keyboard functionality -- just raw ASCII input. Inside of usbhost_hidkbd.c, you can see that (1) usbhost_kbdpoll() periodically samples for keyboard data and usbhost_mapscancode() maps the keyboard scan codes into ASCII values that could be understood by a program reading from the character driver at /dev/kbda.

What is wrong with that? Well, it loses most of the important functionality of a keyboard such as cursor control characters, function keys, etc.. The full set of keyboard scan codes are given in include/nuttx/usb/hid.h; only a fraction of these are understood by /dev/kbda.

So I think first of all what is missing is a system definition of what a keyboard driver is and how an application interacts with it. Perhaps it is a character driver that understands VT100 escape sequences? Perhaps it could be standardized that all keyboards map to VT100 escape sequences (as in include/nuttx/vt100.h). That might be do-able. Then every keyboard driver would have to contain a VT100 encoder and every application that uses a keyboard driver would have to contain a VT100 decoder???

I think that is the first definition that I would put on the table.

Post by Denis 'GNUtoo' Carikli
I've compiled hexdump and tried it against /dev/keypad produced by our
driver, and it produced the following output while pressing a key
0000: 69 i
0000: 49 I
0000: 69 i
0000: 49 I

Yes, from what you say here, I think you could produce a non-USB driver very similar to the USB HID keyboard driver that maps these codes to ASCII codes. Extending the interface to handle cursor controls still needs an interface definition. The VT100 proposal is the only one on the table for now, but perhaps your email will stir up some better opinions.

Post by Denis 'GNUtoo' Carikli

Post by Denis 'GNUtoo' Carikli
I've also found that in shenzhou/nxwm/defconfig in the old config

system(Alan should work on the new Kconfig system for our devices, I'm
#
# Keyboard device settings
#
CONFIG_NXWM_KEYBOARD_DEVPATH="/dev/console"
CONFIG_NXWM_KEYBOARD_SIGNO=6
CONFIG_NXWM_KEYBOARD_BUFSIZE=16
CONFIG_NXWM_KEYBOARD_LISTENERPRIO=50
CONFIG_NXWM_KEYBOARD_LISTENERSTACK=1024
But that's for NXWM,however it takes a dev path... and the driver we
have produces some characters, obviously it has to be fixed to produce
the right characters/numbers.

This is for a virtual keyboard using a touchscreen. But it is really still the same discussion at a little different level.

There are really two different use cases for the the keyboard driver. One is a simple character driver replacement for stdin. That is what usbhost_hidkbd.c basically does.

The other use cases is in a graphics environment with windows and widgets. In this case, keyboard input must be sampled and then "injected" into the graphics system. In most cases, this requires a "keyboard listener thread":

http://nuttx.org/Documentation/NxWM-ThreadingModel.pdf
http://sourceforge.net/p/nuttx/code/5394/tree/trunk/NxWidgets/nxwm/src/ckeyboard.cxx

The NX layer will then re-direct the keyboard input to the "highest" window (the window with "focus"). The NxWidget layer will then further redirect the keyboard input to the specific, highlighted Widget that has focus. This is all just filtering logic and does not change the underlying nature of the keyboard problem:

If the final widget that has focus is an edit box: It needs to be able to receive new text data to add to the text box and it needs to receive new cursor controls to be able to edit the text. So some data representation (VT100?) is still required.

Inside of NxWidgets, it understands the fundamental difference between raw keyboard input and cursor controls. The virtual keyboards know how to make this distinction. But NxWidgets does not know how to take a data stream (VT100?) containing multiplexed cursor control and ASCII data.

Post by Denis 'GNUtoo' Carikli
I've attached the current keypad driver.
Beside that I've a small compilation fix for the calypso platform,
using the old config system.

I don't see the attachment. I would be willing to spend some time get a proper definition of a keyboard interface. I think this is important to some of the longer range NuttX goals.

Greg

[Denis 'GNUtoo' Carikli]

On Tue, 27 Nov 2012 18:48:08 -0000

Post by Gregory N
I don't see the attachment.

Sorry I got some SMTP problem and forgott to re-attach.

Now if this mail arrives they should be inside.

Denis.

[Gregory N]

Hi, Denis,

Post by Denis 'GNUtoo' Carikli

Post by Gregory N
I don't see the attachment.

Sorry I got some SMTP problem and forgott to re-attach.
0001-Calypso-keypad-driver.patch

There is one hunk from this patch that I did not check in. That is this one:

diff --git a/nuttx/arch/arm/src/common/up_initialize.c b/nuttx/arch/arm/src/common/up_initialize.c
index 80f9b11..8c792e3 100644
--- a/nuttx/arch/arm/src/common/up_initialize.c
+++ b/nuttx/arch/arm/src/common/up_initialize.c
@@ -194,4 +194,8 @@ void up_initialize(void)

up_usbinitialize();
up_ledon(LED_IRQSENABLED);
+
+ /* Initialize the keypad driver */
+ calypso_armio();
+ up_keypad();
}

I did not check the change in because it would cause other ARM builds that use the same common/up_initialize.c to fail to build. I am sorry if this causes a problem for you.

Will you be able to call these initialization functions from your application start-up logic? Let me know know how I can help with this.

Also, I did run the keypad driver, arch/arm/src/calypso/calypso_keypad.c through the NuttX pretty printer at tools/indent.sh. So the code will probably look different to you! It should be the same.

It seems that the Calypso port is evolved a little differently than the other ports. For other ports, the logic under arch/arm/src/ contains the MCU-only logic. Board-related logic is in configs/board/src. But it looks like Calypso will treat the whole phone as the platform in arch/arm/src/calypso. I do not see any problem with that, it is just a little different.

Post by Denis 'GNUtoo' Carikli
0002-Fix-building-the-old-way-tough-of-the-calypso-platfo.patch

There were several additional places where -wstrict-prototypes instead of -Wstrict-prototypes was used. Thanks for pointing that out.

Greg

[Gregory N]

Denis,

Post by Gregory N

Post by Denis 'GNUtoo' Carikli
0001-Calypso-keypad-driver.patch

diff --git a/nuttx/arch/arm/src/common/up_initialize.c b/nuttx/arch/arm/src/common/up_initialize.c
index 80f9b11..8c792e3 100644
--- a/nuttx/arch/arm/src/common/up_initialize.c
+++ b/nuttx/arch/arm/src/common/up_initialize.c
@@ -194,4 +194,8 @@ void up_initialize(void)
up_usbinitialize();
up_ledon(LED_IRQSENABLED);
+
+ /* Initialize the keypad driver */
+ calypso_armio();
+ up_keypad();
}
I did not check the change in because it would cause other ARM builds that use the same common/up_initialize.c to fail to build. I am sorry if this causes a problem for you.
Will you be able to call these initialization functions from your application start-up logic? Let me know know how I can help with this.

One thing that you might want to do is to use your own, private initialization routine:

1) Copy arch/arm/src/common/up_initialize.c to arch/arm/src/calypso/calypso_initialize.c

2) Modify calypso_initialize.c as for the above path, and

3) Change arch/arm/src/calypso/Make.defs so that it uses calypso_initialize.c instead of up_initialize.c.

Let me know if you would like to go that route.

Greg

[Denis 'GNUtoo' Carikli]

On Thu, 29 Nov 2012 14:36:35 -0000

Post by Gregory N

Post by Gregory N
+
+ /* Initialize the keypad driver */
+ calypso_armio();
+ up_keypad();
}
I did not check the change in because it would cause other ARM
builds that use the same common/up_initialize.c to fail to build.
I am sorry if this causes a problem for you.
Will you be able to call these initialization functions from your
application start-up logic? Let me know know how I can help with
this.

1) Copy arch/arm/src/common/up_initialize.c to
arch/arm/src/calypso/calypso_initialize.c
2) Modify calypso_initialize.c as for the above path, and
3) Change arch/arm/src/calypso/Make.defs so that it uses
calypso_initialize.c instead of up_initialize.c.
Let me know if you would like to go that route.

So there are multiples routes:
1) the one Just described above.
2) using the same function names than the USB keyboard driver.
3) waiting for a common keyboard abstraction and using that once ready,

I wonder if 2) is the best one for now.

Denis.

[Gregory N]

Hi, Denis,

Post by Denis 'GNUtoo' Carikli
1) the one Just described above.
2) using the same function names than the USB keyboard driver.
3) waiting for a common keyboard abstraction and using that once ready,
I wonder if 2) is the best one for now.

Some device initialization is critical and must be done early in the boot up phase, other initialization can be done later. NuttX three times for MCU/board specific initialization.

1) First at power-up, some very low level initialization is called to setup up clocking and debug UART support, etc. Very low level stuff.

2) After the basic OS is initialized (memory, semaphores, interrupt dispatching, etc), then the OS calls up_initialize() to give the MCU logic another chance at early initialization. This is normal still pretty low level stuff like initializing the system timer. But a lot of unnecessary stuff has crept into up_initialize() like networking and USB. Those really do not need to be initialized so soon.

3) Finally, the application is started and the application has another chance to perform initialization with everything up and running.

In the case of the USB HID keyboard, all of the initialization is performed at the application level. Look at apps/examples/hidkbd/hidbkd_main.c. You can see that all of the initialization of the HID keyboard is performed in the first few lines of hidkbd_main().

Greg

[Denis 'GNUtoo' Carikli]

On Fri, 30 Nov 2012 13:14:58 -0000

Post by Gregory N
Hi, Denis,

Post by Denis 'GNUtoo' Carikli
1) the one Just described above.
2) using the same function names than the USB keyboard driver.

That was a bad idea: the application that uses the USB host driver seem
USB specific.
However I've copied the USB keyboard things to make a keypad
abstraction and an application that opens the keypad(based on the USB
keyboard application and abstraction).

The code is not clean enough, I'll cleanup and send it.

Then the next step would be to make it output the correct keys.

Denis.

[Denis 'GNUtoo' Carikli]

On Sat, 1 Dec 2012 00:03:41 +0100

Post by Denis 'GNUtoo' Carikli
The code is not clean enough, I'll cleanup and send it.

Here it is.

Denis.

[Gregory Nutt]

Hi, Denis,

Post by Denis 'GNUtoo' Carikli

Post by Denis 'GNUtoo' Carikli
The code is not clean enough, I'll cleanup and send it.

Here it is.

Checked in!  I made three changes:

1) I moved include/nuttx/keypad.h to include/nuttx/input/keypad.h.  I set up the nuttx input directory to hold header files for input devices:  touchscreens, pointing devices, keypads, etc.  So I think the keypad.h belongs there.

2) I removed CONFIG_EXAMPLES_KEYPADTEST_BUILTIN and used CONFIG_NSH_BUILTIN_APPS instead.  I have been slowly making this change to all other configurations so I did not want to introduce another case.  I think that just having one NSH built-in indication is sufficient.

3) I removed the loop that retries opening the the keypad device in keypadtest_main.c.  This is left over from the port of the USB keyboard example.  USB is different: The target might be powered up with no keyboard connected.  In that case, it will just try to open the keyboard device until the USB keyboard is eventually plugged in.  That retry logic does not make sense for built-in keypads.  If you fail to open the keypad driver once, it should not succeed later. 




Thanks.  I like the general approach.  As time goes by, I will probably extend this basic keypad/keyboard definition as well.

I struggle some with the semantics of a "keypad" versus a "keyboard".  I think from a user perspective, the difference is obvious:  A keyboard is larger and has the standard alphanumeric, function, key, cursor controls.  While a keypad is smaller and more specialized.

But, from the standpoint of the embedded firmware, I don't think there is any functional difference between a keypad and a keyboard.  I suppose I shouldn't let such things bother me.

Greg

[Denis 'GNUtoo' Carikli]

On Sat, 1 Dec 2012 07:54:47 -0800 (PST)

Thanks.  I like the general approach.  As time goes by, I will
probably extend this basic keypad/keyboard definition as well.

ok, I think I need something for feature phones buttons too, like
include/linux/input.h in the linux kernel:
I think some definition of some buttons like KEY_UP, KEY_LEFT,
KEY_RIGHT, KEY_DOWN and maybe also some keys for hanging up and picking
calls(if possible).

A picture of the c155 can be found here:
Loading Image...

I think I should wait for the keyboard abstraction, and work on making
the key output something better when its done.
Currently pressing on the key labeled 2ABC produces a 'c' and releasing
it produces a 'C'.
However a good(for my use case) keyboard abstraction would handle
pressing and releasing keys.
By the way:
* what to do with other non-standard keys? (such as call/hangup)
* what to do with the fact that the key has several labels: the 2 key
has 2,A,B,C. where should that be handled? in the driver or in the
application?
* what to do with the modifiers if they are on a multi-label key?

But, from the standpoint of the embedded firmware, I don't think
there is any functional difference between a keypad and a keyboard.
I suppose I shouldn't let such things bother me.

yes, Stefan Richter wrote it like that,when there was probably no
keyboard in nuttx and no keyboard abstraction either, and even no
graphical user interface.
Then I forgot to change it in keyboard despite the fact that nuttx
changed over time and now have a keyboard driver.

Denis.

[Gregory N]

Hi, Denis,

Post by Denis 'GNUtoo' Carikli

Thanks. I like the general approach. As time goes by, I will
probably extend this basic keypad/keyboard definition as well.

ok, I think I need something for feature phones buttons too, like
I think some definition of some buttons like KEY_UP, KEY_LEFT,
KEY_RIGHT, KEY_DOWN and maybe also some keys for hanging up and picking
calls(if possible).
http://bb.osmocom.org/trac/attachment/wiki/nuttx-bb/c155.JPG
I think I should wait for the keyboard abstraction, and work on making
the key output something better when its done.
Currently pressing on the key labeled 2ABC produces a 'c' and releasing
it produces a 'C'.
However a good(for my use case) keyboard abstraction would handle
pressing and releasing keys.
* what to do with other non-standard keys? (such as call/hangup)
* what to do with the fact that the key has several labels: the 2 key
has 2,A,B,C. where should that be handled? in the driver or in the
application?
* what to do with the modifiers if they are on a multi-label key?

This is the topic that I was trying to address in my original response: http://tech.groups.yahoo.com/group/nuttx/message/3171

Essentially, a keyboard/keypad needs a way of encoding information for different usages. There is a fundamental difference between text input and cursor control inputs. But there has to be some standard way of marshaling this various information into a byte stream: Encoding information as necessary and decoding it again at the other end as needed. Escape encoding is pretty standard way of doing this.

That is why I propose using VT100 escape encoding in that earlier email. There are already VT100 dependencies in NuttX (like readline()), so I don't have any problem saying that we will encode this "out of band" information as VT100 escape sequences.

Some of the encodings in include/nuttx/vt100.h, map okay for what your are trying to do:

#define VT100_CURSORUP(n) {ASCII_ESC, '[', (n), 'A'} /* Move cursor up n lines */
#define VT100_CURSORDN(n) {ASCII_ESC, '[', (n), 'B'} /* Move cursor down n lines */
#define VT100_CURSORRT(n) {ASCII_ESC, '[', (n), 'C'} /* Move cursor right n lines */
#define VT100_CURSORLF(n) {ASCII_ESC, '[', (n), 'D'} /* Move cursor left n lines */

But I don't seen anything like call or hang-up, perhaps functions keys?

The 2,A,B,C usage is purely context driven, right. There is nothing different in the way that the keypad driver works in these cases. Rather the application interprets the "2" be "2" in one case and "A", "B", or "C" in another case.

The USB HID interface solves the modifier problem by always providing the state of modifier keys in every USB report (shift, control, alt). The driver can then discriminate "C", from "c", from "^C" using those modifiers. I assume that your keypad would work the similarly. If a modifier key is processed, then your driver would report a different value. Would that make sense?

Obviously, I have not thought through all of the issues. I toss out the idea of using VT100 encoding only because I have no other real option to suggest.

Greg

[Denis 'GNUtoo' Carikli]

On Sat, 01 Dec 2012 22:07:51 -0000

Post by Gregory N
This is the topic that I was trying to address in my original
response: http://tech.groups.yahoo.com/group/nuttx/message/3171

Sorry I forgott that.

Post by Gregory N
Essentially, a keyboard/keypad needs a way of encoding information
for different usages. There is a fundamental difference between text
input and cursor control inputs. But there has to be some standard
Encoding information as necessary and decoding it again at the other
end as needed. Escape encoding is pretty standard way of doing this.
That is why I propose using VT100 escape encoding in that earlier
email. There are already VT100 dependencies in NuttX (like
readline()), so I don't have any problem saying that we will encode
this "out of band" information as VT100 escape sequences.

yes, however I've some issues with it, would it be possible to add a
sentinel('\0') to the defines in order to be able to uses functions such
as strlen on the defines?
The issue is that I've to map a key(like 'a'),at runtime and not in
the definitions of variables, to something like VT100 that has an
unknown number of elements.
For instance doing a switch case like that isnt't allowed by C:
char[] key;
case 'a':
//somehow assign VT100_FOO to the variable key
break;
case 'b'
//somehow assign VT100_BAR to the variable key
break;
Else I guess I'll have to use less straightforward methods.
How to handle key press and release?

Denis.

[Michael Smith]

Post by Denis 'GNUtoo' Carikli
Else I guess I'll have to use less straightforward methods.

The "less straightforward" methods are sometimes easier. If your keypad has a relatively small number of keys, a single byte can be sufficient to encode everything you need; e.g. 3 bits gives you 8 distinct prefixes, and then 5 bits for prefix-specific data.

Post by Denis 'GNUtoo' Carikli

Post by Gregory N
Some of the encodings in include/nuttx/vt100.h, map okay for what

How to handle key press and release?

If your model requires this to implement more than auto-repeat, then the serial-terminal model isn't going to work for you and you are going to be better off moving to a variant of the HID encoding.

Something that is worth considering though; this is really outside the remit of a system like NuttX unless Greg is serious about adding a HID-style input layer to NX. You are quite possibly going to be better off running a pipe directly from your keypad driver to whatever event dispatcher you're using and keep the key encodings private to your application(s).

= Mike

[Gregory N]

Post by Michael Smith

Post by Denis 'GNUtoo' Carikli
Else I guess I'll have to use less straightforward methods.

The "less straightforward" methods are sometimes easier. If your keypad has a relatively small number of keys, a single byte can be sufficient to encode everything you need; e.g. 3 bits gives you 8 distinct prefixes, and then 5 bits for prefix-specific data.

Post by Denis 'GNUtoo' Carikli

Post by Gregory N
Some of the encodings in include/nuttx/vt100.h, map okay for what

How to handle key press and release?

If your model requires this to implement more than auto-repeat, then the serial-terminal model isn't going to work for you and you are going to be better off moving to a variant of the HID encoding.
Something that is worth considering though; this is really outside the remit of a system like NuttX unless Greg is serious about adding a HID-style input layer to NX. You are quite possibly going to be better off running a pipe directly from your keypad driver to whatever event dispatcher you're using and keep the key encodings private to your application(s).

Of course, I would rather see an opaque, re-usable interface. I would like to see any keyboard driver connectable to any application that understands a common keyboard interface. As an OS guy, that is the only kind of solution that is of personal interest to me.

Certainly, there is nothing wrong with transparent interface where the keyboard driver and the application are matched and have internal knowledge of each other. That might be the right solution for you, but it is not of interest to me and does not advance NuttX.

Greg

[Gregory N]

Hi, Denis,

Post by Denis 'GNUtoo' Carikli

Post by Gregory N
This is the topic that I was trying to address in my original
response: http://tech.groups.yahoo.com/group/nuttx/message/3171

Sorry I forgott that.

Post by Gregory N
Essentially, a keyboard/keypad needs a way of encoding information
for different usages. There is a fundamental difference between text
input and cursor control inputs. But there has to be some standard
Encoding information as necessary and decoding it again at the other
end as needed. Escape encoding is pretty standard way of doing this.
That is why I propose using VT100 escape encoding in that earlier
email. There are already VT100 dependencies in NuttX (like
readline()), so I don't have any problem saying that we will encode
this "out of band" information as VT100 escape sequences.

yes, however I've some issues with it, would it be possible to add a
sentinel('\0') to the defines in order to be able to uses functions such
as strlen on the defines?
The issue is that I've to map a key(like 'a'),at runtime and not in
the definitions of variables, to something like VT100 that has an
unknown number of elements.
char[] key;
//somehow assign VT100_FOO to the variable key
break;
case 'b'
//somehow assign VT100_BAR to the variable key
break;
Else I guess I'll have to use less straightforward methods.

Post by Gregory N
Some of the encodings in include/nuttx/vt100.h, map okay for what

I have finished an implementation of this. VT100 is a particularly bad encoding because although VT100 is a terminal (what they used to call a "smart" terminal), it really is more of an output device than an input device.

And, if you think about it more, the nature of the internal encoding should not matter: There matched encoders on the driver side and decoders on the user side and it doesn't matter what the encoding is inbetween (as long as it does not interfere with normal data transfer).

There is a blurb here:

http://www.nuttx.org/Documentation/NuttxPortingGuide.html#kbddriver

Relevant files:

include/nuttx/input/kbd_codec.h
libc/misc/lib_kbd*.c
drvers/usbhost/usbhost_hidkbd.c
apps/examples/hidkbd

Post by Denis 'GNUtoo' Carikli
How to handle key press and release?

I have not addressed that, but it is really just another class of encoding. That should be easy to extend.

Right now kbd_get return status as a return value and the character via a pointer parameter.

0 - if the value is a a keypress. The character is the ASCII equivalent of the key.

1 - if the value is a special key. The character is a value from an enumeration describing the special key.

There is no reason why it could not return a value like

2 - A key release event. The character could be the released key.

I'll change the definition like this now (but I won't update the HID keyboard driver now).

Greg

[Gregory N]

Post by Gregory N
2 - A key release event. The character could be the released key.
I'll change the definition like this now (but I won't update the HID keyboard driver now).

Done .. http://www.nuttx.org/Documentation/NuttxPortingGuide.html#kbddriver

Greg