Re: brightness control on thinkpad t61p
On Tue, 2008-01-08 at 14:49 -0200, Henrique de Moraes Holschuh wrote: > On Tue, 08 Jan 2008, Richard Purdie wrote: > > On Tue, 2008-01-08 at 15:54 +, Matthew Garrett wrote: > > > On Tue, Jan 08, 2008 at 03:45:02PM +0000, Richard Purdie wrote: > > > > > > > I did't get enough context above but I went through the archives and it > > > > seems this is about linearising backlight values. > > > > > > Indeed. The ACPI spec provides a range of 0-100, without specifying what > > > this actually means (it gives brightness and power consumption as two > > > different examples). Implementations are only required to support a > > > subset of these, with the others being ignored. The current hook into > > > the backlight class exports this range but provides no means for an > > > application to determine which values are valid - I'd prefer to just > > > flatten the range to remove the holes. Given the lack of standardisation > > > in the real meaning of the values, I don't think exporting the 0-100 > > > range buys us anything. > > > > I agree with that. 0-100 actually breaks a useful and valid way the > > class gets used in the "brightness + 1" case... > > So be it, then. But my request that we get a way to add the information we > are losing to the backlight class still stands. The thing is does this 0-100 value have a use to userspace? Its extremely device specific and can't be exported from the class in a generic way suggesting it should really be something exported by the driver itself. You still have to ask whether userspace actually needs this value though? Kernel debugging is the one use I can see. For that you'd probably be better off with a pr_debug() though. There are hundreds of other 'useful' numbers the kernel has but doesn't export. Cheers, Richard - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: brightness control on thinkpad t61p
On Tue, 2008-01-08 at 15:54 +, Matthew Garrett wrote: > On Tue, Jan 08, 2008 at 03:45:02PM +0000, Richard Purdie wrote: > > > I did't get enough context above but I went through the archives and it > > seems this is about linearising backlight values. > > Indeed. The ACPI spec provides a range of 0-100, without specifying what > this actually means (it gives brightness and power consumption as two > different examples). Implementations are only required to support a > subset of these, with the others being ignored. The current hook into > the backlight class exports this range but provides no means for an > application to determine which values are valid - I'd prefer to just > flatten the range to remove the holes. Given the lack of standardisation > in the real meaning of the values, I don't think exporting the 0-100 > range buys us anything. I agree with that. 0-100 actually breaks a useful and valid way the class gets used in the "brightness + 1" case... Cheers, Richard - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: brightness control on thinkpad t61p
On Tue, 2008-01-08 at 10:48 -0200, Henrique de Moraes Holschuh wrote: > On Tue, 08 Jan 2008, Matthew Garrett wrote: > > On Tue, Jan 08, 2008 at 10:06:53AM -0200, Henrique de Moraes Holschuh wrote: > > > Is there a *real* technical reason why we can't just round to the nearest? > > > That will work well with any firmware, and it will not remove > > > functionality > > > from any box, while at the same time plugging the current issues nicely. > > > > Yes. Software makes the assumption that writing a value larger than the > > current value will result in the value increasing, which isn't > > necessarily true if you round it. > > I dare say that such an assumption is broken for the backlight class, there > is a reason why we have actual_brightness and brightness separate, and it is > just that one AFAIK. I am cc'ing the backlight class maintainer to get his > opinion on the matter. The reason actual_brightness and brightness are two separate things are because some hardware exists that will let you request one brightness but choose one that is different itself. There are also some devices that have backlight limiting in software for use in emergency low battery situations (the battery can get low enough that the device reboots on high backlight but is otherwise usable). I did't get enough context above but I went through the archives and it seems this is about linearising backlight values. You can't just export an interface of 0-100 and hope things will work since you lose the information about which values do something and which don't. I agree something which tells us what those brightness values mean could be useful though, a kind of brightness value <-> relative brightness table. The framebuffer layer has something like this already from before the backlight core was abstracted/standardised. I'd look at that as a first port of call and try to see if it could be integrated into the backlight class somehow. Cheers, Richard - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [4/6] 2.6.21-rc2: known regressions
On Mon, 2007-03-05 at 02:50 +0100, Adrian Bunk wrote: > Subject: LCD is dimmed (ibm-acpi related) > References : http://lkml.org/lkml/2007/2/25/206 > Submitter : Jiri Kosina <[EMAIL PROTECTED]> > Caused-By : Richard Purdie <[EMAIL PROTECTED]> > commit 994efacdf9a087b52f71e620b58dfa526b0cf928 > Handled-By : Jiri Kosina <[EMAIL PROTECTED]> > Richard Purdie <[EMAIL PROTECTED]> > Henrique de Moraes Holschuh <[EMAIL PROTECTED]> > Status : patches are being discussed The confirmed fix is in the ACPI test branch for this. > Subject: no backlight on radeon > References : http://lkml.org/lkml/2007/2/19/1 > Submitter : Yaroslav Halchenko <[EMAIL PROTECTED]> > Alex Romosan <[EMAIL PROTECTED]> > David Miller <[EMAIL PROTECTED]> > Caused-By : James Simmons <[EMAIL PROTECTED]> > commit e0e34ef7f02915cfe50e501e9f32c24217177a96 > Handled-By : Richard Purdie <[EMAIL PROTECTED]> > James Simmons <[EMAIL PROTECTED]> > Henrique de Moraes Holschuh <[EMAIL PROTECTED]> > Status : problem is being discussed > > > Subject : nvidiafb broken > References : http://lkml.org/lkml/2007/2/24/36 > Submitter : Andreas Schwab <[EMAIL PROTECTED]> > Caused-By : Richard Purdie <[EMAIL PROTECTED]> > commit 599a52d12629394236d785615808845823875868 > Handled-By : Richard Purdie <[EMAIL PROTECTED]> > Patch : http://lkml.org/lkml/2007/2/26/43 > Status : patch available The confirmed fixes for both of these are in the backlight tree. I was waiting for any further feedback on the first issue above but will send them to Linus now. Cheers, Richard - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ACPI: ibm-acpi: fix initial status of backlight device
On Wed, 2007-02-21 at 23:16 -0200, Henrique de Moraes Holschuh wrote:
> NOTE: This patch needs an ACK from Richard Purdie before it can be merged,
> as he might want to change the backlight class code instead.
As mentioned elsewhere, we can't do this in the class itself.
> --- a/drivers/acpi/ibm_acpi.c
> +++ b/drivers/acpi/ibm_acpi.c
> @@ -1713,6 +1713,13 @@ static struct backlight_properties ibm_backlight_data
> = {
>
> static int brightness_init(void)
> {
> + int b;
> +
> + b = brightness_get(NULL);
> + if (b < 0)
> + return b;
> + ibm_backlight_data.brightness = b;
> +
> ibm_backlight_device = backlight_device_register("ibm", NULL, NULL,
>&ibm_backlight_data);
This isn't against 2.6.21-rc1 which changed the backlight class a bit.
Basically, you need to set the brightness variable after
backlight_device_register(). It should be simple enough to do and fix
the problem the same way though.
Richard
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sony-laptop: allow complex per-value input/output validation
On Tue, 2007-02-13 at 09:47 +0100, Mattia Dongili wrote: > On Tue, February 13, 2007 5:55 am, Len Brown said: > > On Monday 12 February 2007 16:01, Mattia Dongili wrote: > >> allows consistency between the sony-laptop > >> specific 'brightness_default' and the backlight subsystem 0-based > >> 'brightness'. > > > > Why do we need to have "sony-laptop specific 'brightness_default'" -- > > is that a shortcoming of the backlight subsystem? > > It depends on how do you see it :) > brightness_default is the value that brightness will have at the next (and > later) reboot and it's currently handled as a platform_device attribute. > It would be nice anyway if one such attribute could be added to the > backlight subsystem (I'll provide patches - added rpurdie to the Cc list) > in order to standardize its behavior/interface. The backlight class doesn't really have any reason to know anything about defaults. The current behaviour is that if you want it at a certain 'default' brightness, you set it to this after you register the device. Some devices don't want the brightness changed and want to use whatever it was set to originally. In the case of some other drivers, you can't read the brightness value. With any patches, please keep in mind the changes in http://git.o-hand.com/?p=linux-rpurdie-backlight;a=shortlog;h=for-mm as I've separated out the ops functions from the actual device specific data. Regards, Richard - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git backlight tree
On Sat, 2007-02-10 at 23:45 -0500, Len Brown wrote: > On Saturday 10 February 2007 19:33, Richard Purdie wrote: > > As mentioned previously, I've setup a backlight git tree at: > > > > http://git.o-hand.com/?p=linux-rpurdie-backlight;a=shortlog;h=for-mm > > (git://git.o-hand.com/linux-rpurdie-backlight) > > > > A patch of the combined changes to mainline is: > > > > http://www.rpsys.net/openzaurus/patches/git_backlight-r1.patch.gz > > The changes under drivers/acpi/ and drivers/misc/ look fine to me. > Acked-by: Len Brown <[EMAIL PROTECTED]> > if you need that to send those bits upstream. > > Note that there is a new sony-laptop driver under drivers/misc/ in my tree > that I expect to send upstream next week -- and it will need > the analogous updates. I'd noticed it and had sent Andrew a patch to keep things happy in -mm. Now I know the timescales, I'll wait until after its gone in and fixup the backlight tree accordingly before submitting. Thanks, Richard - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 09/13] acpi: add backlight support to the sony_acpi driver
On Mon, 2007-02-05 at 16:09 -0800, [EMAIL PROTECTED] wrote: > From: Alessandro Guido <[EMAIL PROTECTED]> > > Make the sony_acpi use the backlight subsystem to adjust brightness value > instead of using the /proc/sony/brightness file. (Other settings will > still have a /proc/sony/... entry) > > Signed-off-by: Alessandro Guido <[EMAIL PROTECTED]> > Cc: Stelian Pop <[EMAIL PROTECTED]> > Cc: Richard Purdie <[EMAIL PROTECTED]> Acked-by: Richard Purdie <[EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > --- - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/5] video sysfs support - take 2: Add dev argument for backlight_device_register.
On Wed, 2006-11-08 at 00:33 +0800, Yu Luming wrote:
> This patch set adds generic abstract layer support for acpi video driver to
> have
> generic user interface to control backlight and output switch control by
> leveraging
> the existing backlight sysfs class driver, and by adding a new video output
> sysfs
> class driver.
>
> Patch 1/5: adds dev argument for backlight_device_register to link the class
> device
> to real device object. The platform specific driver should find a way to get
> the real
> device object for their video device.
>
> signed-off-by: Luming Yu <[EMAIL PROTECTED]>
> ---
> drivers/acpi/asus_acpi.c|2 +-
> drivers/acpi/ibm_acpi.c |2 +-
> drivers/acpi/toshiba_acpi.c |3 ++-
> drivers/video/backlight/backlight.c |7 +--
> include/linux/backlight.h |2 +-
> 5 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/video/backlight/backlight.c
> b/drivers/video/backlight/backlight.c
> index 27597c5..1d97cdf 100644
> --- a/drivers/video/backlight/backlight.c
> +++ b/drivers/video/backlight/backlight.c
> @@ -190,8 +190,10 @@ static int fb_notifier_callback(struct n
> * Creates and registers new backlight class_device. Returns either an
> * ERR_PTR() or a pointer to the newly allocated device.
> */
> -struct backlight_device *backlight_device_register(const char *name, void
> *devdata,
> -struct backlight_properties
> *bp)
> +struct backlight_device *backlight_device_register(const char *name,
> + struct device *dev,
> + void *devdata,
> + struct backlight_properties *bp)
> {
> int i, rc;
> struct backlight_device *new_bd;
This patch breaks several platforms. If you're going to add parameters
to a function like backlight_device_register, you could at least grep
the tree and update all the users :-(.
To top it off, someone noticed some of the failures and fixed them but
nobody thought to fix the drivers in drivers/video/backlight itself and
a mac reference seems to have escaped too.
I'll send a patch to to Andrew to clean up this mess...
Richard
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] backlight: do not power off backlight when unregistering (try 2)
On Thu, 2006-11-09 at 22:32 -0200, Henrique de Moraes Holschuh wrote: > ACPI drivers like ibm-acpi are moving to the backlight sysfs infrastructure. > During ibm-acpi testing, I have noticed that backlight_device_unregister() > sets the display brightness and power to zero. > > This causes the display to be dimmed on ibm-acpi module removal. It will > affect all other ACPI drivers that are being converted to use the backlight > class, as well. It also affects a number of framebuffer devices that are > used on desktops and laptops which might also not want such behaviour. > > Since working around this behaviour requires undesireable hacks, Richard > Purdie decided that we would be better off reverting the changes in the > sysfs class, and adding the code to dim and power off the backlight device > to the drivers that want it. This patch is my attempt to do so. > > Patch against latest linux-2.6.git. Changes untested, as I lack the > required hardware. Still, they are trivial enough that, apart from typos, > there is little chance of getting them wrong. > > Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]> > Cc: Richard Purdie <[EMAIL PROTECTED]> > Cc: Andriy Skulysh <[EMAIL PROTECTED]> > Cc: Antonino Daplas <[EMAIL PROTECTED]> Acked-by: Richard Purdie <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] backlight: do not power off backlight when unregistering
On Sun, 2006-11-05 at 20:54 -0200, Henrique de Moraes Holschuh wrote: > ACPI drivers like ibm-acpi are moving to the backlight sysfs infrastructure. > During ibm-acpi testing, I have noticed that backlight_device_unregister() > sets the display brightness and power to zero. > > This causes the display to be dimmed on ibm-acpi module removal. It will > affect all other ACPI drivers that are being converted to use the backlight > class, as well. > > This annoying behaviour in backlight_device_unregister() can either be > reverted, or it can be worked around on acpi drivers by doing a > backlightdevice->props->update_status = NULL before calling > backlight_device_unregister(). > > Given the, AFAIK, lack of a good reason to disable display backlight as the > _general_ behaviour for the entire sysfs class, the attached patch changes > backlight.c to not do so anymore. The reason the corgi code does this is quite simple. If you don't turn off the backlight when unloading the backlight driver, nothing can turn the backlight off. The backlight is the biggest power consumer on corgi and would cause some power drain even if for example you then suspend the device. I never want to end up with those bug reports. I reasoned that other devices would have a similar set of constraints (all the existing users at the time did). On such hardware, deinitialising anything you initialised is the norm and makes sense but the PC/ACPI world is different. Setting backlightdevice->props->update_status = NULL before unregistering is a horrible idea and I don't want to see hacks like that so yes, lets move it back into the drivers. > Since the commit that introduced this behaviour (commit > 6ca017658b1f902c9bba2cc1017e301581f7728d) apparently did so because the > corgi_bl.c driver powered off the backlight, the attached patch also makes > sure that the corgi_bl.c driver will not have its behaviour changed. Those commits were designed to standardise several behaviours amongst several drivers and this specific case was added to the core rather than coding it in each of several drivers. We therefore really need to update those other drivers too (locomo at the very least). Richard - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH] Make ACPI button driver an input device
On Mon, 2006-04-24 at 22:34 +0200, Pavel Machek wrote: > What is on the jack, BTW? Left headphone, right headphone, mic in? Can > all of them be used independently? > > It gets tricky. AC presence isn't a property of a battery for example > > and is in fact more like a switch (my handheld has a mechanical > > switch > > Oops, really? Mechanical switch to sense ac in? (What happens when you > plug in charger but that is not plugged to AC?) Most of the Zaurus devices can measure the AC voltage and make sanity checks on it in the SharpSL Battery/PM code. > I think that AC presence should be handled independently from > battery. There can be >1 battery in the system. Agreed. This is some of the leftover information I'm referring to below. >(Another interesting question is: is AC status 0/1 or is it number of > milivolts?) I'd say millivolts except for the problem of what you do on systems that don't support voltage readings. Use a very high value I guess. For a lot of devices millivolts also means in kernel conversion tables. Do such things belong in kernel or user space? > > to detect when its plugged in) ;). The battery class would export some > > information but not all of it and I don't know where the leftover > > information should go. If I knew that, I'd write the class. > > Leftover information? Where to put AC status and AC voltage readings amongst other things. Another sysfs class? Also, how do you control suspend/resume notifications to userspace if not using APM/ACPI? > I think we should create directory in sysfs, and populate it according > to battery's capabilities. > > Zaurus' battery would have voltage and maybe percent fields. > > ACPI battery would have all the usual fields. > > Another important question is a way for user applications to avoid > polling... but I guess that should be solveable by enabling select on > one of those files. Agreed, this is something that would be needed. Richard - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH] Make ACPI button driver an input device
On Mon, 2006-04-24 at 12:26 -0400, Dmitry Torokhov wrote: > On 4/24/06, Richard Purdie <[EMAIL PROTECTED]> wrote: > > This gets tricky as the handhelds have two "lid" switches. Pictures of > > how it can fold are at http://www.dynamism.com/sl-c3000/main.shtml . To > > summarise, it can be in three positions: > > > > * Screen folded facing the keys (shut like a laptop) > > * Screen open above the keyboard (like an open laptop) > > * Screen folded over the keys but with the screen visible (becomes a > > tablet like handheld with no keyboard) > > > > Shut is when both switches (SW_0 and SW_1) are pressed, open is when > > neither are pressed and the "no keyboard" mode has only one switch > > pressed. > > Ugh... I wonder if we could change SW_0 to report "comletely > shut"/"open" and SW_1 to report orientation. Then we could alias SW_0 > <-> SW_LID, SW_1 <-> SW_TABLET_MODE. I've checked which switch is which and SW_0 is equivalent to SW_LID. We can just rename them and retain compatibility if: SW_0/SW_LID is pressed to indicate shut SW_1/SW_TABLET_MODE is pressed to indicate tablet mode SW_2/SW_HEADPHONE_DETECT is pressed to indicate headphone jack insertion I'm happy to submit a patch to make that change (and remove the as yet unused SW_[3-7] if you like? I realise there are arguments for having the headphone jack control monitoring in the sound driver but this was the nicest way I've found of passing the event to user space to deal with. I didn't want to deal with it in the sound driver as in this case there is no right answer as to what the sound driver should do (we can't detect if it was headphones, a speaker + mic headset etc. or just a mic that was inserted yet we can support all of them). > > If we are going to have a KEY_LID switch, we should probably decide now > > whether the switch is pressed (1) when the lid is either open or shut > > otherwise things are going to get confused. > > SW_LID please. Sorry, I did mean SW_LID. > > I've often wondered whether the input system could/should be used to > > pass more generic events. I know my handheld has lots of other switch > > like events such as MMC/SD card insertion, CF card insertion, a battery > > lock switch, AC power insertion switch and USB cable detection "switch". > > Most of these are currently acted on by the kernel so userspace doesn't > > need to see them but some like the USB cable detection would be useful. > > It could then load the user's chosen USB gadget kernel module for > > example. In that case its a user choice as there is no "right" gadget > > module to autoload. I'm not sure if it would be right for these to go > > via the input system and last time I looked, udev wasn't able to handle > > generic events like this. > > > > I don't think these belong to input system. Yet they're arguably switches and have all the right semantics to be reported as such. I agree they shouldn't be in the input system but where should they be? Currently we don't need most of them but some would be useful. > > Whilst sort of on the subject (AC power switches and AC power events) > > I'd like to see some standard way of exporting power/battery information > > to userspace. Currently, the ARM handhelds use kernel emulation of an > > APM bios and export the battery info as part of that. Making ARM emulate > > ACPI interfaces doesn't appeal. The answer could be a battery sysfs > > class and the above system events interface but I'm open to other > > suggestions. > > > > Having generic battery interface would be nice. It gets tricky. AC presence isn't a property of a battery for example and is in fact more like a switch (my handheld has a mechanical switch to detect when its plugged in) ;). The battery class would export some information but not all of it and I don't know where the leftover information should go. If I knew that, I'd write the class. Cheers, Richard - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH] Make ACPI button driver an input device
On Mon, 2006-04-24 at 10:45 -0400, Dmitry Torokhov wrote: > Yes, I still need to apply it. > > Matthew, I would recommend not adding KEY_LID but using one of the > switch codes (SW_0?) for the lid. > > Richard, on your handhelds what switch would be most similar to > notebook's lid? Should we alias one of the switches to SW_LID? This gets tricky as the handhelds have two "lid" switches. Pictures of how it can fold are at http://www.dynamism.com/sl-c3000/main.shtml . To summarise, it can be in three positions: * Screen folded facing the keys (shut like a laptop) * Screen open above the keyboard (like an open laptop) * Screen folded over the keys but with the screen visible (becomes a tablet like handheld with no keyboard) Shut is when both switches (SW_0 and SW_1) are pressed, open is when neither are pressed and the "no keyboard" mode has only one switch pressed. The final switch (SW_2) is mapped to headphone detection. If we are going to have a KEY_LID switch, we should probably decide now whether the switch is pressed (1) when the lid is either open or shut otherwise things are going to get confused. I've often wondered whether the input system could/should be used to pass more generic events. I know my handheld has lots of other switch like events such as MMC/SD card insertion, CF card insertion, a battery lock switch, AC power insertion switch and USB cable detection "switch". Most of these are currently acted on by the kernel so userspace doesn't need to see them but some like the USB cable detection would be useful. It could then load the user's chosen USB gadget kernel module for example. In that case its a user choice as there is no "right" gadget module to autoload. I'm not sure if it would be right for these to go via the input system and last time I looked, udev wasn't able to handle generic events like this. In an ideal world, given the system nature of the events, perhaps they'd be better suited to a more generalised or specialised piece of code based on the input system. A more general events system would mean we could have: EVENT_LID_SHUT EVENT_LID_OPEN EVENT_LID_OPEN_NOKEYBOARD or similar which would avoid the issues associated with a single SW_LID switch. I suspect there are no easy answers though. Whilst sort of on the subject (AC power switches and AC power events) I'd like to see some standard way of exporting power/battery information to userspace. Currently, the ARM handhelds use kernel emulation of an APM bios and export the battery info as part of that. Making ARM emulate ACPI interfaces doesn't appeal. The answer could be a battery sysfs class and the above system events interface but I'm open to other suggestions. Cheers, Richard - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
