From: David Zeuthen <david@fubar.dk>
To: linux-hotplug@vger.kernel.org
Subject: Re: can't seem to ignore a battery
Date: Thu, 12 Nov 2009 16:50:37 +0000 [thread overview]
Message-ID: <1258044637.2168.11.camel@localhost.localdomain> (raw)
In-Reply-To: <29507.1258042014@foxharp.boston.ma.us>
Hey,
On Thu, 2009-11-12 at 11:06 -0500, Paul Fox wrote:
> i'm hoping someone can explain why my rule containing an
> "ignore_device" option for a power_supply device seems to be
> ignored. some sample output from udevadm test, and udevadm are
> available here: http://pastie.org/695548
Like last_rule (which we covered a few weeks ago), things like
ignore_device probably needs to go (although I haven't thought much
about it and I don't know why it was added - probably a broken driver I
guess). Trying to hide or ignore events at the udev level is just wrong
on a number of levels.
> (it may be that i simply have a gross misunderstanding about
> how udev and its clients interact -- this is as deep as i've
> ever delved here.)
>
> background: this is on the OLPC XO-1.5 laptop. we have a legacy
> battery driver that we need to keep running for a while, a) because
> it provides some data that our power analysis scripts rely on,
> and b) because we don't yet trust the DSDT code that drives the
> ACPI driver.
>
> because of the duplicate battery issue (see question #1 of the
> g-p-m FAQ) i'd like hal and devkit to simply ignore the legacy
> driver. i can easily fix hal with an fdi snippet, but haven't
> figured out how to do the same with devkit-power. i assumed
> using a udev "ignore_device" option would take care of it, but
> that's where i'm having trouble.
You probably want a feature in DeviceKit-power so you can set the udev
property DKP_PRESENTATION_HIDE to 1 so the daemon can convey to users
(such as gnome-power-manager) that a given device should be ignored for
presentation and/or policy.
We have similar things in DeviceKit-disks (such as
DKD_PRESENTATION_HIDE) for this - see the DeviceKit-disks man page for
details. Talk to Richard (Cc'ed) about such a feature?
Thanks,
David
next prev parent reply other threads:[~2009-11-12 16:50 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-12 16:06 can't seem to ignore a battery Paul Fox
2009-11-12 16:50 ` David Zeuthen [this message]
2009-11-12 17:33 ` Richard Hughes
2009-11-12 17:40 ` Paul Fox
2009-11-12 17:43 ` David Zeuthen
2009-11-13 2:01 ` Kay Sievers
2009-11-13 2:44 ` Paul Fox
2009-11-13 4:54 ` Greg KH
2009-11-13 14:13 ` Kay Sievers
2009-11-13 14:33 ` Paul Fox
2009-11-13 14:43 ` Justin Schoeman
2009-11-13 16:48 ` Greg KH
2009-11-13 16:49 ` Greg KH
2009-11-13 17:29 ` Justin Schoeman
2009-11-13 17:38 ` Greg KH
2009-11-13 18:22 ` Justin Schoeman
2009-11-13 18:43 ` Paul Fox
2009-11-13 20:33 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1258044637.2168.11.camel@localhost.localdomain \
--to=david@fubar.dk \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).