Re: Missing Key-codes from input.h file.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jun 26, 2012 at 1:30 PM, anish kumar
<anish198519851985@xxxxxxxxx> wrote:
> On Tue, 2012-06-26 at 09:43 +0200, Matthias Brugger wrote:
>> On 06/26/2012 08:47 AM, Dharam Kumar wrote:
>> > On Tue, Jun 26, 2012 at 12:02 PM, anish kumar
>> > <anish198519851985@xxxxxxxxx> wrote:
>> >> On Mon, 2012-06-25 at 23:24 +0530, Dharam Kumar wrote:
>> >>> On Mon, Jun 25, 2012 at 10:47 PM, anish kumar
>> >>> <anish198519851985@xxxxxxxxx> wrote:
>> >>>> On Mon, 2012-06-25 at 18:52 +0530, Dharam Kumar wrote:
>> >>>>> Hi,
>> >>>>> I'm working on a module which is an input device and hence it needs to
>> >>>>> report certain key events.
>> >>>>>
>> >>>>> While browsing through the <linux/input.h>, I did find most of the
>> >>>>> key-codes(which I need to use)already defined but not all.
>> >>>>>
>> >>>>>
>> >>>>> Few of the KEY_xxx which i could not find are:
>> >>>>>
>> >>>>>
>> >>>>> a.) A Key for going to the previous channel.
>> >>>>> b.) Keys for Moving upper-right, lower-right, upper-left and
>> >>>>> lower-left direction(probably a GUI(grid of icons),where you move
>> >>>>> diagonally)
>> >>>>> d.) A key for Subpicture (this 'subpicture' key is deeined in
>> >>>>> CEA-931C).
>> >>>> I think you are interested in the user space implementation of
>> >>>> the keys reported by the input subsystem of kernel.
>> >>>> Keys reported by the driver->input subsystem->reported to user space.
>> >>>>
>> >>>> I am not sure about linux way of reporting keys but in android the key
>> >>>> is reported at a particular sysfs file and this sysfs file is read by
>> >>>> eventhub.cpp.This file in turn is responsible for sending the events
>> >>>> to particular application and it is the responsibility of the
>> >>>> application how they interpret this keys.It can interpret events by
>> >>>> moving diagonally a pointer/touch or going left/right.
>> >>>>
>> >>> Thanks Anish ! To be clear, i just want to know the key-code
>> >>> which will be used by the Input Subsytem of the Kernel.
>> >>>
>> >>> For example, in <linux/input.h> file you will find a lot of #defines
>> >>> like the below,mapping different kind of key events to some key-code
>> >>> or value :
>> >>> #define KEY_UP                 0xXYZ
>> >>> #define KEY_DOWN         0xABC and so on...
>> >>>
>> >>> Now, I'm looking for key events like:
>> >>> #define KEY_PREVIOUSCHANNEL   <???>
>> >>> #define KEY_RIGHTUP                         <???>
>> >>> #define kEY_RIGHTLEFT                     <???>
>> >>> #define kEY_SUBPICTURE                 <???> and so on...
>> >>>
>> >>> You are probably right , that Userspace reads the key-events/key-codes
>> >>> from certain sysfs entries exported by Android Linux Kernel and these
>> >>> key-codes/events will be handled accordingly by the respective
>> >>> Framework/Application. But  I'm really not interested in how and what
>> >>> Userspace gets from Kernel.
>> >>> I'm interested in what values the Kernel or input subsystem will
>> >>> provide to such keys..
>> >> Do you have such keys in your device KEY_RIGHTUP?
>> >>
>> > Yes, my device is supposed to support such keys:
>> > RIGHTUP --> moves cursor upper-right direction.
>> > RIGHTDOWN ---> moves cursor lower-right direction.
>> > and similar keys for upper-left and lower-left cursor direction.
>> > Sadly, I could not find any #define in input.h file for such key events.
>>
>>  From your response I interpret that you have some kind of custom
>> key-pad, or anything similar which is not a standard keyboard.
>>
>> If there are no such defines in the Kernel, it's probably because no one
>> has had the need for them up to now.
>>
>> I think the implementation should be done as Anish described beforehand.
>> Anyway you can add some defines to your Kernel if this is a requirement
> and probably submit your first patch to the kernel but I am not clear
> about the policy regarding adding new keys in the kernel.However sending
Hmm..If I do add some defines to my Kernel and submit the patch to the
Open source kernel, I need to be very clear
about how these keys will be used(which driver, use-case ,source of
these keys etc..).
I think I'm not at that stage right now..hopefully I can complete the
driver and kernel patches in some time and submit it :)

Thanks for your time and patience !!
>> for you.
>>
>> Regards,
>> Matthias
>>
>> >>>> Not sure if this is what you are interested in but would have been
>> >>>> better if you had described the problem in more detail.
>> >>>>>
>> >>>>>
>> >>>>> Does anybody have any idea about this?
>> >>>>>
>> >>>>>
>> >>>>> -
>> >>>>> Dharam
>> >>>>> _______________________________________________
>> >>>>> Kernelnewbies mailing list
>> >>>>> Kernelnewbies@xxxxxxxxxxxxxxxxx
>> >>>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>> >>>>
>> >>>>
>> >>
>> >>
>> >
>> > _______________________________________________
>> > Kernelnewbies mailing list
>> > Kernelnewbies@xxxxxxxxxxxxxxxxx
>> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>> >
>>
>>
>
>

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies



[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux