Enable addition function keys

Enable addition function keys

[David Christen]

I have a custom made keyboard with 48 Function keys attached to an embedded
PC running on a RISC CPU. With hid module in the kernel the regular part of
the keyboard (i.e. all letters, num pad and Fxx keys up to F12) are working
perfectly fine. However with the additional keys I don't get any events in
/dev/input/event0. This is the same behavior as found on a regular Linux PC
and also under Windows. Although the manufacturer of the keyboard confirmed
that those keys do send proper HID codes (0x68 to 0x8b for F13 to F48).
I don't have any experience in programming on the Kernel level. Could you
maybe direct me in how to get the input events of those keys running?

Thank you in advance,
David

Re: Enable addition function keys

[Dmitry Torokhov]

Hi David,

On Mon, May 16, 2011 at 09:54:49PM +0200, David Christen wrote:
> I have a custom made keyboard with 48 Function keys attached to an embedded
> PC running on a RISC CPU. With hid module in the kernel the regular part of
> the keyboard (i.e. all letters, num pad and Fxx keys up to F12) are working
> perfectly fine. However with the additional keys I don't get any events in
> /dev/input/event0. This is the same behavior as found on a regular Linux PC
> and also under Windows. Although the manufacturer of the keyboard confirmed
> that those keys do send proper HID codes (0x68 to 0x8b for F13 to F48).
> I don't have any experience in programming on the Kernel level. Could you
> maybe direct me in how to get the input events of those keys running?
> 

Even though the usage codes are not mapped you should be able to map
them yourself using EVIOCSKEYCODE ioctl. See udev sources for how to
adjust keymaps on input devices.

We have F1 through F24 keycode defines, but no F25-F48 (nor do I want to
add these since userspace would not really know what to do with these,
they are device-specific); you'll have to pick some standard ones that
match the functions you want to assign to your extended keys.

Hope this helps.

-- 
Dmitry

Re: Enable addition function keys

[David Christen]

On Tue, May 24, 2011 at 8:22 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> Hi David,
>
> On Mon, May 16, 2011 at 09:54:49PM +0200, David Christen wrote:
>> I have a custom made keyboard with 48 Function keys attached to an embedded
>> PC running on a RISC CPU. With hid module in the kernel the regular part of
>> the keyboard (i.e. all letters, num pad and Fxx keys up to F12) are working
>> perfectly fine. However with the additional keys I don't get any events in
>> /dev/input/event0. This is the same behavior as found on a regular Linux PC
>> and also under Windows. Although the manufacturer of the keyboard confirmed
>> that those keys do send proper HID codes (0x68 to 0x8b for F13 to F48).
>> I don't have any experience in programming on the Kernel level. Could you
>> maybe direct me in how to get the input events of those keys running?
>>
>
> Even though the usage codes are not mapped you should be able to map
> them yourself using EVIOCSKEYCODE ioctl. See udev sources for how to
> adjust keymaps on input devices.
>
> We have F1 through F24 keycode defines, but no F25-F48 (nor do I want to
> add these since userspace would not really know what to do with these,
> they are device-specific); you'll have to pick some standard ones that
> match the functions you want to assign to your extended keys.
>

Dear Dmitry,

Thank you for looking into this.

I'm trying to figure out how to use udev for this. Just to make sure
that my problem was described correctly. My issue is not the mapping
from the scancode to the keycode, but that I don't get any scancode at
all. If I look at the output of usbmon, in particular the rdesc file,
I get

====
Keyboard.0063 ---> Key.KPDot
Keyboard.0064 ---> Key.102nd
Keyboard.0065 ---> Key.Compose
LED.NumLock ---> LED.NumLock
LED.CapsLock ---> LED.CapsLock
LED.ScrollLock ---> LED.ScrollLock
(eof)
====

Looking at the output of my standard Logitech keyboard, this would be
exactly what I would need:

====
Keyboard.0080 ---> Key.VolumeUp
Keyboard.0081 ---> Key.VolumeDown
Keyboard.0082 ---> Key.Unknown
Keyboard.0083 ---> Key.Unknown
Keyboard.0084 ---> Key.Unknown
Keyboard.0085 ---> Key.KPComma
Keyboard.0086 ---> Key.Unknown
Keyboard.0087 ---> Key.RO
Keyboard.0088 ---> Key.Katakana/Hiragana
Keyboard.0089 ---> Key.Yen
Keyboard.008a ---> Key.Henkan
Keyboard.008b ---> Key.Muhenkan
Keyboard.008c ---> Key.KPJpComma
Keyboard.008d ---> Key.Unknown
Keyboard.008e ---> Key.Unknown
Keyboard.008f ---> Key.Unknown
Keyboard.0090 ---> Key.Hangeul
Keyboard.0091 ---> Key.Hanja
(eof)
====

Even better would be to use a keymap without any Key.Unknown in the
range 0x6b - 0x8b. The exact keycode is not relevant to me as long as
they are unique. I translate them immediately to some other codes and
send them to the serial port.

So is there an easy way to select which keymap should be loaded? Below
is the output when the keyboard is being attached:

====
usb 2-1: new full speed USB device using uhci_hcd and address 9
usb 2-1: New USB device found, idVendor=03eb, idProduct=2003
usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 2-1: Product: USB Foil Keyboard Controller 32 12 885
usb 2-1: Manufacturer: GESYS
input: GESYS USB Foil Keyboard Controller 32 12 885 as /class/input/input11
generic-usb 0003:03EB:2003.000C: input,hidraw0: USB HID v1.11 Keyboard
[GESYS USB Foil Keyboard Controller 32 12 885] on
usb-0000:00:06.0-1/input0
====

as opposed to the logitech keyboard:

====
usb 2-1: new low speed USB device using uhci_hcd and address 10
usb 2-1: New USB device found, idVendor=046d, idProduct=c30e
usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 2-1: Product: HID compliant keyboard
usb 2-1: Manufacturer: Logitech
input: Logitech HID compliant keyboard as /class/input/input12
generic-usb 0003:046D:C30E.000D: input,hidraw0: USB HID v1.10 Keyboard
[Logitech HID compliant keyboard] on usb-0000:00:06.0-1/input0
input: Logitech HID compliant keyboard as /class/input/input13
generic-usb 0003:046D:C30E.000E: input,hidraw1: USB HID v1.10 Device
[Logitech HID compliant keyboard] on usb-0000:00:06.0-1/input1
====

Thank you,
David

Re: Enable addition function keys

[David Christen]

[-- Attachment #1: Type: text/plain, Size: 5175 bytes --]

On Tue, May 24, 2011 at 1:30 PM, David Christen <davidchristen@gmail.com> wrote:
> On Tue, May 24, 2011 at 8:22 AM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
>> Hi David,
>>
>> On Mon, May 16, 2011 at 09:54:49PM +0200, David Christen wrote:
>>> I have a custom made keyboard with 48 Function keys attached to an embedded
>>> PC running on a RISC CPU. With hid module in the kernel the regular part of
>>> the keyboard (i.e. all letters, num pad and Fxx keys up to F12) are working
>>> perfectly fine. However with the additional keys I don't get any events in
>>> /dev/input/event0. This is the same behavior as found on a regular Linux PC
>>> and also under Windows. Although the manufacturer of the keyboard confirmed
>>> that those keys do send proper HID codes (0x68 to 0x8b for F13 to F48).
>>> I don't have any experience in programming on the Kernel level. Could you
>>> maybe direct me in how to get the input events of those keys running?
>>>
>>
>> Even though the usage codes are not mapped you should be able to map
>> them yourself using EVIOCSKEYCODE ioctl. See udev sources for how to
>> adjust keymaps on input devices.
>>
>> We have F1 through F24 keycode defines, but no F25-F48 (nor do I want to
>> add these since userspace would not really know what to do with these,
>> they are device-specific); you'll have to pick some standard ones that
>> match the functions you want to assign to your extended keys.
>>
>
> Dear Dmitry,
>
> Thank you for looking into this.
>
> I'm trying to figure out how to use udev for this. Just to make sure
> that my problem was described correctly. My issue is not the mapping
> from the scancode to the keycode, but that I don't get any scancode at
> all. If I look at the output of usbmon, in particular the rdesc file,
> I get
>
> ====
> Keyboard.0063 ---> Key.KPDot
> Keyboard.0064 ---> Key.102nd
> Keyboard.0065 ---> Key.Compose
> LED.NumLock ---> LED.NumLock
> LED.CapsLock ---> LED.CapsLock
> LED.ScrollLock ---> LED.ScrollLock
> (eof)
> ====
>
> Looking at the output of my standard Logitech keyboard, this would be
> exactly what I would need:
>
> ====
> Keyboard.0080 ---> Key.VolumeUp
> Keyboard.0081 ---> Key.VolumeDown
> Keyboard.0082 ---> Key.Unknown
> Keyboard.0083 ---> Key.Unknown
> Keyboard.0084 ---> Key.Unknown
> Keyboard.0085 ---> Key.KPComma
> Keyboard.0086 ---> Key.Unknown
> Keyboard.0087 ---> Key.RO
> Keyboard.0088 ---> Key.Katakana/Hiragana
> Keyboard.0089 ---> Key.Yen
> Keyboard.008a ---> Key.Henkan
> Keyboard.008b ---> Key.Muhenkan
> Keyboard.008c ---> Key.KPJpComma
> Keyboard.008d ---> Key.Unknown
> Keyboard.008e ---> Key.Unknown
> Keyboard.008f ---> Key.Unknown
> Keyboard.0090 ---> Key.Hangeul
> Keyboard.0091 ---> Key.Hanja
> (eof)
> ====
>
> Even better would be to use a keymap without any Key.Unknown in the
> range 0x6b - 0x8b. The exact keycode is not relevant to me as long as
> they are unique. I translate them immediately to some other codes and
> send them to the serial port.
>
> So is there an easy way to select which keymap should be loaded? Below
> is the output when the keyboard is being attached:
>
> ====
> usb 2-1: new full speed USB device using uhci_hcd and address 9
> usb 2-1: New USB device found, idVendor=03eb, idProduct=2003
> usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> usb 2-1: Product: USB Foil Keyboard Controller 32 12 885
> usb 2-1: Manufacturer: GESYS
> input: GESYS USB Foil Keyboard Controller 32 12 885 as /class/input/input11
> generic-usb 0003:03EB:2003.000C: input,hidraw0: USB HID v1.11 Keyboard
> [GESYS USB Foil Keyboard Controller 32 12 885] on
> usb-0000:00:06.0-1/input0
> ====
>
> as opposed to the logitech keyboard:
>
> ====
> usb 2-1: new low speed USB device using uhci_hcd and address 10
> usb 2-1: New USB device found, idVendor=046d, idProduct=c30e
> usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> usb 2-1: Product: HID compliant keyboard
> usb 2-1: Manufacturer: Logitech
> input: Logitech HID compliant keyboard as /class/input/input12
> generic-usb 0003:046D:C30E.000D: input,hidraw0: USB HID v1.10 Keyboard
> [Logitech HID compliant keyboard] on usb-0000:00:06.0-1/input0
> input: Logitech HID compliant keyboard as /class/input/input13
> generic-usb 0003:046D:C30E.000E: input,hidraw1: USB HID v1.10 Device
> [Logitech HID compliant keyboard] on usb-0000:00:06.0-1/input1
> ====
>
> Thank you,
> David
>

Dear Dmitry,

I'm starting to feel stupid. I tried a simple code doing some ioctl
calls using EVIOCSKEYCODE  and EVIOCGKEYCODE. But it does not appear
to work. If I run it using ./ioctl-test /dev/input/event0 I get lots
of complains about wrong arguments:

====
evdev ioctl: Invalid argument
[0]= 125, [1] = 0
evdev ioctl: Invalid argument
[0]= 126, [1] = 0
evdev ioctl: Invalid argument
[0]= 127, [1] = 0
evdev ioctl: Invalid argument
[0]= 128, [1] = 0
evdev ioctl: Invalid argument
[0]= 129, [1] = 0
evdev ioctl: Invalid argument
Testing changes
evdev ioctl: Invalid argument
[0]= 49, [1] = 49
evdev ioctl: Invalid argument
[0]= 50, [1] = 49
====

Sorry for bothering you with this but I haven't found a lot of
information on this on the web.

Best regards,
David

[-- Attachment #2: ioctl-test.c --]
[-- Type: text/x-csrc, Size: 1428 bytes --]

#include <stdlib.h>
#include <stdio.h>
#include <ctype.h>
#include <fcntl.h>

#include <linux/input.h>
#include <linux/serial.h>
#include <errno.h>
#include <unistd.h>
#include <termios.h>

#include <string.h>
#include <linux/input.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <sys/time.h>
#include <sys/stat.h>

int main (int argc, char *argv[]) {
    int i, fd, ret;
    struct input_event ev[64];

    if ((fd = open(argv[1], O_RDWR)) < 0) {
        perror("Couldn't open input device");
        return 1;
    }

	int version;

	if (ioctl(fd, EVIOCGVERSION, &version)) {
		perror("evdev ioctl");
	}

	/* the EVIOCGVERSION ioctl() returns an int */
	/* so we unpack it and display it */
	printf("evdev driver version is %d.%d.%d\n",
		   version >> 16, (version >> 8) & 0xff,
		   version & 0xff);

	int codes[2];
	for (i=0; i<130; i++) {
		codes[0] = i;
		if(ioctl(fd, EVIOCSKEYCODE, codes)) {
			perror("evdev ioctl");
		}
		printf("[0]= %d, [1] = %d\n",
			   codes[0], codes[1]);
	}

	codes[0] = 58; /* M keycap */
	codes[1] = 49; /* assign to N */

	if(ioctl(fd, EVIOCSKEYCODE, codes)) {
		perror("evdev ioctl");
	}
	
	printf("Testing changes\n");
	
	for (i=49; i<60; i++) {
		codes[0] = i;
		if(ioctl(fd, EVIOCSKEYCODE, codes)) {
			perror("evdev ioctl");
		}
		printf("[0]= %d, [1] = %d\n",
			   codes[0], codes[1]);
	}

	return 0;
}

Re: Enable addition function keys

[Dmitry Torokhov]

On Tue, May 24, 2011 at 06:27:57PM +0200, David Christen wrote:
> On Tue, May 24, 2011 at 1:30 PM, David Christen <davidchristen@gmail.com> wrote:
> > On Tue, May 24, 2011 at 8:22 AM, Dmitry Torokhov
> > <dmitry.torokhov@gmail.com> wrote:
> >> Hi David,
> >>
> >> On Mon, May 16, 2011 at 09:54:49PM +0200, David Christen wrote:
> >>> I have a custom made keyboard with 48 Function keys attached to an embedded
> >>> PC running on a RISC CPU. With hid module in the kernel the regular part of
> >>> the keyboard (i.e. all letters, num pad and Fxx keys up to F12) are working
> >>> perfectly fine. However with the additional keys I don't get any events in
> >>> /dev/input/event0. This is the same behavior as found on a regular Linux PC
> >>> and also under Windows. Although the manufacturer of the keyboard confirmed
> >>> that those keys do send proper HID codes (0x68 to 0x8b for F13 to F48).
> >>> I don't have any experience in programming on the Kernel level. Could you
> >>> maybe direct me in how to get the input events of those keys running?
> >>>
> >>
> >> Even though the usage codes are not mapped you should be able to map
> >> them yourself using EVIOCSKEYCODE ioctl. See udev sources for how to
> >> adjust keymaps on input devices.
> >>
> >> We have F1 through F24 keycode defines, but no F25-F48 (nor do I want to
> >> add these since userspace would not really know what to do with these,
> >> they are device-specific); you'll have to pick some standard ones that
> >> match the functions you want to assign to your extended keys.
> >>
> >
> > Dear Dmitry,
> >
> > Thank you for looking into this.
> >
> > I'm trying to figure out how to use udev for this. Just to make sure
> > that my problem was described correctly. My issue is not the mapping
> > from the scancode to the keycode, but that I don't get any scancode at
> > all. If I look at the output of usbmon, in particular the rdesc file,
> > I get
> >
> > ====
> > Keyboard.0063 ---> Key.KPDot
> > Keyboard.0064 ---> Key.102nd
> > Keyboard.0065 ---> Key.Compose
> > LED.NumLock ---> LED.NumLock
> > LED.CapsLock ---> LED.CapsLock
> > LED.ScrollLock ---> LED.ScrollLock
> > (eof)
> > ====
> >
> > Looking at the output of my standard Logitech keyboard, this would be
> > exactly what I would need:
> >
> > ====
> > Keyboard.0080 ---> Key.VolumeUp
> > Keyboard.0081 ---> Key.VolumeDown
> > Keyboard.0082 ---> Key.Unknown
> > Keyboard.0083 ---> Key.Unknown
> > Keyboard.0084 ---> Key.Unknown
> > Keyboard.0085 ---> Key.KPComma
> > Keyboard.0086 ---> Key.Unknown
> > Keyboard.0087 ---> Key.RO
> > Keyboard.0088 ---> Key.Katakana/Hiragana
> > Keyboard.0089 ---> Key.Yen
> > Keyboard.008a ---> Key.Henkan
> > Keyboard.008b ---> Key.Muhenkan
> > Keyboard.008c ---> Key.KPJpComma
> > Keyboard.008d ---> Key.Unknown
> > Keyboard.008e ---> Key.Unknown
> > Keyboard.008f ---> Key.Unknown
> > Keyboard.0090 ---> Key.Hangeul
> > Keyboard.0091 ---> Key.Hanja
> > (eof)
> > ====
> >
> > Even better would be to use a keymap without any Key.Unknown in the
> > range 0x6b - 0x8b. The exact keycode is not relevant to me as long as
> > they are unique. I translate them immediately to some other codes and
> > send them to the serial port.
> >
> > So is there an easy way to select which keymap should be loaded? 

We try to follow HID Usage Table 1.12 or later as close as possible,
but we do not have keys defined for all possible usage codes and expect
userspace to adjust keymap as needed for specific devices.

> > Below
> > is the output when the keyboard is being attached:
> >
> > ====
> > usb 2-1: new full speed USB device using uhci_hcd and address 9
> > usb 2-1: New USB device found, idVendor=03eb, idProduct=2003
> > usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> > usb 2-1: Product: USB Foil Keyboard Controller 32 12 885
> > usb 2-1: Manufacturer: GESYS
> > input: GESYS USB Foil Keyboard Controller 32 12 885 as /class/input/input11
> > generic-usb 0003:03EB:2003.000C: input,hidraw0: USB HID v1.11 Keyboard
> > [GESYS USB Foil Keyboard Controller 32 12 885] on
> > usb-0000:00:06.0-1/input0
> > ====
> >
> > as opposed to the logitech keyboard:
> >
> > ====
> > usb 2-1: new low speed USB device using uhci_hcd and address 10
> > usb 2-1: New USB device found, idVendor=046d, idProduct=c30e
> > usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> > usb 2-1: Product: HID compliant keyboard
> > usb 2-1: Manufacturer: Logitech
> > input: Logitech HID compliant keyboard as /class/input/input12
> > generic-usb 0003:046D:C30E.000D: input,hidraw0: USB HID v1.10 Keyboard
> > [Logitech HID compliant keyboard] on usb-0000:00:06.0-1/input0
> > input: Logitech HID compliant keyboard as /class/input/input13
> > generic-usb 0003:046D:C30E.000E: input,hidraw1: USB HID v1.10 Device
> > [Logitech HID compliant keyboard] on usb-0000:00:06.0-1/input1
> > ====
> >
> > Thank you,
> > David
> >
> 
> Dear Dmitry,
> 
> I'm starting to feel stupid. I tried a simple code doing some ioctl
> calls using EVIOCSKEYCODE  and EVIOCGKEYCODE. But it does not appear
> to work. If I run it using ./ioctl-test /dev/input/event0 I get lots
> of complains about wrong arguments:
> 
> ====
> evdev ioctl: Invalid argument
> [0]= 125, [1] = 0
> evdev ioctl: Invalid argument
> [0]= 126, [1] = 0
> evdev ioctl: Invalid argument
> [0]= 127, [1] = 0
> evdev ioctl: Invalid argument
> [0]= 128, [1] = 0
> evdev ioctl: Invalid argument
> [0]= 129, [1] = 0
> evdev ioctl: Invalid argument
> Testing changes
> evdev ioctl: Invalid argument
> [0]= 49, [1] = 49
> evdev ioctl: Invalid argument
> [0]= 50, [1] = 49

The "scancode" for USB HID devices is full usage code (32 bit), so to
remap 'M' to 'N' I think you need to issue EVIOCSKEYCODE for
usage 0x00070010 (I think) and keycode 49 (KEY_N). 

BTW, this requires somewhat recent kernel. What kernel are you using?

Hope this helps.

-- 
Dmitry

P.S. In your program you call EVIOCSKEYCODE twice. I believe the 2nd
time, when you test, you want to call EVIOCGKEYCODE.

Re: Enable addition function keys

[David Christen]

[-- Attachment #1: Type: text/plain, Size: 1641 bytes --]

>>
>> Dear Dmitry,
>>
>> I'm starting to feel stupid. I tried a simple code doing some ioctl
>> calls using EVIOCSKEYCODE  and EVIOCGKEYCODE. But it does not appear
>> to work. If I run it using ./ioctl-test /dev/input/event0 I get lots
>> of complains about wrong arguments:
>>
>> ====
>> evdev ioctl: Invalid argument
>> [0]= 125, [1] = 0
>> evdev ioctl: Invalid argument
>> [0]= 126, [1] = 0
>> evdev ioctl: Invalid argument
>> [0]= 127, [1] = 0
>> evdev ioctl: Invalid argument
>> [0]= 128, [1] = 0
>> evdev ioctl: Invalid argument
>> [0]= 129, [1] = 0
>> evdev ioctl: Invalid argument
>> Testing changes
>> evdev ioctl: Invalid argument
>> [0]= 49, [1] = 49
>> evdev ioctl: Invalid argument
>> [0]= 50, [1] = 49
>
> The "scancode" for USB HID devices is full usage code (32 bit), so to
> remap 'M' to 'N' I think you need to issue EVIOCSKEYCODE for
> usage 0x00070010 (I think) and keycode 49 (KEY_N).
>
> BTW, this requires somewhat recent kernel. What kernel are you using?
>
Dear Dmitry,

So you mean it should say:

	codes[0] = 0x00070010 ; /* M keycap */
	codes[1] = 49; /* assign to N */

	if(ioctl(fd, EVIOCSKEYCODE, codes)) {
		perror("evdev ioctl");
	}


> P.S. In your program you call EVIOCSKEYCODE twice. I believe the 2nd
> time, when you test, you want to call EVIOCGKEYCODE.
>
>

Yes, you were right. Please find the corrected file attached.

But it seems that the behavior is exactly the same.

The kernel I use is 2.6.33 . It's a debian distro running on a risc processor.

Do you have any idea where that issue could come from?

Thank you for the help,
David

[-- Attachment #2: keytable.c --]
[-- Type: text/x-csrc, Size: 6424 bytes --]

/*
 * Based on keytable.c by Mauro Carvalho Chehab
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, version 2 of the License.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * Author: David Christen, Beat Christen AG, Zell LU, Switzerland
 * Date  :
 *
 */

#include <stdlib.h>
#include <stdio.h>
#include <ctype.h>
#include <fcntl.h>

#include <linux/input.h>
#include <linux/serial.h>
#include <errno.h>
#include <unistd.h>
#include <termios.h>

#include <string.h>
#include <linux/input.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <sys/time.h>
#include <sys/stat.h>

#include "parse.h"
#include "vsopenrisc.h"

#define KEY_RELEASE 0
#define KEY_PRESS 1
#define KEY_KEEPING_PRESSED 2

#define GOTO_ERROR(str)	\
	do { \
		printf("%s(%d) / %s: %s (%d)\n", __FILE__, __LINE__, str, strerror(errno), errno); \
		goto error; \
	} while(0)

static struct
{
	unsigned char value;
	char name[32];
} 

epld_str_tab[] =
{
	 { EPLD_RS232, "rs232" }
	,{ EPLD_RS422, "rs422" }
	,{ EPLD_RS485_ART_4W, "rs485byart-4-wire" }
	,{ EPLD_RS485_ART_2W, "rs485byart-2-wire-noecho" }
	,{ EPLD_RS485_ART_ECHO, "rs485byart-2-wire-echo" }
	,{ EPLD_RS485_RTS_4W, "rs485byrts-4-wire" }
	,{ EPLD_RS485_RTS_2W, "rs485byrts-2-wire-noecho" }
	,{ EPLD_RS485_RTS_ECHO, "rs485byrts-2-wire-echo" }
	,{ EPLD_PORTOFF, "inactive" }
};

static int epld_str_tab_size = sizeof(epld_str_tab) / sizeof(epld_str_tab[0]);

struct translateEntry {
	char KeyName[32];
	int CtrlOn;
	int TranslatedChar;
};	

char * prtcode(int codes) {
    struct parse_key *p;
    for (p = keynames; p->name != NULL; p++) {
        if (p->value == (unsigned) codes) {
            printf("scancode %s (0x%02x)\n", p->name, codes);
            return p->name;
        }
    }
	
    if (isprint(codes)) {
        printf("scancode '%c' (0x%02x)\n", codes, codes);
    } else {
        printf("scancode 0x%02x\n", codes);
    }

	return NULL;
}

int main (int argc, char *argv[]) {
    int i, fd, ret;
    struct input_event ev[64];

    if (argc != 4) {
        fprintf(stderr, "usage: %s event-device (/dev/input/eventX) \n           output-device(/dev/ttyS1)\n           config-file (tastatur.config)\n", argv[0]);
        return 1;
    }

    if ((fd = open(argv[1], O_RDONLY)) < 0) {
        perror("Couldn't open input device");
        return 1;
    }

	struct translateEntry translateTable[1024];
	int numTranslateEntries = 0;
	
 	FILE *file = fopen ( argv[3], "r" );
	
	char largeBuf[1024];
	if ( file != NULL ) {
		printf("Start reading config file\n");
		while (1) {
			ret = fscanf(file, "%s %d %d", largeBuf, 
					&(translateTable[numTranslateEntries].CtrlOn), 
					&(translateTable[numTranslateEntries].TranslatedChar));
			if ( ret == 3) {
				char * comment = strchr(largeBuf, '#');
				if ( comment == NULL ) {
					if (strlen(largeBuf) < 32) {
						strcpy(translateTable[numTranslateEntries].KeyName, largeBuf);
						printf("Found key definition: %s %d %d\n", translateTable[numTranslateEntries].KeyName, 
								translateTable[numTranslateEntries].CtrlOn, 
								translateTable[numTranslateEntries].TranslatedChar);
						numTranslateEntries++;
					} else {
						perror("KeyCode exceeds maximum length of 32 characters");
					}
				}
			} else if (ret == EOF) {
				break;
			} else {
				/*printf("ret = %d, largeBuf = %s\n", ret, largeBuf);*/
			}
		}

		fclose ( file );
	}
	else {
		perror ( argv[3] ); /* why didn't the file open? */
	}
	
	
    int s = -1;
	struct epld_struct epld;
	struct sockaddr_in *addrp;

	printf("reading the mode of port %s\n", argv[2]);

	/////////////////////////////////////////////
	// set the external serial port 2 to rs232 //
	/////////////////////////////////////////////
	printf("setting %s to rs232 mode\n", argv[2]);
	
	int fds;
	struct termios ser_termios;
	struct serial_struct ss_st;
	
	fds = open ( argv[2] , (O_RDWR | O_NOCTTY) ) ;
	if ( fds < 0)
	{
		perror("open");
		return -1;
	}

	//set baudrate to 38400 bit/s to activate custom divisor
	ret=tcgetattr(fds , &ser_termios);
	if(ret<0)
	{
		perror("getattr");
		return -1;
	}
	ret = cfsetispeed(&ser_termios, B1200);
	if (ret<0)
	{
		perror("ispeed");
		return -1;
	}
	ret=cfsetospeed(&ser_termios,B1200);
	if(ret<0)
	{
		perror("ospeed");
		return -1;
	}
	ret=tcsetattr(fds,TCSANOW,&ser_termios);
	if(ret<0)
	{
		perror("getattr");
		return -1;
	}

	if (ioctl(fds, TIOCGEPLD, &epld) < 0)
		perror("ioctl: TIOCGEPLD");

	for (i = 0; i < epld_str_tab_size; i++)
	{
		if (epld_str_tab[i].value == epld.value)
			printf("port %s is configured to %s\n", argv[2], epld_str_tab[i].name);
	}

	sleep(2);	
	
	epld.value = EPLD_RS232;
	
	printf("Start listening...\n");
		
	int CtrlPressed = 0;

    while (1) {
        size_t rb = read(fd, ev, sizeof(ev));

        if (rb < (int) sizeof(struct input_event)) {
            perror("short read");
            return 1;
        }

		int j;
        for (i = 0; i < (int) (rb / sizeof(struct input_event)); i++) {
            if (EV_KEY == ev[i].type) {
                char * keycode = prtcode(ev[i].code);
                printf("type %d code %d value %d\n", ev[i].type, ev[i].code, ev[i].value);
					
				if ((!strcmp("KEY_LEFTCTRL", keycode)) || (!strcmp("KEY_LEFTCTRL", keycode))) {
					if (ev[i].value > 0) {
						CtrlPressed = 1;
					} else {
						CtrlPressed = 0;
					}
				}
	
				if (ev[i].value > 0) {
					for(j=0; j<numTranslateEntries; j++){
						if ((!strcmp(translateTable[j].KeyName, keycode)) && (CtrlPressed == translateTable[j].CtrlOn)) {
							//Found a match
							printf("Will be translated to %d\n", translateTable[j].TranslatedChar);
							fprintf(fds, "%c", char(translateTable[j].TranslatedChar));
						}
					}
				}
				
				printf("\n");					
            } else {
				printf("type %d code %d value %d\n", ev[i].type, ev[i].code, ev[i].value);
			}
        }
    }

    return 0;
}

Re: Enable addition function keys

[Dmitry Torokhov]

On Tue, May 24, 2011 at 07:39:22PM +0200, David Christen wrote:
> >>
> >> Dear Dmitry,
> >>
> >> I'm starting to feel stupid. I tried a simple code doing some ioctl
> >> calls using EVIOCSKEYCODE  and EVIOCGKEYCODE. But it does not appear
> >> to work. If I run it using ./ioctl-test /dev/input/event0 I get lots
> >> of complains about wrong arguments:
> >>
> >> ====
> >> evdev ioctl: Invalid argument
> >> [0]= 125, [1] = 0
> >> evdev ioctl: Invalid argument
> >> [0]= 126, [1] = 0
> >> evdev ioctl: Invalid argument
> >> [0]= 127, [1] = 0
> >> evdev ioctl: Invalid argument
> >> [0]= 128, [1] = 0
> >> evdev ioctl: Invalid argument
> >> [0]= 129, [1] = 0
> >> evdev ioctl: Invalid argument
> >> Testing changes
> >> evdev ioctl: Invalid argument
> >> [0]= 49, [1] = 49
> >> evdev ioctl: Invalid argument
> >> [0]= 50, [1] = 49
> >
> > The "scancode" for USB HID devices is full usage code (32 bit), so to
> > remap 'M' to 'N' I think you need to issue EVIOCSKEYCODE for
> > usage 0x00070010 (I think) and keycode 49 (KEY_N).
> >
> > BTW, this requires somewhat recent kernel. What kernel are you using?
> >
> Dear Dmitry,
> 
> So you mean it should say:
> 
> 	codes[0] = 0x00070010 ; /* M keycap */
> 	codes[1] = 49; /* assign to N */

Yes.

> 
> 	if(ioctl(fd, EVIOCSKEYCODE, codes)) {
> 		perror("evdev ioctl");
> 	}
> 
> 
> > P.S. In your program you call EVIOCSKEYCODE twice. I believe the 2nd
> > time, when you test, you want to call EVIOCGKEYCODE.
> >
> >
> 
> Yes, you were right. Please find the corrected file attached.
> 
> But it seems that the behavior is exactly the same.
> 
> The kernel I use is 2.6.33 . It's a debian distro running on a risc processor.

I am afraid you need 2.6.38. Or you'll have to backport the following
commits:

8613e4c Input: add support for large scancodes
ab4e019 Input: define separate EVIOCGKEYCODE_V2/EVIOCSKEYCODE_V2
de391d1 Input: fix typo in keycode validation supporting large scancodes
a0bf0ea Input: hid-input - switch to using new keycode interface
f5854fa Input: hid-input - allow mapping unknown usages

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Enable addition function keys

[Thadeu Lima de Souza Cascardo]

[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]

On Tue, May 24, 2011 at 10:52:38AM -0700, Dmitry Torokhov wrote:
> On Tue, May 24, 2011 at 07:39:22PM +0200, David Christen wrote:
> > 
> > Yes, you were right. Please find the corrected file attached.
> > 
> > But it seems that the behavior is exactly the same.
> > 
> > The kernel I use is 2.6.33 . It's a debian distro running on a risc processor.
> 
> I am afraid you need 2.6.38. Or you'll have to backport the following
> commits:
> 
> 8613e4c Input: add support for large scancodes
> ab4e019 Input: define separate EVIOCGKEYCODE_V2/EVIOCSKEYCODE_V2
> de391d1 Input: fix typo in keycode validation supporting large scancodes
> a0bf0ea Input: hid-input - switch to using new keycode interface
> f5854fa Input: hid-input - allow mapping unknown usages
> 
> -- 
> Dmitry

Perhaps, he could try using hidraw interface. Would it be OK for you,
David? Since you said you are only getting these key events and sending
them through a serial interface, and I'd say your device portability
does not include non-HID devices right now, this should solve the
problem without the need for a kernel upgrade.

Regards,
Cascardo.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Enable addition function keys

[David Christen]

On Tue, May 24, 2011 at 8:03 PM, Thadeu Lima de Souza Cascardo
<cascardo@holoscopio.com> wrote:
> On Tue, May 24, 2011 at 10:52:38AM -0700, Dmitry Torokhov wrote:
>> On Tue, May 24, 2011 at 07:39:22PM +0200, David Christen wrote:
>> >
>> > Yes, you were right. Please find the corrected file attached.
>> >
>> > But it seems that the behavior is exactly the same.
>> >
>> > The kernel I use is 2.6.33 . It's a debian distro running on a risc processor.
>>
>> I am afraid you need 2.6.38. Or you'll have to backport the following
>> commits:
>>
>> 8613e4c Input: add support for large scancodes
>> ab4e019 Input: define separate EVIOCGKEYCODE_V2/EVIOCSKEYCODE_V2
>> de391d1 Input: fix typo in keycode validation supporting large scancodes
>> a0bf0ea Input: hid-input - switch to using new keycode interface
>> f5854fa Input: hid-input - allow mapping unknown usages
>>
>> --
>> Dmitry
>
> Perhaps, he could try using hidraw interface. Would it be OK for you,
> David? Since you said you are only getting these key events and sending
> them through a serial interface, and I'd say your device portability
> does not include non-HID devices right now, this should solve the
> problem without the need for a kernel upgrade.
>
> Regards,
> Cascardo.
>

Dear Cascardo and Dmitry,

Thank you for the hint with the hidraw. I was briefly looking at this
in the beginning of the project, but I found it was a bit too raw for
my purpose. Well, I was wrong...

Based on the example in the Documentation
(http://ns3.spinics.net/lists/linux-input/msg14216.html), together
with the patch for HIDIOCSFEATURE
(http://choon.net/forum/read.php?21,19545) and the same for
HIDIOCGRAWNAME I was able to first write a small test program and
later last night to actually build it into my software project.

Thank you very much the effort in helping me with this.

Take care,
David