From: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
Add input device support to the hotkey subdriver.
Hot keys that have a valid keycode mapping are reported through the input
layer if the input device is open. Otherwise, they will be reported as
ACPI events, as they were before.
Scan codes a
Add input device support to the hotkey subdriver.
Hot keys that have a valid keycode mapping are reported through the input
layer if the input device is open. Otherwise, they will be reported as
ACPI events, as they were before.
Scan codes are reported (using EV_MSC MSC_SCAN events) along with E
On Mon, Jul 16, 2007 at 03:19:11PM -0300, Henrique de Moraes Holschuh wrote:
> Anyway, if the input layer is really not the place for "passive key
> presses", then my decision to not issue input events for such stuff is the
> correct one.
That wasn't my interpretation of what Dmitry said - it's n
On Mon, 16 Jul 2007, Matthew Garrett wrote:
> On Mon, Jul 16, 2007 at 11:46:26AM -0400, Dmitry Torokhov wrote:
> > How do you know that this is a "passive keypress"? Can you put another
> > (better) soundcard in a docking station? Woudl the firmware still
> > control that card (doubtful)? Do we wan
On Mon, Jul 16, 2007 at 11:46:26AM -0400, Dmitry Torokhov wrote:
> How do you know that this is a "passive keypress"? Can you put another
> (better) soundcard in a docking station? Woudl the firmware still
> control that card (doubtful)? Do we want the same keys to control that
> card's volume?
T
On 7/15/07, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
On Sun, 15 Jul 2007, Matthew Garrett wrote:
> On Sun, Jul 15, 2007 at 05:59:34PM -0300, Henrique de Moraes Holschuh wrote:
> > *HAL* does. HAL is *not* all there is to userspace. The input layer is not
> > an interface between t
On Sun, 15 Jul 2007, Matthew Garrett wrote:
> On Sun, Jul 15, 2007 at 06:54:53PM -0300, Henrique de Moraes Holschuh wrote:
> > On Sun, 15 Jul 2007, Matthew Garrett wrote:
> > > Hal is the only piece of userspace that knows how to speak to more than
> > > one type of backlight in any useful way, wh
On Sun, Jul 15, 2007 at 06:54:53PM -0300, Henrique de Moraes Holschuh wrote:
> On Sun, 15 Jul 2007, Matthew Garrett wrote:
> > Hal is the only piece of userspace that knows how to speak to more than
> > one type of backlight in any useful way, which makes it the de-facto
> > reference for how use
On Sun, 15 Jul 2007, Matthew Garrett wrote:
> On Sun, Jul 15, 2007 at 05:59:34PM -0300, Henrique de Moraes Holschuh wrote:
> > *HAL* does. HAL is *not* all there is to userspace. The input layer is not
> > an interface between the kernel and HAL, it is an interface between kernel
> > and userspac
On Sun, Jul 15, 2007 at 05:59:34PM -0300, Henrique de Moraes Holschuh wrote:
> *HAL* does. HAL is *not* all there is to userspace. The input layer is not
> an interface between the kernel and HAL, it is an interface between kernel
> and userspace.
Hal is the only piece of userspace that knows h
On Sun, 15 Jul 2007, Matthew Garrett wrote:
> On Sun, Jul 15, 2007 at 05:03:38PM -0300, Henrique de Moraes Holschuh wrote:
> > I do not consider screwing up the mixer handling a harmless result.
>
> We've shipped in this configuration for over a year. Total number of
> bugs filed? None. It's not
On Sun, Jul 15, 2007 at 05:03:38PM -0300, Henrique de Moraes Holschuh wrote:
> I do not consider screwing up the mixer handling a harmless result.
We've shipped in this configuration for over a year. Total number of
bugs filed? None. It's not ideal, but it's simply not true that it
results in a
On Sun, 15 Jul 2007, Matthew Garrett wrote:
> > No. This is handled in firmware in IBM thinkpads, and userspace only screws
> > it up. I am tired of watching people get this routed to the AC97 mixer by
> > default. That is a fringe configuration that only makes sense when using a
> > dock, and w
On Sun, Jul 15, 2007 at 03:12:33PM -0300, Henrique de Moraes Holschuh wrote:
> On Sat, 14 Jul 2007, Matthew Garrett wrote:
> > KEY_BRIGHTNESSUP
>
> Only if I start filtering it out when disabled by the mask. This key is not
> to be sent to userspace unless explicitly configured to do so by someth
On Sat, 14 Jul 2007, Matthew Garrett wrote:
> On Sat, Jul 14, 2007 at 11:11:59AM -0300, Henrique de Moraes Holschuh wrote:
> > +static u16 hotkey_keycode_map[] = {
> > + /* Scan Codes 0x00 to 0x0B: ACPI HKEY FN+F1..F12 */
> > + KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
> > + KEY_UNK
On Sat, Jul 14, 2007 at 11:11:59AM -0300, Henrique de Moraes Holschuh wrote:
> +static u16 hotkey_keycode_map[] = {
> + /* Scan Codes 0x00 to 0x0B: ACPI HKEY FN+F1..F12 */
> + KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
> + KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
>
Add input device support to the hotkey subdriver.
Hot keys that have a valid keycode mapping are reported through the input
layer if the input device is open. Otherwise, they will be reported as
ACPI events, as they were before.
Scan codes are reported (using EV_MSC MSC_SCAN events) along with E
Add input device support to the hotkey subdriver.
Hot keys that have a valid keycode mapping are reported through the input
layer if the input device is open. Otherwise, they will be reported as
ACPI events, as they were before.
Scan codes are reported (using EV_MSC MSC_SCAN events) along with E
Add input device support to the hotkey subdriver. Hotkeys are reported
both as an ACPI event, and through the input layer.
This patch is based on a patch by Richard Hughes <[EMAIL PROTECTED]>.
Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
Cc: Richard Hughes <[EMAIL PROTECTED]>
-
19 matches
Mail list logo
