> Quoting Henrique de Moraes Holschuh <[email protected]>:
> Subject: [PATCH 3/3] ACPI: thinkpad-acpi: change thinkpad-acpi input default and kconfig help
>
> The current kconfig help text was misleading users. Also, the default for
> an input-layer-optimized support caused way too many problems without
> up-to-date userspace in place.
>
> So, rework the help text, and change the default to N. Note that
> distributions are supposed to enable this option as soon as they update HAL
> to a version that handles the thinkpad-acpi new input layer interface.
I don't really know the details here, so I could be completely wrong.
However, generally, forcing HAL and kernel to be in sync really
looks to me like a non-ideal way to handle interface change.
For example, this would mean that one can't use the same kernel
for multiple distributions, and for a person like me
that needs to switch distros all the time, it seems like a pain.
Could not the kernel expose both new and old interfaces
somehow, so that HAL can be updated without recompiling the kernel?
For example, there could be a sysfs interface which let the HAL set
the desired interface version.
Couldn't that work?
This seems easy to code up.
Want a patch like that?
--
MST
On Sat, 11 Aug 2007, Michael S. Tsirkin wrote:
> > Quoting Henrique de Moraes Holschuh <[email protected]>:
> > Subject: [PATCH 3/3] ACPI: thinkpad-acpi: change thinkpad-acpi input default and kconfig help
> >
> > The current kconfig help text was misleading users. Also, the default for
> > an input-layer-optimized support caused way too many problems without
> > up-to-date userspace in place.
> >
> > So, rework the help text, and change the default to N. Note that
> > distributions are supposed to enable this option as soon as they update HAL
> > to a version that handles the thinkpad-acpi new input layer interface.
>
> I don't really know the details here, so I could be completely wrong.
You can get up to speed through the archives of the ibm-acpi-devel
mailinglist at sourceforge.net (or gmane.org).
> However, generally, forcing HAL and kernel to be in sync really
> looks to me like a non-ideal way to handle interface change.
True. But so far I didn't find any better way. Sending hot key events over
the input layer and as an ACPI event at the same time is bound to cause
problems that are not that easy to work around, while configuring the driver
to send one of the two will always work, and autodetecting which channel to
use to deliver events is basically impossible (HAL, for example, always
opens the ACPI event sink, AND all input devices that issue EV_KEY).
I *can* make the compile-time option a module parameter, though. That
wouldn't be much of a problem, and the compile-time option would select the
default for that parameter, but it would be easier to override it at run
time (you can already do it, but it requires reprogramming various driver
parameters using sysfs and the input device IOCTLs).
Would a module parameter address enough of your concerns? Kconfig would
only set the default for that parameter, then...
> For example, this would mean that one can't use the same kernel
> for multiple distributions, and for a person like me
> that needs to switch distros all the time, it seems like a pain.
Setup the driver at boot time, then. You can change its behaviour through
sysfs and some utility that can reprogram an input layer device keymap. Or,
if I add a module parameter that duplicates the compile-time parameter, you
just need to use the module parameter.
> Could not the kernel expose both new and old interfaces
> somehow, so that HAL can be updated without recompiling the kernel?
It exposes all interfaces, all the time. But you have to configure their
behaviour, and since you can't have both active at the same time, you need
to cause the driver to use the one your userland expects.
Also, there is a matter of the default of the hot key functionality (enabled
or disabled, and its masks) which used not to matter much as the driver was
basically useless without a lot configuration from userspace, but that is
not true anymore when dealing with input devices.
> For example, there could be a sysfs interface which let the HAL set
> the desired interface version.
HAL already can do that if it wants. However, driver autodetection
information is lost when the input device is not enabled by default (you
lose the autodetected keymap).
This could be fixed by selecting whether to send events over ACPI or the
input device in a different way (but I found no better compromise than the
one I used. Suggestions?).
--
"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
> I *can* make the compile-time option a module parameter, though. That
> wouldn't be much of a problem, and the compile-time option would select the
> default for that parameter, but it would be easier to override it at run
> time (you can already do it, but it requires reprogramming various driver
> parameters using sysfs and the input device IOCTLs).
>
> Would a module parameter address enough of your concerns? Kconfig would
> only set the default for that parameter, then...
I really think modifying defaults it not a great idea.
What about adding a writeable module parameter?
Then new HAL would just write to /sysfs/module/thinkpad/parameters/interface_version to
switch to new behaviour.
--
MST
On Thu, 16 Aug 2007, Michael S. Tsirkin wrote:
> > I *can* make the compile-time option a module parameter, though. That
> > wouldn't be much of a problem, and the compile-time option would select the
> > default for that parameter, but it would be easier to override it at run
> > time (you can already do it, but it requires reprogramming various driver
> > parameters using sysfs and the input device IOCTLs).
> >
> > Would a module parameter address enough of your concerns? Kconfig would
> > only set the default for that parameter, then...
>
> I really think modifying defaults it not a great idea.
> What about adding a writeable module parameter?
> Then new HAL would just write to /sysfs/module/thinkpad/parameters/interface_version to
> switch to new behaviour.
Nah. This thing regulates what the module has to do when it loads and inits
the firmware, and the whole point of the new behaviour is to get userspace
to be as hands' off as possible, so that we can auto-tune things better
in-kernel, without a need to worry about HAL and friends overwriting local
admin configurations needlessly.
I will probably have to do something like the strict versioned interfaces of
wireless extensions, I think. It really is a case of a deprecation of
current userland interfaces done sanely. Right now I am thinking about
giving userland two kernel releases before I change the default interface
level, and one to two years to remove the older ones.
--
"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
> Quoting Henrique de Moraes Holschuh <[email protected]>:
> Subject: Re: [PATCH 3/3] ACPI: thinkpad-acpi: change thinkpad-acpi input default and kconfig help
>
> On Thu, 16 Aug 2007, Michael S. Tsirkin wrote:
> > > I *can* make the compile-time option a module parameter, though. That
> > > wouldn't be much of a problem, and the compile-time option would select the
> > > default for that parameter, but it would be easier to override it at run
> > > time (you can already do it, but it requires reprogramming various driver
> > > parameters using sysfs and the input device IOCTLs).
> > >
> > > Would a module parameter address enough of your concerns? Kconfig would
> > > only set the default for that parameter, then...
> >
> > I really think modifying defaults it not a great idea.
> > What about adding a writeable module parameter?
> > Then new HAL would just write to /sysfs/module/thinkpad/parameters/interface_version to
> > switch to new behaviour.
>
> Nah. This thing regulates what the module has to do when it loads and inits
> the firmware,
This does not have to be at module load time, though, does it?
> and the whole point of the new behaviour is to get userspace
> to be as hands' off as possible, so that we can auto-tune things better
> in-kernel, without a need to worry about HAL and friends overwriting local
> admin configurations needlessly.
>
> I will probably have to do something like the strict versioned interfaces of
> wireless extensions, I think. It really is a case of a deprecation of
> current userland interfaces done sanely. Right now I am thinking about
> giving userland two kernel releases before I change the default interface
> level, and one to two years to remove the older ones.
--
MST
On Thu, 16 Aug 2007, Michael S. Tsirkin wrote:
> > Quoting Henrique de Moraes Holschuh <[email protected]>:
> > Subject: Re: [PATCH 3/3] ACPI: thinkpad-acpi: change thinkpad-acpi input default and kconfig help
> > On Thu, 16 Aug 2007, Michael S. Tsirkin wrote:
> > > > I *can* make the compile-time option a module parameter, though. That
> > > > wouldn't be much of a problem, and the compile-time option would select the
> > > > default for that parameter, but it would be easier to override it at run
> > > > time (you can already do it, but it requires reprogramming various driver
> > > > parameters using sysfs and the input device IOCTLs).
> > > >
> > > > Would a module parameter address enough of your concerns? Kconfig would
> > > > only set the default for that parameter, then...
> > >
> > > I really think modifying defaults it not a great idea.
> > > What about adding a writeable module parameter?
> > > Then new HAL would just write to /sysfs/module/thinkpad/parameters/interface_version to
> > > switch to new behaviour.
> >
> > Nah. This thing regulates what the module has to do when it loads and inits
> > the firmware,
>
> This does not have to be at module load time, though, does it?
Depends on how you view things. If I do it at any other time, I will
clobber the current configuration of the module, i.e. it will be an
"autoconfig now, overriding current state" trigger. It will also waste a
lot of memory since a big deal of stuff will stop being __init and
__initdata.
Also, it means the configuration the local admin did gets overwritten every
time HAL or something else feels the need to poke thinkpad-acpi (hopefully
once at system startup, but still...). I consider that completely
unacceptable, because in my experience, every time you give someone such a
knob, it is abused.
And if I make it a only-one-use knob (i.e. start returning -EPERM after it
was used once), it is not much different from a module parameter, is it?
And both KISS and the principle of least suprise tells me that in that case
it better be a module parameter.
--
"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