HAL and INPUT

[Richard Hughes]

On Sun, 2007-07-08 at 20:09 +0300, Daniel Stone wrote:
> On Tue, Jul 03, 2007 at 02:01:54PM +0100, ext Richard Hughes wrote:
> > What are we doing with HAL and INPUT? Currently HAL exposes buttons such
> > as LID with state and other buttons such as POWER without state.
> > 
> > With the new INPUT world-order, we will have several event devices that
> > can emit devices of different types.
> 
> Hi,
> Forgive the stupid question, but by 'INPUT', I assume you mean input via
> evdev (i.e. /dev/input/event*), right?

Sure, sorry for being vague.

> > So I think, ideally we need to do:
> > 
> > * hardware remaping of keys using the keymap addon
> > * for each input device:
> >  - create a new individual hal device for any 'interesting' buttons and
> > launch an addon monitoring the event file.
> >  - and buttons that have state then merge in the extra properties
> 
> Sounds sensible to me, assuming that this is just things like
> lid/sleep/whatever.

Sure, we need to define the "whatever". Maybe just do lids that are
useful to the session to know if they exist, like suspend and lid.

> Most multimedia keys (e.g. play/pause, mute, those
> infurating 'your very own key' custom keys, whatever) should probably
> get punted through to X, I believe.

Totally agree. We need to document all of this - do you have any wiki
type thing setup that i can add to?

> > Or we can rip out all the input parts from HAL (but keep keymap) and
> > just reply on querying XOrg for buttons and state.
> 
> X is bad for querying state, really.

Hmm, not just me then :-)

Richard.