diff options
author | Mauro Carvalho Chehab <mchehab@redhat.com> | 2009-08-29 13:15:55 -0400 |
---|---|---|
committer | Mauro Carvalho Chehab <mchehab@redhat.com> | 2009-09-12 11:19:47 -0400 |
commit | 715a223323c8c8bcbe7739e20f6c619f7343b595 (patch) | |
tree | 0c7eddcdd3c778428fc936009af085940c0394bb /drivers/xen | |
parent | 47f7f6fb7949b6546baf4b6f26bf0ca075d12759 (diff) |
V4L/DVB (12595): common/ir: use a struct for keycode tables
Currently, V4L uses a scancode table whose index is the scancode and
the value is the keycode. While this works, it has some drawbacks:
1) It requires that the scancode to be at the range 00-7f;
2) keycodes should be masked on 7 bits in order for it to work;
3) due to the 7 bits approach, sometimes it is not possible to replace
the default keyboard to another one with a different encoding rule;
4) it is different than what is done with dvb-usb approach;
5) it requires a typedef for it to work. This is not a recommended
Linux CodingStyle.
This patch is part of a larger series of IR changes. It basically
replaces the IR_KEYTAB_TYPE tables by a structured table:
struct ir_scancode {
u16 scancode;
u32 keycode;
};
This is very close to what dvb does. So, a further integration with DVB
code will be easy.
While we've changed the tables, for now, the IR keycode handling is still
based on the old approach.
The only notable effect is the redution of about 35% of the ir-common
module size:
text data bss dec hex filename
6721 29208 4 35933 8c5d old/ir-common.ko
5756 18040 4 23800 5cf8 new/ir-common.ko
In thesis, we could be using above u8 for scancode, reducing even more the size
of the module, but defining it as u16 is more convenient, since, on dvb, each
scancode has up to 16 bits, and we currently have a few troubles with rc5, as their
scancodes are defined with more than 8 bits.
This patch itself shouldn't be doing any functional changes.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Diffstat (limited to 'drivers/xen')
0 files changed, 0 insertions, 0 deletions