CC'ing Zephaniah E. Hull, who seems to be the person who contributed the patch in question.
Hello X guys, I hope I'm asking this question in the right place, since the evdev support patch seems to be Debian specific. I was trying to get my keyboard (Sun Type 6 USB) to work with the evdev driver, and I found a whole lot of keys reporting scancode 7, even more than in "regular" operation, without the evdev stuff. Then I read these lines in the patch: + case EV_KEY_103RD: + case EV_KEY_102ND: + case EV_KEY_LINEFEED: + case EV_KEY_MACRO: + case EV_KEY_MUTE: + case EV_KEY_VOLUMEDOWN: + case EV_KEY_VOLUMEUP: + case EV_KEY_POWER: + case EV_KEY_KPPLUSMINUS: + case EV_KEY_F18: + case EV_KEY_F19: + case EV_KEY_F20: + case EV_KEY_F21: + case EV_KEY_F22: + case EV_KEY_F23: + case EV_KEY_F24: + case EV_KEY_KPCOMMA: + case EV_KEY_COMPOSE: + code = KEY_UNKNOWN; + break; ... which could explain that. Is there a specific reason why these codes are mapped to KEY_UNKNOWN? I mean, if Linux recognizes them (which I'm not sure about -- is there a way to verify that besides hexdumping /dev/input/event*?), it would be cool to pass them on to the user. -- Best Regards, | This signature is currently under construction. Sebastian | Please check back later!
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
