I have finished cleaning it up, and I think the final version is ready. It
is in the input-hotkeys branch of the git tree, as usual.
Testing is welcome. It *DOES* change the ABI by default, but that's an ABI
that is *NOT* protected by any of the usual rules, AFAIK. It is all in the
docs, and th
On Mon, 25 Jun 2007, Richard Hughes wrote:
> On Mon, 2007-06-25 at 10:33 -0300, Henrique de Moraes Holschuh wrote:
> > I trust HAL can map switch edge events to launch scripts or
> > an application? If it does not, it needs to, now :-)
>
> Isn't NetworkManager going to handle this?
I bet in-kern
On Mon, 2007-06-25 at 10:33 -0300, Henrique de Moraes Holschuh wrote:
> I trust HAL can map switch edge events to launch scripts or
> an application? If it does not, it needs to, now :-)
Isn't NetworkManager going to handle this?
Richard.
--
On Mon, 25 Jun 2007, Richard Hughes wrote:
> On Sun, 2007-06-24 at 10:46 -0300, Henrique de Moraes Holschuh wrote:
> > On Sun, 24 Jun 2007, Richard Hughes wrote:
> > > > 1. Activate hot key handling and input device handling, with
> > > > most
> > > >keys already mapped by defa
On Sun, 2007-06-24 at 10:46 -0300, Henrique de Moraes Holschuh wrote:
> On Sun, 24 Jun 2007, Richard Hughes wrote:
> > > 1. Activate hot key handling and input device handling, with most
> > > keys already mapped by default in thinkpad-acpi.
> >
> > Mapped to KEY_UNKNOWN?
>
> No, KEY_FN_*,
On Sun, 24 Jun 2007, Richard Hughes wrote:
> > 1. Activate hot key handling and input device handling, with most
> >keys already mapped by default in thinkpad-acpi.
>
> Mapped to KEY_UNKNOWN?
No, KEY_FN_*, except for FN+F4 which is KEY_SLEEP and FN+F12, which is
KEY_SUSPEND. KEY_ZOOM
On Sun, 2007-06-24 at 09:45 -0300, Henrique de Moraes Holschuh wrote:
> Currently, thinkpad-acpi defaults to most hot keys disabled, AND the hot key
> system disabled. This is the firmware default, for obvious reasons
> (DOS/unknown O.S. support using the BIOS). This is also true for all
> versio
Hello Richard,
On Sun, 10 Jun 2007, Richard Hughes wrote:
> On Sat, 2007-06-09 at 16:41 -0300, Henrique de Moraes Holschuh wrote:
> > 1: always generate both events (may cause problems for sleep to disk and
> > sleep to ram, at the very least)
>
> Both events are a pain for HAL to handle, althoug
On Wed, 13 Jun 2007, Richard Hughes wrote:
> > find a way to tap into the ACPI interrupts the low-level firmware does
> > generate when it changes the NVRAM bits.
>
> Yes, although I've had no luck with this on my X60. Ideas welcome.
Activate ACPI debug and tracing, and trap all _Q* ACPI GPE even
On Wed, 2007-06-13 at 11:05 -0300, Henrique de Moraes Holschuh wrote:
> On Sun, 10 Jun 2007, Richard Hughes wrote:
> > On Sat, 2007-06-09 at 16:41 -0300, Henrique de Moraes Holschuh wrote:
> > > Now that KEY_UNKNOWN as the top choice is gone, and that HAL seems to want
> > > to map keys by default,
On Sun, 10 Jun 2007, Richard Hughes wrote:
> On Sat, 2007-06-09 at 16:41 -0300, Henrique de Moraes Holschuh wrote:
> > Now that KEY_UNKNOWN as the top choice is gone, and that HAL seems to want
> > to map keys by default, the solution I used to not generate hotkey input
> > events and ACPI events i
On Sat, 2007-06-09 at 16:41 -0300, Henrique de Moraes Holschuh wrote:
> Now that KEY_UNKNOWN as the top choice is gone, and that HAL seems to want
> to map keys by default, the solution I used to not generate hotkey input
> events and ACPI events in duplicate is busted.
Why busted? Legacy systems
Richard,
Now that KEY_UNKNOWN as the top choice is gone, and that HAL seems to want
to map keys by default, the solution I used to not generate hotkey input
events and ACPI events in duplicate is busted.
I can only think of a few ways to go about it:
1: always generate both events (may cause pro
13 matches
Mail list logo