Re: [patch] add INPUT key reporting to thinkpad_acpi

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

 



On Mon, 2007-05-21 at 10:05 -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 21 May 2007, Richard Hughes wrote:
> > > > One comment I was about to make, are the INPUT events emitted even
> > > > without a "echo enable,0xffff >/proc/acpi/ibm/hotkey"?
> > > 
> > > No, they are not.
> > 
> > Ick. 
> 
> There is no way around that.  It is how these things work.  You are actually
> requesting to the firmware that "OSI will handle these hotkeys".

On all models? When I enable my hkeys on my X60, the hardware still does
the actions.

> And I suspect we are missing part of the interface on the X60 new BIOS, too.
> Is a X60 onwer up to some DSDT debugging ?

I have an X60, although the bios is 2.03 iirc.

> > Sure, I think only KEY_FN_HOME and KEY_FN_END are needed for my X60.
> 
> Also KEY_FN_BACKSPACE, KEY_FN_INSERT and KEY_FN_DELETE, if it is anything
> like the T43.

Ahh, I do not have graphics on those keys.

> > Alternatively, we could match against the dmi data (from the dmi class)
> > and then do the conversion of FnF2 to KEY_LOCK in the thinkpad_acpi
> > driver itself.
> 
> Won't help.  Many of these keys have no set meaning.

Sure.

> > > I am still trying to get the input events routed to the core keyboard.  Do
> > > you know how that can be archieved?  Right now they work just fine, but you
> > > have to open and process the relevant event* device to get the events...
> > 
> > Yes, I found that KEY_POWER would be routed, but KEY_FN_F1 would not be.
> > I suspect something is filtering these keys.
> 
> I will check more on this later.

If you use evtest, the events get through to it, but not to X.

> > > It is already working on 2.6.20, though, with some rough edges on the
> > > keycode remap sysfs interface (it requires binary attributes, which I am
> > > dealing with for the first time in my life).
> > 
> > What is the keycode-remap interface? Do you mean using something like a
> > kernel version of KDSETKEYCODE?
> 
> It is a binary attribute, that looks like a little-endian file composed of
> u16 values.  Read from it to get the current hotkey->keycode map, write to
> it to change the mapping.  There are 16 keycodes right now, but if we find
> out the hotkey interface in ACPI can be extended, it will grow.
> 
> KEY_RESERVED disables the issuing of input events for that key.  Anything
> else (valid) enables it, including KEY_UNKNOWN.
> 
> Would HAL need to mess with these?  If it does, it means I need to add a
> lock attribute that disables changes to it (which HAL is *not* allowed to
> touch) so as to allow the admin to preserve his setup.

Well, at the moment the input stuff is al up in the air, and so we can
do this anyway that works. My preference is as much stuff in the kernel,
and then do the fancy stuff in HAL.

> > Also, is the aim to deprecate or remove the hotkey events, or shall I
> > add workarounds to HAL so we don't get double events?
> 
> There is a bit of a problem.  The ACPI hotkey events are complete, and can
> handle *anything* the firmware produces as long as there is code in
> thinkpad-acpi to intercept the events.

Sure, but currently usersapce is unaware of the ibm acpi events, unless
HAL proxies them using DBUS. This is obviously non-ideal.

> Is there an event we can send through the input layer capable of carrying a
> 16-bit value ?  Otherwise, I can remove the ACPI events, but I'd have to add
> generic uevents to replace them.

What sort of value? If it's not a keypress then a uevent seems most sane
IMO.

> As for double event suppresion, it is probably best if we make it in-kernel.
> It really doesn't make much sense to generate both events, but at the same
> time, I don't want to break existing systems.

Sure.

> It probably makes sense to suppress ACPI events to any hotkets mapped to a
> non-KEY_RESERVED keycode if the input device is open by default, with some
> sort of sysfs override for this.  Would that work?  HAL is not to touch the
> override, of course.

Yes, that sounds very sane.

Richard.




-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
ibm-acpi-devel mailing list
ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

[Index of Archives]     [Linux ACPI]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Photo]     [Yosemite Photos]     [Yosemite Advice]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux