Mobile phone keypad driver - Embedded

This is a discussion on Mobile phone keypad driver - Embedded ; 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 -- ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Mobile phone keypad driver

  1. Mobile phone keypad driver

    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


  2. 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

  3. 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:
    > 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



+ Reply to Thread