linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: linux-input@vger.kernel.org, johannes@sipsolutions.net,
	linux-wireless@vger.kernel.org, dmitry.torokhov@gmail.com
Subject: Re: [PATCH 1/2] input: Add KEY_RFKILL_ALL
Date: Sat, 01 Aug 2009 13:52:22 -0700	[thread overview]
Message-ID: <1249159942.3491.21.camel@localhost.localdomain> (raw)
In-Reply-To: <20090801204534.GA23642@srcf.ucam.org>

Hi Matthew,

> > actually I would prefer if we name this key KEY_RFKILL and not put the
> > policy of ALL into the kernel. Since we wanna get rid of rfkill-input.
> > That needs to be done in userspace and by users policy. If they wanna
> > map that key to ALL then that is fine. If they just wanna toggle WiFi,
> > then that is also fine. If the wanna have to popup some UI, that is also
> > reasonable.
> 
> My reasoning was that this conceptually maps to a key that controls all 
> of the radios in the system - whether a single press actually kills all 
> of them or not is kind of irrelevent (having the simple policy in 
> rfkill-input works fine for this, but userspace will obviously want 
> something more cunning). My concern with KEY_RFKILL is that it it's not 
> obvious that it refers to a specific type of key - ones that purely 
> control wifi should still be KEY_WLAN, for instance.

actually if the key is clearly hardwired to WLAN, then it should not
even show up as input event at all. This is one of the mis-concepts of
the old RFKILL subsystem. No need to send an input event if the platform
driver is going to rfkill that device anyway.

If a key is clearly labeled as WLAN then it should emit only KEY_WLAN.
And if it is just a generic key with some radio on it like FN-F5 on my
ThinkPad, then it better just emits KEY_RFKILL and we let userspace (or
rfkill-input do the policy).

Remember that in the end it is just a key and whatever the user does
with it is users policy. So in summary it is up to the platform driver
to emit the proper key. For some it might be still KEY_WLAN, for other
it might be KEY_RFKILL. Sounds fair?

Regards

Marcel



  reply	other threads:[~2009-08-01 20:52 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-01 18:54 [PATCH 1/2] input: Add KEY_RFKILL_ALL Matthew Garrett
2009-08-01 18:54 ` [PATCH 2/2] rfkill: Add support for KEY_RFKILL_ALL Matthew Garrett
2009-08-01 20:25   ` Bastien Nocera
2009-08-01 20:41     ` Marcel Holtmann
2009-08-01 20:38 ` [PATCH 1/2] input: Add KEY_RFKILL_ALL Marcel Holtmann
2009-08-01 20:45   ` Matthew Garrett
2009-08-01 20:52     ` Marcel Holtmann [this message]
2009-08-01 20:54       ` Matthew Garrett
2009-08-01 21:48         ` Marcel Holtmann
2009-08-01 21:51           ` Matthew Garrett
2009-08-01 22:11             ` Marcel Holtmann
2009-08-01 22:25               ` Matthew Garrett
2009-08-02  7:55                 ` Johannes Berg
2009-08-02  1:05 ` Henrique de Moraes Holschuh
2009-08-02  1:15   ` Matthew Garrett

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=1249159942.3491.21.camel@localhost.localdomain \
    --to=marcel@holtmann.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mjg59@srcf.ucam.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).