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
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
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:[email protected]
fon +49 551 37000-37, fax -38, friedl?nder weg 7, 37085 g?ttingen, germany
emlix - your embedded linux partner
> 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.
> 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 :-)
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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
> 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).
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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
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
> 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).
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
--
--./../...-/. -.--/---/..-/.-./..././.-../..-. .---/..-/.../- .-
--/../-./..-/-/./--..-- ../.----./.-../.-.. --./../...-/. -.--/---/..-
.- -/---/--/---/.-./.-./---/.--/.-.-.-
--./.-/-.../.-./.././.-../.-.-.-
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