cell-phone like keyboard driver anywhere?

cell-phone like keyboard driver anywhere?

[Holger Schurig]

I have to write a keyboard driver for a cell-phone like keyboard. I'm just 
wondering if this has been done before.

Basically, the keys are in some x/y matrix. How to decode that can be seen in 
drivers/char/asi_keyboard.c (after applying the patches

ftp://ftp.arm.linux.org.uk/pub/armlinux/source/kernel-patches/v2.4/patch-2.4.18-rmk7.bz2 
ftp://source.mvista.com/pub/xscale/pxa/diff-2.4.18-rmk7-pxa3.gz
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=1187/1

However, this file (as any other that I have seen) assumes that there are 
shift, ctrl, alt etc layers. But a cell-phone like keyboard operates 
differently, e.g.

1 pause -> send keycode for character "a"
1 1 pause -> send keycode for character "b"
1 1 1 pause -> send keycode for character "c"
2 pause -> send keycode for character "d"

and so on.

Has anybody done things in this area?


Holger

Re: cell-phone like keyboard driver anywhere?

[Ingo Oeser]

Hi Holger,

On Wed, Aug 21, 2002 at 09:32:36AM +0200, Holger Schurig wrote:
> I have to write a keyboard driver for a cell-phone like keyboard. I'm just 
> wondering if this has been done before.
> 
> However, this file (as any other that I have seen) assumes that there are 
> shift, ctrl, alt etc layers. But a cell-phone like keyboard operates 
> differently, e.g.
> 
> 1 pause -> send keycode for character "a"
> 1 1 pause -> send keycode for character "b"
> 1 1 1 pause -> send keycode for character "c"
> 2 pause -> send keycode for character "d"

This can be done with counting repeat count of the last key until we
reach the pause (done with a timer, that gets modified after each
key pressed).

If the pause is reached or after each key press you compute the
keycode character that will be sent now.

Cell phones usally do an replacement of the character until you
do the pause or push a different key.

So you would need to play console games, too (changing between
insert and replace mode).

Hope this helps.

Regards

Ingo Oeser
-- 
Science is what we can tell a computer. Art is everything else. --- D.E.Knuth

Re: cell-phone like keyboard driver anywhere?

[Oskar Schirmer]

On Wed, Aug 21, 2002 at 09:32:36AM +0200, Holger Schurig wrote:
> 1 pause -> send keycode for character "a"
> 1 1 pause -> send keycode for character "b"
> 1 1 1 pause -> send keycode for character "c"
> 2 pause -> send keycode for character "d"

IMO this should not be done by the kernel, but by the application.

Reasons:
- actually, there is no key "a" etc that is pressed, but "1" etc.
- you loose ability to keep the display up to date according
  to the pressed key sequence while composing characters, otherwise.
- it is easy for the application to check the timing of the
  keys pressed and produce the desired characters instead [poll (2)].
- not all projects using the keyboard in question will need the
  sequence-to-character conversion You describe. e.g. cash register.

gruesse(oskar)
-- 
oskar schirmer, emlix gmbh, http://www.emlix.com, mailto:os@emlix.com
fon +49 551 37000-37, fax -38, friedländer weg 7, 37085 göttingen, germany

emlix - your embedded linux partner

Re: cell-phone like keyboard driver anywhere?

[Holger Schurig]

> IMO this should not be done by the kernel, but by the application.

One can read such stuff all the time ... but really this is not possible in a 
general way. You don't know in advance if one runs a ncurses, text-only, 
Qt/Embedded or X-Windows application.

> - it is easy for the application to check the timing of the
>   keys pressed and produce the desired characters instead [poll (2)].

Yes, it's easy to put that in a Qt/Embedded app, but what is when the app 
terminates?  You could not restart it via the keyboard, because the keyboard 
is dead. Yeah, it's cumbersome to restart it with a cell-like keyboard, but 
it's possible.



Anyway, I have to write it low-level, in the kernel. I just wondered if 
something like this already exists.

Re: cell-phone like keyboard driver anywhere?

[Holger Schurig]

> The problems that need to be resolved with the kernel approach.  Lets
> look at the '1-1-1' case:
>
> 1. Do you queue the characters "a" "^h" "b" "^h" "c" ?

There is no '1-1-1' case, the case is '1-1-1-pause'. Only after the pause 
would the software (may it be kernel or user-space) know that and what 
character has been meant. At the '1-1-1' state the user might press again a 1 
and then wait, then this might be an '1-pause' case.


The idea is that in the case of '1-1-1-pause' the driver queues exactly one 
character, e.g. the "c".

> 2. How do you handle the case where the app is waiting for one key press
>    only, but the user hits '1' three times?

See 1. The app doesn't see that this key has been hit three times.

> 3. what if the app doesn't want to accept another character into (say)
>    a text field?  The effect of "a" "^h" "b" will always replace the last
>    character.

When the driver would send Backspaces, then yes. Otherwise not.


So we both agree that sending backspaces from a cell-phone-like keyboard 
driver is a bad thing :-)

Re: cell-phone like keyboard driver anywhere?

[Russell King]

I'm sorry, but I find what you just did extremely offensive.  I
specifically did not copy lkml with my reply.  You therefore have
no right to copy bits from my reply and post them to a public forum.

On Fri, Aug 23, 2002 at 12:05:28PM +0200, Holger Schurig wrote:
> > The problems that need to be resolved with the kernel approach.  Lets
> > look at the '1-1-1' case:
> >
> > 1. Do you queue the characters "a" "^h" "b" "^h" "c" ?
> 
> There is no '1-1-1' case, the case is '1-1-1-pause'. Only after the pause 
> would the software (may it be kernel or user-space) know that and what 
> character has been meant. At the '1-1-1' state the user might press again a 1 
> and then wait, then this might be an '1-pause' case.
> 
> The idea is that in the case of '1-1-1-pause' the driver queues exactly one 
> character, e.g. the "c".

Where is the user feedback normally associated with the action of
pressing "1-1-1-pause" ?  Most keypads I know display "a" then "b"
then "c" so the user knows what character they're going to get.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: cell-phone like keyboard driver anywhere?

[Holger Schurig]

> I'm sorry, but I find what you just did extremely offensive.  I
> specifically did not copy lkml with my reply.  You therefore have
> no right to copy bits from my reply and post them to a public forum.

In this case I apologize. I did not wanted to step onto someone toes.

I'll not do this again. Sorry.


> Where is the user feedback normally associated with the action of
> pressing "1-1-1-pause" ?  Most keypads I know display "a" then "b"
> then "c" so the user knows what character they're going to get.

There would be none (maybe a keyboard buzzer).

Re: cell-phone like keyboard driver anywhere?

[Russell King]

On Fri, Aug 23, 2002 at 01:45:34PM +0200, Holger Schurig wrote:
> > Where is the user feedback normally associated with the action of
> > pressing "1-1-1-pause" ?  Most keypads I know display "a" then "b"
> > then "c" so the user knows what character they're going to get.
> 
> There would be none (maybe a keyboard buzzer).

Ok, well, I think there may be an example of one in the -rmk patch (aka
arm) ftp://ftp.arm.linux.org.uk/pub/armlinux/kernel/v2.5

See linux/drivers/char/clps711x_keyb.c

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: cell-phone like keyboard driver anywhere?

[Jan Harkes]

On Fri, Aug 23, 2002 at 09:54:11AM +0200, Holger Schurig wrote:
> > IMO this should not be done by the kernel, but by the application.
> 
> One can read such stuff all the time ... but really this is not possible in a 
> general way. You don't know in advance if one runs a ncurses, text-only, 
> Qt/Embedded or X-Windows application.
> 
> > - it is easy for the application to check the timing of the
> >   keys pressed and produce the desired characters instead [poll (2)].
> 
> Yes, it's easy to put that in a Qt/Embedded app, but what is when the app 
> terminates?  You could not restart it via the keyboard, because the keyboard 
> is dead. Yeah, it's cumbersome to restart it with a cell-like keyboard, but 
> it's possible.

If the app dies, it should drop you in something like a shell that
should probably simply have the same keyboard decoding code. Or maybe
something smarter. It could use the something like my empeg is using
when searching for song titles.

Press 5 (JKL), all songs starting with either j, k, or l will be
selected, and the display shows 'Kind of Magic'. Press 3 (DEF) and it
limits the selection to any songs that have one of those letters in the
second place. Then press 8 (TUV) and we get 'Let It Be'. So with 3
keypresses I just picked a song out of a selection of almost 1000. I
guess Nokia is doing something similar based on a dictionary.

(or drop back into a menu which doesn't even need key translation)

In any case, how the keys are interpreted is very much application
specific, and can be implemented in a userspace library. I really do not
think it is a good idea to put a complete dictionary or other list of
possible completions in kernel space to implement such alternative input
methods.

> Anyway, I have to write it low-level, in the kernel. I just wondered if 
> something like this already exists.

If you really _have_ to write it low-level in the kernel, it sounds like
a class assignment, in which case you really shouldn't be asking for
existing implementations.

Jan

Re: cell-phone like keyboard driver anywhere?

[Holger Schurig]

> Press 5 (JKL), all songs starting with either j, k, or l will be
> selected, and the display shows 'Kind of Magic'. Press 3 (DEF) and it
> limits the selection to any songs that have one of those letters in the

That sounds pretty much like high application stuff. If I had that in my mind, 
I would not have had asked in linux-KERNEL. For an application it's easy to 
have some directory.

The solution you're proposing is good and elegant --- in it's domain. It 
solves one narrow problem. I need a solution that is broader. Your solution 
wouldn't work with Qt/Embedded apps AND X11 apps AND ncurses apps. Maybe 
because your hardware is only used for playing mpegs. But what if the 
computer is used for tn-5250 (ncurses), Konq/Embedded (Qt/Embedded) and Java 
(X11), just as the user pleases?  In this case you need something general, 
and that usually means a kernel driver (because, in our case, there is no 
kernel interface for a user-space program that can inject key codes back into 
the kernel so that the keycodes would be subject of normal 
controlling-tty-handling).

Re: cell-phone like keyboard driver anywhere?

[Jan Harkes]

On Fri, Aug 23, 2002 at 05:10:19PM +0200, Holger Schurig wrote:
> > Press 5 (JKL), all songs starting with either j, k, or l will be
> > selected, and the display shows 'Kind of Magic'. Press 3 (DEF) and it
> > limits the selection to any songs that have one of those letters in the
> 
> That sounds pretty much like high application stuff. If I had that in my mind, 
> I would not have had asked in linux-KERNEL. For an application it's easy to 
> have some directory.
> 
> The solution you're proposing is good and elegant --- in it's domain. It 
> solves one narrow problem. I need a solution that is broader. Your solution 
> wouldn't work with Qt/Embedded apps AND X11 apps AND ncurses apps. Maybe 
> because your hardware is only used for playing mpegs. But what if the 

The hardware in not just used to play mpegs. It is one application that
happens to be running most of the time, and it is the application that
deals with treating the input in such a way.

You want a broader solution, just look at how grafitti input (penstrokes)
is dealt with in for example Qt/Embedded or X11 on the iPaq. No kernel
hacks involved there as far as I can see.

    http://www.handhelds.org/
    http://www.handhelds.org/projects/xscribble.html

Or have a library that intercepts read() from fd 0 which you link
against applications.

Jan

Re: cell-phone like keyboard driver anywhere?

[Thunder from the hill]

Hi,

On Fri, 23 Aug 2002, Holger Schurig wrote:
> But what if the computer is used for tn-5250 (ncurses), Konq/Embedded
> (Qt/Embedded) and Java (X11), just as the user pleases?  In this case
> you need something general, and that usually means a kernel driver

The problem is that most cell phones, if they don't have a keyboard 
themselves, only have 16 keys (0 through 9, *, #, cancel, menu, up/down). 
My cellphonish pocket terminal got its own space-cadet derived keyboard, 
works well. But I don't really thing you'll cope w/only 16 keys.

Otherwise proceed the ugly way it is. 0 through 9 have their usual 
meaning, all the multicodes, menu is say return, C is esc, up/down - well, 
ok, and * and # have any meaning. I see no better way.

			Thunder
-- 
--./../...-/. -.--/---/..-/.-./..././.-../..-. .---/..-/.../- .-
--/../-./..-/-/./--..-- ../.----./.-../.-.. --./../...-/. -.--/---/..-
.- -/---/--/---/.-./.-./---/.--/.-.-.-
--./.-/-.../.-./.././.-../.-.-.-