Re: [ibm-acpi-devel] ACPI: thinkpad-acpi: make the input event mode the default

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 15 Jul 2007, Matthew Garrett wrote:
> On Sun, Jul 15, 2007 at 07:08:01PM -0300, Henrique de Moraes Holschuh wrote:
> > On Sun, 15 Jul 2007, Matthew Garrett wrote:
> > > Right now, the hotkey functionality of the driver is not terribly useful 
> > > without (bleeding-edge) userspace. This is inconsistent with the 
> > > majority of input drivers which do something broadly sane in that 
> > > situation.
> > 
> > It works better with non-bleeding-edge userspace the way I did it, as far as
> > I know. So I'll need some explanations about what I should be doing
> > differently.
> > 
> > Here's my view on things:
> > 
> > Non-bleeding-edge userspace screws up volume control if I send events.  And
> > so does bleeding-edge userspace for that matter, AFAIK.
> 
> No, it doesn't. It interacts in a way that you may not consider to be 
> ideal - the vast majority of our users appear to prefer it to the 
> previous behaviour, so it's better than nothing.

I don't go for "better than nothing", when there is a way to have it right
(and there is: an alsa mixer, or an extension to the input layer).

> > Non-bleeding-edge userspace screws up brightness control if I send events.
> 
> No. Nothing will screw up if you send brightness events.

It can, if it feed backs a brightness up order to the kernel, either
through thinkpad-acpi, or through the ACPI video driver at the wrong time
(before the thinkpad firmware did it).  And before you think the firmware
might be doing something sane for a change, I've had reports of more than
half-a-second delay on a X60s without the latest EC between a brightness
change order, and the hardware responding to it.

A bad feedback will either increase brightness once with two writes (waste
of resources, but the user won't notice, and I hope the thinkpad hardware is
not so crappy as to bother the inverter in this case), increase twice, or
cause a loop (got a report, don't know how it happened, but I *do* know the
code has no defense --yet-- against such a loop) that makes it increase the
brightness all the way up or all the way down until you press some other key
that disturbs the loop.

I actually prefer Lenovo's idea of not handling brightness up/down in
firmware anymore, and just reporting the keys...

> > Bleeding-edge userspace needs to be told it exists, anyway, to make proper
> > use of it, and can be told to enable it on the driver while at it.
> 
> We've been listening for KEY_BRIGHTNESS* on Thinkpads for over a year. 
> It's already implemented and works fine.

If everything did it right, I would have never heard of it.  Note that I am
not accusing HAL of breakage, I am talking about *userspace*.  I am *not*
sure if hal is what broke it, and, if it indeed was hal, whether it was new
enough.  I am sure bleeding-edge hal does something sensible for brightness,
and I have no reasons not to believe you that one-year-old hal will do
something wrong, either.  But there is other userspace, AND much older hal.

> > Non-bleeding-edge userspace that is not broken can remap keys already.
> > FN+F1 generating KEY_FN_F1 makes a lot more sense to someone which has a
> > blank FN+F1 key, than it generating "KEY_FOOBAR".
> 
> That's fine. Send KEY_FN_F1 if there's no label.

Isn't that what I am doing right now?  That's why I asked you which key
codes I was missing when you complained about it. I really don't know of
any.

> > So exactly what should I be changing to make it more useful?  WHAT hot keys
> > do you want mapped by default, and to which key codes?  And forget the ones
> > that need passive handling, these are not mapped for a very different
> > reason.
> 
> On a machine with a glyph, the driver should generate a keycode 
> appropriate for that glyph.

It already does so for every key with a glyph that requires active handling
AND which is present on most thinkpads AND for which I could find a sensible
keycode.

Oh, I miss an undock/eject generic device keycode, too.  Can't use EJECTCD
to undock...

Again, what you want me to change in that default key code matrix that is
not a passive-action key?  I aimed to do the best I could according to the
info I have (http://thinkwiki.org/wiki/Default_meanings_of_special_keys).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux