All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dtor_core@ameritech.net>
To: Michael Hanselmann <linux-kernel@hansmi.ch>
Cc: linux-kernel@killerfox.forkbomb.ch, linux-kernel@vger.kernel.org,
	linuxppc-dev@ozlabs.org, Vojtech Pavlik <vojtech@suse.cz>,
	linux-input@atrey.karlin.mff.cuni.cz
Subject: Re: [PATCH/RFC?] usb/input: Add support for fn key on Apple PowerBooks
Date: Thu, 12 Jan 2006 23:12:04 -0500	[thread overview]
Message-ID: <200601122312.05210.dtor_core@ameritech.net> (raw)
In-Reply-To: <20060112000830.GB10142@hansmi.ch>

On Wednesday 11 January 2006 19:08, Michael Hanselmann wrote:
> On Thu, Jan 12, 2006 at 10:41:40AM +1100, Benjamin Herrenschmidt wrote:
> > I don't understand the comment above ? You are adding this to all struct
> > hid_device ? There can be only one of those keyboards plugged at one
> > point in time, I don't think there is any problem having the above
> > static in the driver rather than in the hid_device structure.
> 
> While I don't agree on that, I still modified the patch.
>

I disagree as well, but if we get semantics right we can merge it in
this form and adjust later. 
 
> +static int usbhid_pb_fnmode = 1;
> +module_param_named(pb_fnmode, usbhid_pb_fnmode, int, 0644);
> +MODULE_PARM_DESC(usbhid_pb_fnmode,
> +	"Mode of fn key on PowerBooks (0 = disabled, "
> +	"1 = fkeyslast, 2 = fkeysfirst)");
> +#endif
> +

That should be "MODULE_PARM_DESC(pb_fn_mode, ...)". Also, since this is
for compatibility with ADB, why do we have 3 options? Doesn't ADB have
only 2?

>  #define map_abs(c)	do { usage->code = c; usage->type = EV_ABS; bit = input->absbit; max = ABS_MAX; } while (0)
>  #define map_rel(c)	do { usage->code = c; usage->type = EV_REL; bit = input->relbit; max = REL_MAX; } while (0)
>  #define map_key(c)	do { usage->code = c; usage->type = EV_KEY; bit = input->keybit; max = KEY_MAX; } while (0)
> @@ -73,6 +135,80 @@ static struct {
>  #define map_key_clear(c)	do { map_key(c); clear_bit(c, bit); } while (0)
>  #define map_ff_effect(c)	do { set_bit(c, input->ffbit); } while (0)
>  
> +static inline struct hidinput_key_translation *find_translation(

I thought is was agreed that we'd avoid "inlines" in .c files?

> +	struct hidinput_key_translation *table, u16 from)
> +{
> +	struct hidinput_key_translation *trans;
> +
> +	/* Look for the translation */
> +	for(trans = table; trans->from && (trans->from != from); trans++);
> +
> +	return (trans->from?trans:NULL);
> +}

I'd prefer liberal amount of spaces applied here </extreme nitpick mode>

> +
> +static int hidinput_pb_event(struct hid_device *hid, struct input_dev *input,
> +	struct hid_usage *usage, __s32 value)
> +{
> +#ifdef CONFIG_USB_HIDINPUT_POWERBOOK
> +	struct hidinput_key_translation *trans;
> +
> +	if (usage->code == KEY_FN) {
> +		if (value) hid->quirks |=  HID_QUIRK_POWERBOOK_FN_ON;
> +		else       hid->quirks &= ~HID_QUIRK_POWERBOOK_FN_ON;
> +
> +		input_event(input, usage->type, usage->code, value);
> +
> +		return 1;
> +	}
> +
> +	if (usbhid_pb_fnmode) {
> +		int try_translate, do_translate;
> +
> +		trans = find_translation(powerbook_fn_keys, usage->code);
> +		if (trans) {
> +			if (test_bit(usage->code, usbhid_pb_fn))
> +				do_translate = 1;
> +			else if (trans->flags & POWERBOOK_FLAG_FKEY)
> +				do_translate =
> +					(usbhid_pb_fnmode == 2 &&  (hid->quirks & HID_QUIRK_POWERBOOK_FN_ON)) ||
> +					(usbhid_pb_fnmode == 1 && !(hid->quirks & HID_QUIRK_POWERBOOK_FN_ON));
> +			else
> +				do_translate = (hid->quirks & HID_QUIRK_POWERBOOK_FN_ON);
> +
> +			if (do_translate) {
> +				if (value)
> +					set_bit(usage->code, usbhid_pb_fn);
> +				else
> +					clear_bit(usage->code, usbhid_pb_fn);
> +
> +				input_event(input, usage->type, trans->to, value);
> +
> +				return 1;
> +			}
> +		}
> +
> +		try_translate = test_bit(usage->code, usbhid_pb_numlock)?1:
> +				test_bit(LED_NUML, input->led);
> +		if (try_translate) {

Isn't this the same as 

		if (test_bit(usage->code, usbhid_pb_numlock) || test_bit(LED_NUML, input->led))

but harder to read?

-- 
Dmitry

WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Torokhov <dtor_core@ameritech.net>
To: Michael Hanselmann <linux-kernel@hansmi.ch>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	linux-kernel@vger.kernel.org,
	linux-input@atrey.karlin.mff.cuni.cz, linuxppc-dev@ozlabs.org,
	linux-kernel@killerfox.forkbomb.ch,
	Vojtech Pavlik <vojtech@suse.cz>
Subject: Re: [PATCH/RFC?] usb/input: Add support for fn key on Apple PowerBooks
Date: Thu, 12 Jan 2006 23:12:04 -0500	[thread overview]
Message-ID: <200601122312.05210.dtor_core@ameritech.net> (raw)
In-Reply-To: <20060112000830.GB10142@hansmi.ch>

On Wednesday 11 January 2006 19:08, Michael Hanselmann wrote:
> On Thu, Jan 12, 2006 at 10:41:40AM +1100, Benjamin Herrenschmidt wrote:
> > I don't understand the comment above ? You are adding this to all struct
> > hid_device ? There can be only one of those keyboards plugged at one
> > point in time, I don't think there is any problem having the above
> > static in the driver rather than in the hid_device structure.
> 
> While I don't agree on that, I still modified the patch.
>

I disagree as well, but if we get semantics right we can merge it in
this form and adjust later. 
 
> +static int usbhid_pb_fnmode = 1;
> +module_param_named(pb_fnmode, usbhid_pb_fnmode, int, 0644);
> +MODULE_PARM_DESC(usbhid_pb_fnmode,
> +	"Mode of fn key on PowerBooks (0 = disabled, "
> +	"1 = fkeyslast, 2 = fkeysfirst)");
> +#endif
> +

That should be "MODULE_PARM_DESC(pb_fn_mode, ...)". Also, since this is
for compatibility with ADB, why do we have 3 options? Doesn't ADB have
only 2?

>  #define map_abs(c)	do { usage->code = c; usage->type = EV_ABS; bit = input->absbit; max = ABS_MAX; } while (0)
>  #define map_rel(c)	do { usage->code = c; usage->type = EV_REL; bit = input->relbit; max = REL_MAX; } while (0)
>  #define map_key(c)	do { usage->code = c; usage->type = EV_KEY; bit = input->keybit; max = KEY_MAX; } while (0)
> @@ -73,6 +135,80 @@ static struct {
>  #define map_key_clear(c)	do { map_key(c); clear_bit(c, bit); } while (0)
>  #define map_ff_effect(c)	do { set_bit(c, input->ffbit); } while (0)
>  
> +static inline struct hidinput_key_translation *find_translation(

I thought is was agreed that we'd avoid "inlines" in .c files?

> +	struct hidinput_key_translation *table, u16 from)
> +{
> +	struct hidinput_key_translation *trans;
> +
> +	/* Look for the translation */
> +	for(trans = table; trans->from && (trans->from != from); trans++);
> +
> +	return (trans->from?trans:NULL);
> +}

I'd prefer liberal amount of spaces applied here </extreme nitpick mode>

> +
> +static int hidinput_pb_event(struct hid_device *hid, struct input_dev *input,
> +	struct hid_usage *usage, __s32 value)
> +{
> +#ifdef CONFIG_USB_HIDINPUT_POWERBOOK
> +	struct hidinput_key_translation *trans;
> +
> +	if (usage->code == KEY_FN) {
> +		if (value) hid->quirks |=  HID_QUIRK_POWERBOOK_FN_ON;
> +		else       hid->quirks &= ~HID_QUIRK_POWERBOOK_FN_ON;
> +
> +		input_event(input, usage->type, usage->code, value);
> +
> +		return 1;
> +	}
> +
> +	if (usbhid_pb_fnmode) {
> +		int try_translate, do_translate;
> +
> +		trans = find_translation(powerbook_fn_keys, usage->code);
> +		if (trans) {
> +			if (test_bit(usage->code, usbhid_pb_fn))
> +				do_translate = 1;
> +			else if (trans->flags & POWERBOOK_FLAG_FKEY)
> +				do_translate =
> +					(usbhid_pb_fnmode == 2 &&  (hid->quirks & HID_QUIRK_POWERBOOK_FN_ON)) ||
> +					(usbhid_pb_fnmode == 1 && !(hid->quirks & HID_QUIRK_POWERBOOK_FN_ON));
> +			else
> +				do_translate = (hid->quirks & HID_QUIRK_POWERBOOK_FN_ON);
> +
> +			if (do_translate) {
> +				if (value)
> +					set_bit(usage->code, usbhid_pb_fn);
> +				else
> +					clear_bit(usage->code, usbhid_pb_fn);
> +
> +				input_event(input, usage->type, trans->to, value);
> +
> +				return 1;
> +			}
> +		}
> +
> +		try_translate = test_bit(usage->code, usbhid_pb_numlock)?1:
> +				test_bit(LED_NUML, input->led);
> +		if (try_translate) {

Isn't this the same as 

		if (test_bit(usage->code, usbhid_pb_numlock) || test_bit(LED_NUML, input->led))

but harder to read?

-- 
Dmitry

  reply	other threads:[~2006-01-13  4:12 UTC|newest]

Thread overview: 92+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-25 21:20 [PATCH/RFC?] usb/input: Add support for fn key on Apple PowerBooks Michael Hanselmann
2005-12-25 21:20 ` Michael Hanselmann
2005-12-25 21:57 ` Benjamin Herrenschmidt
2005-12-25 21:57   ` Benjamin Herrenschmidt
2005-12-26  4:04 ` Dmitry Torokhov
2005-12-26  4:04   ` Dmitry Torokhov
2005-12-26  5:46   ` Benjamin Herrenschmidt
2005-12-26  5:46     ` Benjamin Herrenschmidt
2006-01-11 21:07     ` Dmitry Torokhov
2006-01-11 21:07       ` Dmitry Torokhov
2006-01-11 21:20       ` Michael Hanselmann
2006-01-11 21:20         ` Michael Hanselmann
2006-01-11 21:34         ` Benjamin Herrenschmidt
2006-01-11 21:34           ` Benjamin Herrenschmidt
2006-01-11 21:38           ` Michael Hanselmann
2006-01-11 21:38             ` Michael Hanselmann
2006-01-11 21:41             ` Benjamin Herrenschmidt
2006-01-11 21:41               ` Benjamin Herrenschmidt
2006-01-11 21:43               ` Michael Hanselmann
2006-01-11 21:43                 ` Michael Hanselmann
2006-01-11 21:47                 ` Vojtech Pavlik
2006-01-11 21:47                   ` Vojtech Pavlik
2006-01-11 21:50                   ` Michael Hanselmann
2006-01-11 21:50                     ` Michael Hanselmann
2006-01-11 21:54                 ` Benjamin Herrenschmidt
2006-01-11 21:54                   ` Benjamin Herrenschmidt
2006-01-11 21:30       ` Benjamin Herrenschmidt
2006-01-11 21:30         ` Benjamin Herrenschmidt
2006-01-11 21:45         ` Vojtech Pavlik
2006-01-11 21:45           ` Vojtech Pavlik
2006-01-11 21:46         ` Michael Hanselmann
2006-01-11 21:46           ` Michael Hanselmann
2006-01-11 23:26       ` Michael Hanselmann
2006-01-11 23:26         ` Michael Hanselmann
2006-01-11 23:41         ` Benjamin Herrenschmidt
2006-01-11 23:41           ` Benjamin Herrenschmidt
2006-01-12  0:08           ` Michael Hanselmann
2006-01-12  0:08             ` Michael Hanselmann
2006-01-13  4:12             ` Dmitry Torokhov [this message]
2006-01-13  4:12               ` Dmitry Torokhov
2006-01-13  6:53               ` Michael Hanselmann
2006-01-13  6:53                 ` Michael Hanselmann
2006-01-13  7:47                 ` Vojtech Pavlik
2006-01-13  7:47                   ` Vojtech Pavlik
2006-01-13 22:02                   ` Michael Hanselmann
2006-01-13 22:02                     ` Michael Hanselmann
2006-01-14  4:58                     ` Dmitry Torokhov
2006-01-14  4:58                       ` Dmitry Torokhov
2006-01-14 10:41                       ` Vojtech Pavlik
2006-01-14 10:41                         ` Vojtech Pavlik
2006-01-14 10:57                       ` Michael Hanselmann
2006-01-14 10:57                         ` Michael Hanselmann
2006-01-13 21:55               ` Benjamin Herrenschmidt
2006-01-13 21:55                 ` Benjamin Herrenschmidt
2006-01-13 21:57                 ` Benjamin Herrenschmidt
2006-01-13 21:57                   ` Benjamin Herrenschmidt
2006-01-13 22:05                 ` Dmitry Torokhov
2006-01-13 22:05                   ` Dmitry Torokhov
2006-01-13 22:08                   ` Dmitry Torokhov
2006-01-13 22:08                     ` Dmitry Torokhov
2006-01-13 22:14                   ` Benjamin Herrenschmidt
2006-01-13 22:14                     ` Benjamin Herrenschmidt
2006-01-13 22:25                     ` Dmitry Torokhov
2006-01-13 22:25                       ` Dmitry Torokhov
2006-01-12  9:07           ` Vojtech Pavlik
2006-01-12  9:07             ` Vojtech Pavlik
2006-01-12 23:39             ` Michael Hanselmann
2006-01-12 23:39               ` Michael Hanselmann
2006-01-13  1:53               ` Benjamin Herrenschmidt
2006-01-13  1:53                 ` Benjamin Herrenschmidt
2005-12-31 23:51   ` Michael Hanselmann
2005-12-31 23:51     ` Michael Hanselmann
2006-01-01  1:33     ` Michael Hanselmann
2006-01-01  1:33       ` Michael Hanselmann
2006-01-01  2:56     ` Benjamin Herrenschmidt
2006-01-01  2:56       ` Benjamin Herrenschmidt
2006-01-01  3:03       ` Michael Hanselmann
2006-01-01  3:03         ` Michael Hanselmann
2006-01-01  6:09         ` Benjamin Herrenschmidt
2006-01-01  6:09           ` Benjamin Herrenschmidt
2006-01-02 22:46       ` Michael Hanselmann
2006-01-02 22:46         ` Michael Hanselmann
2006-01-03  2:29         ` Ben Collins
2006-01-03  2:29           ` Ben Collins
2006-01-03 19:14           ` Michael Hanselmann
2006-01-03 19:14             ` Michael Hanselmann
2006-01-03 19:18             ` Ben Collins
2006-01-03 19:18               ` Ben Collins
2006-01-03 19:25               ` Michael Hanselmann
2006-01-03 19:25                 ` Michael Hanselmann
2006-01-02 12:06     ` Stelian Pop
2006-01-02 12:06       ` Stelian Pop

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200601122312.05210.dtor_core@ameritech.net \
    --to=dtor_core@ameritech.net \
    --cc=linux-input@atrey.karlin.mff.cuni.cz \
    --cc=linux-kernel@hansmi.ch \
    --cc=linux-kernel@killerfox.forkbomb.ch \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=vojtech@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.