Skip to contentSkip to conversation

Usage of new KEY_NUMERIC_* codes in an existing driver (yealink)

DISCUSSION Thomas Reitmayr 2 participants 3 messages Aug 22, 2008 – Aug 23, 2008 HID

lore
Share & tools
lore
#0 lore raw

Hi,
I am in the process of extending the existing yealink driver, partly to support various other models. The existing driver as included in the current kernel uses the shift key to report the keys "*" and "#", but I am hesitating to do the same bad "trick" for the other models.

As I would like to eventually submit the extended driver upstream, what is the recommended strategy in my situation regarding usage of the new KEY_NUMERIC_* codes? Use them only for the new models (which would result in an ugly mix), or also update the codes for the existing USB-P1K model (which would break userspace programs but finally fix things for some foreign keyboard layouts), or for the existing USB-P1K model report the old and the new codes (which might look like two key presses)?

Thanks for your advice,
-Thomas

PS: The updated driver is available at
http://www.devbase.at/svn/view.cgi/yealink-module/trunk/?root=voip
(still including #if's reg. kernel versions, some comments to be corrected, etc.)

#1 lore raw

Hi Thomas,

Quoted 6 lines · Thomas Reitmayr

Hi,
I am in the process of extending the existing yealink driver, partly to support various other models. The existing driver as included in the current kernel uses the shift key to report the keys "*" and "#", but I am hesitating to do the same bad "trick" for the other models.

Quoted 6 lines

As I would like to eventually submit the extended driver upstream, what is the recommended strategy in my situation regarding usage of the new KEY_NUMERIC_* codes? Use them only for the new models (which would result in an ugly mix), or also update the codes for the existing USB-P1K model (which would break userspace programs but finally fix things for some foreign keyboard layouts),

Do you think that we need to add more keymaps to the kernel? What I woudl like to see is adding setkeycode/getkeycode support to yealink so proper keymap can be loaded from userspace (udev, hal, whatever) when a device is plugged into a box. USB-P1K coudl also get the new keymap loaded from userspace while keeping the current legacy keymap for existing users.

Quoted 3 lines

or for the existing USB-P1K
model report the old and the new codes (which might look like two key presses)?

No, that is not a good idea.

Quoted 8 lines

Thanks for your advice,
-Thomas

PS: The updated driver is available at
http://www.devbase.at/svn/view.cgi/yealink-module/trunk/?root=voip
(still including #if's reg. kernel versions, some comments to be corrected, etc.)

Would you mind posting it as a patch - it is much easier to comment on it in e-mail... Thanks!

Signature · 1 line
Dmitry
#2 lore raw

Thanks Dmitry,
I will take a look at the cm109 driver to see how setkeycode/getkeycode support is implemented and how this fits into the yealink code. As soon as I have done that (and cleaned up a few things) I will post the code as a patch.
Best regards,
-Thomas

Am Freitag, den 22.08.2008, 16:02 -0400 schrieb Dmitry Torokhov:

Quoted 32 lines

Hi Thomas,

Quoted 6 lines · Thomas Reitmayr

Hi,
I am in the process of extending the existing yealink driver, partly to support various other models. The existing driver as included in the current kernel uses the shift key to report the keys "*" and "#", but I am hesitating to do the same bad "trick" for the other models.

Quoted 6 lines

As I would like to eventually submit the extended driver upstream, what is the recommended strategy in my situation regarding usage of the new KEY_NUMERIC_* codes? Use them only for the new models (which would result in an ugly mix), or also update the codes for the existing USB-P1K model (which would break userspace programs but finally fix things for some foreign keyboard layouts),

Do you think that we need to add more keymaps to the kernel? What I woudl like to see is adding setkeycode/getkeycode support to yealink so proper keymap can be loaded from userspace (udev, hal, whatever) when a device is plugged into a box. USB-P1K coudl also get the new keymap loaded from userspace while keeping the current legacy keymap for existing users.

Quoted 3 lines

or for the existing USB-P1K
model report the old and the new codes (which might look like two key presses)?

No, that is not a good idea.

Quoted 3 lines

Thanks for your advice,
-Thomas

Quoted 9 lines
Quoted 5 lines

PS: The updated driver is available at
http://www.devbase.at/svn/view.cgi/yealink-module/trunk/?root=voip
(still including #if's reg. kernel versions, some comments to be corrected, etc.)

Would you mind posting it as a patch - it is much easier to comment on it in e-mail... Thanks!

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