On Tue, 23 Oct 2007, Dmitry Torokhov wrote:
> in question. Probably simply adding separate key notify events (such
> as KEY_BRIGHTNESSUP_NOTIFY) to EV_KEY instead of creating EV_NOTIFY is
> not such a bad idea - this way we can fix keymap from userspace (if
> needed) instead of needing to modify th
On 10/18/07, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
> On Thu, 18 Oct 2007, Dmitry Torokhov wrote:
> > On 10/17/07, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
> > > Still, I was
> > > thinking about it, and a doubt came to mind: would it cause problems for a
> > > bitmap
On Thu, 18 Oct 2007, Dmitry Torokhov wrote:
> On 10/17/07, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
> > Still, I was
> > thinking about it, and a doubt came to mind: would it cause problems for a
> > bitmap to share the function for EV_foo and EV_foo notifications?
>
> Not sure if I
On 10/17/07, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
> Still, I was
> thinking about it, and a doubt came to mind: would it cause problems for a
> bitmap to share the function for EV_foo and EV_foo notifications?
>
Not sure if I follow... Are you talking about bringing KEY_*_NOTIFY
On Wed, 17 Oct 2007, Dmitry Torokhov wrote:
> > The use of the same path for notifications and events are already a big
> > enough concession to the HAL model. AFAIK, HAL is the only reason why on
> > most systems the userspace consumer of events and notification events are
> > the same. HAL gets
On 10/17/07, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
> On Wed, 17 Oct 2007, Matthew Garrett wrote:
> > On Wed, Oct 17, 2007 at 11:57:18AM -0400, Dmitry Torokhov wrote:
> > > say that they only care about notifications arising from keypresses
> > > then I will add EV_NOTIFY type of ev
On Wed, 17 Oct 2007, Matthew Garrett wrote:
> On Wed, Oct 17, 2007 at 11:57:18AM -0400, Dmitry Torokhov wrote:
> > say that they only care about notifications arising from keypresses
> > then I will add EV_NOTIFY type of events to input layer. What events
> > would we need? I can imagine:
>
> Why
On Wed, Oct 17, 2007 at 11:57:18AM -0400, Dmitry Torokhov wrote:
> say that they only care about notifications arising from keypresses
> then I will add EV_NOTIFY type of events to input layer. What events
> would we need? I can imagine:
Why use EV_NOTIFY? They're still keys. I'd also quibble with
On 10/16/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> On Tue, 16 Oct 2007, Dmitry Torokhov wrote:
> >
> > I agree that these are 2 different events. My argument is that
> > "VOLUME_UP_NOTIFY" event is similar to "BATTERY_OUT_NOTIFY",
> > "DOCK_UNDOCK_NOTIFY", etc, etc and should be sent not th
On Tue, 16 Oct 2007, Jesse Barnes wrote:
> However, since we already have userspace code in place handling the
> input layer case, why not just go with it? It's fairly straightforward
> and already works in some distros.
That is answered in the thread, as well...
--
"One disk to rule them a
On Tuesday, October 16, 2007 11:25 pm Henrique de Moraes Holschuh wrote:
> On Tue, 16 Oct 2007, Jesse Barnes wrote:
> > > Last time the issue was brought up (and I do believe it was
> > > because of thinkpad-acpi :-) ), he made it clear that any events
> > > you are to act upon are fine in input, b
On Tue, 16 Oct 2007, Jesse Barnes wrote:
> > Last time the issue was brought up (and I do believe it was because
> > of thinkpad-acpi :-) ), he made it clear that any events you are to
> > act upon are fine in input, but events that are just notifications
> > (i.e. the firmware already did the acti
On Tuesday, October 16, 2007 2:18 am Henrique de Moraes Holschuh wrote:
> On Tue, 16 Oct 2007, Jesse Barnes wrote:
> > On Tuesday, October 16, 2007 1:36 am Henrique de Moraes Holschuh
wrote:
> > > You want ACPI video to just pass the messages to userspace when
> > > X.org is driving the backlight?
On Tue, 16 Oct 2007, Dmitry Torokhov wrote:
>
> I agree that these are 2 different events. My argument is that
> "VOLUME_UP_NOTIFY" event is similar to "BATTERY_OUT_NOTIFY",
> "DOCK_UNDOCK_NOTIFY", etc, etc and should be sent not through input
> layer but through a generic (yet to be designed) n
On 10/16/07, Matthew Garrett <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 16, 2007 at 01:48:54PM -0700, Kok, Auke wrote:
>
> > real life example: hook up one of those fancy usb keyboards with volume
> > buttons to
> > your thinkpad. The volume keys on the thinkpad do adjust the volume, the
> > ones o
On Tue, Oct 16, 2007 at 01:48:54PM -0700, Kok, Auke wrote:
> real life example: hook up one of those fancy usb keyboards with volume
> buttons to
> your thinkpad. The volume keys on the thinkpad do adjust the volume, the ones
> on
> the USB keyboard do not - software needs to be able to distingu
Dmitry Torokhov wrote:
> On 10/16/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>>
>> On Tue, 16 Oct 2007, Matthew Garrett wrote:
It still doesn't mean it belongs inside the stream of data for the
keyboard,
maskerading as a key press.
>>> But it *is* a key press!
>> To get somewhat
> > But it *is* a key press!
>
> To get somewhat back on track: volume and brightness (and similar - lid
> close etc) events clearly are keypresses.
>
> However, I would also argue that a keypress that is acted on by the
> firmware automatically is *different* from a keypress that hasn't been
> act
On 10/16/07, Jeremy Katz <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-10-16 at 16:12 -0400, Dmitry Torokhov wrote:
> > On 10/16/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > > On Tue, 16 Oct 2007, Matthew Garrett wrote:
> > > > >
> > > > > It still doesn't mean it belongs inside the stream of data
On 10/16/07, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
>
> And unless Dmitry agrees with Linus' suggestion (maybe as a temporary
> stopgap while something better gets written?), we are not going anywhere,
> anyway.
"Nothing is more permanent than a temporary soution" (not sure who
sai
On Tue, 2007-10-16 at 16:12 -0400, Dmitry Torokhov wrote:
> On 10/16/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > On Tue, 16 Oct 2007, Matthew Garrett wrote:
> > > >
> > > > It still doesn't mean it belongs inside the stream of data for the
> > > > keyboard,
> > > > maskerading as a key press
On 10/16/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Tue, 16 Oct 2007, Matthew Garrett wrote:
> > >
> > > It still doesn't mean it belongs inside the stream of data for the
> > > keyboard,
> > > maskerading as a key press.
> >
> > But it *is* a key press!
>
> To get somewhat back on tra
On Tue, 16 Oct 2007, Matthew Garrett wrote:
> On Tue, Oct 16, 2007 at 12:14:32PM -0700, Linus Torvalds wrote:
> > IOW, I think the thinkpad issue (and others like it) should be fixed by
> > splitting up the KEY_VOLUMEUP "key" into separate KEY_VOLUMEUP and
> > KEY_VOLUMEUP_NOTIFY key events, so t
Matthew Garrett wrote:
On Mon, Oct 15, 2007 at 04:45:10PM -0400, Jeremy Katz wrote:
There are standard keycodes for brightness and volume; map the events to
emit them so that things work properly
We've been doing this in Ubuntu for a couple of years now, with no
obvious difficulty.
One deta
On Tue, Oct 16, 2007 at 12:14:32PM -0700, Linus Torvalds wrote:
> IOW, I think the thinkpad issue (and others like it) should be fixed by
> splitting up the KEY_VOLUMEUP "key" into separate KEY_VOLUMEUP and
> KEY_VOLUMEUP_NOTIFY key events, so that downstream user mode (and the
> kernel itself,
On Tue, 16 Oct 2007, Matthew Garrett wrote:
> >
> > It still doesn't mean it belongs inside the stream of data for the keyboard,
> > maskerading as a key press.
>
> But it *is* a key press!
To get somewhat back on track: volume and brightness (and similar - lid
close etc) events clearly are ke
On Mon, Oct 15, 2007 at 04:45:10PM -0400, Jeremy Katz wrote:
> There are standard keycodes for brightness and volume; map the events to
> emit them so that things work properly
We've been doing this in Ubuntu for a couple of years now, with no
obvious difficulty.
--
Matthew Garrett | [EMAIL PRO
On Tue, Oct 16, 2007 at 02:56:23PM -0200, Henrique de Moraes Holschuh wrote:
> On Tue, 16 Oct 2007, Matthew Garrett wrote:
> > They're keys that generate scancodes through the keyboard controller.
>
> The fact is that we were not used to anything using the keyboard controller
> as a message-passi
On Tue, 16 Oct 2007, Matthew Garrett wrote:
> On Tue, Oct 16, 2007 at 12:31:24PM -0200, Henrique de Moraes Holschuh wrote:
> > On Tue, 16 Oct 2007, Matthew Garrett wrote:
> > > Yes, the firmware acts upon it.
> >
> > So, I'd have to say it doesn't belong on the input layer AFAIK.
> They're keys t
On Tue, Oct 16, 2007 at 11:54:31AM -0400, Dmitry Torokhov wrote:
> I think there was a laptop that sent vierd bytes over KBC port when
> you plug AC cord into it and pulled it out again. So it's not only
> keys. Don't have a reference handy though.
That rings a bell. We can already get that infor
On 10/16/07, Matthew Garrett <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 16, 2007 at 10:27:11AM -0400, Dmitry Torokhov wrote:
>
> > I want to add the ability to add "filetrs" to i8042 keyboard ports so
> > that certain bytes that represent state changes (battery events,
> > wireless, etc.) can be dive
On Tue, Oct 16, 2007 at 10:27:11AM -0400, Dmitry Torokhov wrote:
> I want to add the ability to add "filetrs" to i8042 keyboard ports so
> that certain bytes that represent state changes (battery events,
> wireless, etc.) can be diverted from keyboard serio port (and atkbd
> driver) and be process
On Tue, Oct 16, 2007 at 12:31:24PM -0200, Henrique de Moraes Holschuh wrote:
> On Tue, 16 Oct 2007, Matthew Garrett wrote:
> > Yes, the firmware acts upon it.
>
> So, I'd have to say it doesn't belong on the input layer AFAIK.
They're keys that generate scancodes through the keyboard controller.
On Tue, 16 Oct 2007, Matthew Garrett wrote:
> On Tue, Oct 16, 2007 at 12:11:53PM -0200, Henrique de Moraes Holschuh wrote:
> > On Tue, 16 Oct 2007, Matthew Garrett wrote:
> > > are sent via the keyboard controller, such as the wireless and touchpad
> > > disable keys on my HP. There are Dells that
Hi Henrique,
On 10/16/07, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
> On Tue, 16 Oct 2007, Matthew Garrett wrote:
> > On Mon, Oct 15, 2007 at 07:07:37PM -0200, Henrique de Moraes Holschuh wrote:
> > > And the input subsystem maintainer has made it extremely clear in various
> > > thre
On Tue, Oct 16, 2007 at 12:11:53PM -0200, Henrique de Moraes Holschuh wrote:
> On Tue, 16 Oct 2007, Matthew Garrett wrote:
> > are sent via the keyboard controller, such as the wireless and touchpad
> > disable keys on my HP. There are Dells that do the same for brightness
>
> It is not clear to
On Tue, 16 Oct 2007, Matthew Garrett wrote:
> On Mon, Oct 15, 2007 at 07:07:37PM -0200, Henrique de Moraes Holschuh wrote:
> > And the input subsystem maintainer has made it extremely clear in various
> > threads that the input devices are *not* to be used as a notification
> > service for on-scree
On Mon, Oct 15, 2007 at 07:07:37PM -0200, Henrique de Moraes Holschuh wrote:
> And the input subsystem maintainer has made it extremely clear in various
> threads that the input devices are *not* to be used as a notification
> service for on-screen-display or other such stuff. If you send volume
On Tue, 16 Oct 2007, Jesse Barnes wrote:
> On Tuesday, October 16, 2007 1:36 am Henrique de Moraes Holschuh wrote:
> > You want ACPI video to just pass the messages to userspace when X.org
> > is driving the backlight? Fine with me. That *still* doesn't make
> > it right to get these messages as
On Mon, 15 Oct 2007, Jeremy Katz wrote:
> On Mon, 2007-10-15 at 19:07 -0200, Henrique de Moraes Holschuh wrote:
> > On Mon, 15 Oct 2007, Jeremy Katz wrote:
> > > There are standard keycodes for brightness and volume; map the events to
> > > emit them so that things work properly
> >
> > NAK. It i
On Tuesday, October 16, 2007 1:36 am Henrique de Moraes Holschuh wrote:
> > No, on Lenovo (and in general actually) the firmware should *not*
> > touch the backlight. Otherwise if another driver touches it the
> > driver and
>
> This is not an option on IBM ThinkPads, unless you patch the DSDT on
On Mon, 15 Oct 2007, Jesse Barnes wrote:
> On Monday, October 15, 2007 2:07 pm Henrique de Moraes Holschuh wrote:
> > As for Lenovo thinkpads, brightness control is to be processed by the
> > ACPI video module, so brightness hot keys are not to be reported by
> > default there either. I am not so
On Monday, October 15, 2007 2:07 pm Henrique de Moraes Holschuh wrote:
> We should fix the backlight class to be more useful and support
> poll() or somesuch, for userspace to track the backlight level in a
> resource-friendly way for OSD (the only sane thing to do on an IBM
> thinkpad with such ev
On Mon, 15 Oct 2007 19:07:37 -0200
Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
> On Mon, 15 Oct 2007, Jeremy Katz wrote:
> > There are standard keycodes for brightness and volume; map the
> > events to emit them so that things work properly
>
> NAK. It is the completely wrong thing to
On Mon, 2007-10-15 at 19:07 -0200, Henrique de Moraes Holschuh wrote:
> On Mon, 15 Oct 2007, Jeremy Katz wrote:
> > There are standard keycodes for brightness and volume; map the events to
> > emit them so that things work properly
>
> NAK. It is the completely wrong thing to do for IBM thinkpads
On Mon, 15 Oct 2007, Jeremy Katz wrote:
> There are standard keycodes for brightness and volume; map the events to
> emit them so that things work properly
NAK. It is the completely wrong thing to do for IBM thinkpads which process
volume and brightness completely in firmware.
And the input subs
There are standard keycodes for brightness and volume; map the events to
emit them so that things work properly
Signed-off-by: Jeremy Katz <[EMAIL PROTECTED]>
---
drivers/misc/thinkpad_acpi.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/misc/thin
47 matches
Mail list logo
