Mobile phone keypad driver

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi,

We are developing a keypad driver for a mobile phone like device. Like
as usual mobile phone keypad, we need to support two modes of
operation.
-- dialling mode- Repeatedly pressing key 1 in this modes causes 111111

-- text mode (sms) - There is a key group associated with each key. For
key 2, pressing it continuously causes 2,a,b,c,A,B,C sequence.

The details of the mode is dependent on the application scenario.
Whether we are in a dialling application or SMS application.

So our question is how we manage this? What is the usual way of doing
this? The driver provides the key code or just the scan code
corresponding to the key pressed? We need to give support for GTK+ on
this interfaces and run minimo browser over it.  Setting the mode in
the driver and converting to key codes there means we have to provide a
custom IOCTL to set mode. Is that the standard way of doing it? Won't
that require changes in the GTK+/ minimo for this?

We'll be grateful for any help/suggestions/web links in this matter.
Thanking you,
Liz


Re: Mobile phone keypad driver
Do you really want to do this in the Kernel mode device driver driver ?

IMHO, the Kernel mode device driver should be as small and as "simple"
as possible (as it's harder to test a driver than testing a user mode
application).

My suggestion is to have the driver issue a as well a key-up as a key
down event together with some kind of time stamp or perhaps only the
key-up event together with a duration indication. These events can go
into a FiFo and the application can use file read commands to get the
events (e.g. a 32 bit word for each event containing the scan code, the
up/down indicator and the duration or time-stamp).

Thus the Kernel mode driver only needs to implement standard blocking
file "read" and perhaps a "select"  events as a user mode interface.

The application now can detect the timing in user mode (without needing
more information than what it reads from the driver) and act accordingly
in an appropriately complex way. If you do a dedicated user thread for
this purpose you can just use the blocking read interface to the driver
and the driver does not need to support select().

-Michael

Re: Mobile phone keypad driver
Thanks for your quick response.
But there is a concern here in that we want to use GTK+. So
implementing a new protocol here might not be that easy. GTK+ expects
the keypad driver to behave the same way as the standard PC keyboard.
It directly calls the GTK driver interface functions [open, close,
ioctl etc]. Introducing a layer in between means all these will have to
be changed. Also if you introduce a library above GTK+ means all
applications will have to use this custom interface. The application
development doesnot come under our scope. We assume that there are are
already existing applications available above GTK. This will need all
of them to be modified.


Michael Schnell wrote:
Quoted text here. Click to load it
?
Quoted text here. Click to load it
"simple"
Quoted text here. Click to load it




the

needing
accordingly
for
driver


Site Timeline