On Thursday, December 11, 2014 01:05:49 PM Colin Percival wrote:
On 12/11/14 11:08, John Baldwin wrote:
On Sunday, December 07, 2014 2:53:37 am Colin Percival wrote:
On my Dell Latitude E7440 laptop, the ACPI reports two batteries: First
the battery which exists; and second, a Not Present
On 12/12/14 07:21, John Baldwin wrote:
On Thursday, December 11, 2014 01:05:49 PM Colin Percival wrote:
On 12/11/14 11:08, John Baldwin wrote:
Does setting hint.battery.1.disabled=1 work for you?
That fixes the dev.battery sysctls and KDE's battery monitor. The
hw.acpi.battery.units sysctl
On Fri, 12 Dec 2014 14:36:18 -0800, Colin Percival wrote:
On 12/12/14 07:21, John Baldwin wrote:
On Thursday, December 11, 2014 01:05:49 PM Colin Percival wrote:
On 12/11/14 11:08, John Baldwin wrote:
Does setting hint.battery.1.disabled=1 work for you?
That fixes the dev.battery
Just remember, batteries can come and go, so we can't just ignore a
battery because the status says not present.
So I think it's a bug in hald.
-adrian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To
On Sunday, December 07, 2014 2:53:37 am Colin Percival wrote:
Hi ACPI people,
On my Dell Latitude E7440 laptop, the ACPI reports two batteries: First
the battery which exists; and second, a Not Present battery with zeroed
statistics. FreeBSD, not realizing that this second battery is a
On 12/11/14 11:08, John Baldwin wrote:
On Sunday, December 07, 2014 2:53:37 am Colin Percival wrote:
On my Dell Latitude E7440 laptop, the ACPI reports two batteries: First
the battery which exists; and second, a Not Present battery with zeroed
statistics. FreeBSD, not realizing that this
On Tue, 9 Dec 2014 10:42:39 +0100, Dan Lukes wrote:
On 12/09/14 06:33, Ian Smith:
Normally with 2 batteries catered for and only one fitted you'd expect to
see
battery1: ACPI Control Method Battery on acpi0
battery1: battery initialization start
battery1: battery initialization
On 12/09/14 06:33, Ian Smith:
Normally with 2 batteries catered for and only one fitted you'd expect to see
battery1: ACPI Control Method Battery on acpi0
battery1: battery initialization start
battery1: battery initialization failed, giving up
Just for the completeness ...
... it is
On 12/08/14 15:27, Adrian Chadd wrote:
What's the output of acpiconf -i0 and acpiconf -i1?
acpiconf -i0 is exactly what you'd expect. acpiconf -i1 shows blank for
the model/serial/type/OEM info strings, and 0 mAh/mV for the rest except
State which is not present.
I wonder if changing 'state'
On 12/08/14 21:33, Ian Smith wrote:
And what does 'grep battery /var/run/dmesg.boot' have to say? Normally
with 2 batteries catered for and only one fitted you'd expect to see eg:
./nicks_acpi/dmesg-bootwithacpi-2-part.txt:battery0: ACPI Control Method
Battery on acpi0
On 12/07/14 08:03, Adrian Chadd wrote:
How's this work on other systems? KDE on Linux doesn't lose its mind
if the second battery is totally flat.
I just booted Ubuntu 14.04, and both batteries appear in /proc/acpi/battery;
but BAT1 just shows present: no without any statistics, and the GUI
What's the output of acpiconf -i0 and acpiconf -i1?
I wonder if changing 'state' to something else would keep everything happy.
-adrian
On 8 December 2014 at 15:08, Colin Percival cperc...@freebsd.org wrote:
On 12/07/14 08:03, Adrian Chadd wrote:
How's this work on other systems? KDE on
On Mon, 8 Dec 2014 15:27:10 -0800, Adrian Chadd wrote:
What's the output of acpiconf -i0 and acpiconf -i1?
I wonder if changing 'state' to something else would keep everything happy.
On 8 December 2014 at 15:08, Colin Percival cperc...@freebsd.org wrote:
On 12/07/14 08:03, Adrian
Colin Percival wrote:
it seems like not attaching a non-present battery would be a good idea. This
shouldn't be the default behaviour, since
there are plenty of systems where a non-present battery might be inserted at
a later time; but I see nothing wrong with adding an option.
The
On 12/07/14 00:28, Dan Lukes wrote:
Colin Percival wrote:
it seems like not attaching a non-present battery would be a good idea.
This shouldn't be the default behaviour, since
there are plenty of systems where a non-present battery might be inserted at
a later time; but I see nothing wrong
Colin Percival wrote:
The attached patch adds a acpi.cmbat.hide_not_present loader tunable which,
as the name suggests, hides non-present batteries; this is done in the probe
code by returning ENXIO
No, but it may be more useful to create more generalized interface.
I agree in theory, but
Hi,
Wait - so it reports a battery with 0% in it, but not that it's not present?
How's this work on other systems? KDE on Linux doesn't lose its mind
if the second battery is totally flat.
-adrian
On 6 December 2014 at 23:53, Colin Percival cperc...@freebsd.org wrote:
Hi ACPI people,
On
On 12/07/14 08:03, Adrian Chadd wrote:
Wait - so it reports a battery with 0% in it, but not that it's not present?
It reports all zeroes: Not Present, 0% power, 0V, 0mA design capacity, etc.
How's this work on other systems? KDE on Linux doesn't lose its mind
if the second battery is totally
On 07/12/2014 22:49, Colin Percival wrote:
On 12/07/14 08:03, Adrian Chadd wrote:
Wait - so it reports a battery with 0% in it, but not that it's not present?
It reports all zeroes: Not Present, 0% power, 0V, 0mA design capacity, etc.
How's this work on other systems? KDE on Linux doesn't
19 matches
Mail list logo
