Mobile phone keypad driver


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

Reply to
Loading thread data ...

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().


Reply to
Michael Schnell

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:








Reply to

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.