Created attachment 93841 [details]
output of lspci -vvnn

Created attachment 93851 [details]
output of dmidecode

Created attachment 93861 [details]
output of acpidump

(In reply to comment #0)
> POWER_SUPPLY_ENERGY_FULL=59940000
> POWER_SUPPLY_ENERGY_NOW=49750000
> POWER_SUPPLY_CAPACITY=82
> POWER_SUPPLY_MODEL_NAME=Venturi
> POWER_SUPPLY_MANUFACTURER=13-17
> POWER_SUPPLY_SERIAL_NUMBER=01317 01/24/2012

The output show the capacity 82% rather than 100%. Did  I miss something?

POWER_SUPPLY_CAPACITY seems to show the current charging level, not the capacity of the battery. Right now I have POWER_SUPPLY_CAPACITY=24, which corresponds to 'battery percentage' in the output of 'upower --dump' and the value, the GNOME battery status applet gives me.

The relevant values are POWER_SUPPLY_ENERGY_FULL_DESIGN and POWER_SUPPLY_ENERGY_FULL, which are the same in the output I posted above – which means the capacity of the battery should be 100% (like it would be a brand new battery).

Apart from the fact that the battery is one year old and thus can't have a capacity of 100% the HP UEFI Support Environment tells me that 'Charge Capacity' is 92%. The relevant values here are 'Design Capacity' (5400 mAh) and 'Full Charge Capacity' (5020 mAh): 5020 / 5400 = 0,92962963.


So this bug report is about the following values:

Design Capacity: 5400 mAh
Full Charge Capacity: 5020 mAh

and

POWER_SUPPLY_ENERGY_FULL_DESIGN=59940000
POWER_SUPPLY_ENERGY_FULL=59940000.

Created attachment 95911 [details]
debug.patch

Please try this patch. There is a quirk to make ENERGY_FULL equal to 
ENERGY_FULL_DESIGN when the datas from bios are uncorrect. This patch is to comment the quirk.

After applying the patch provided in comment #6, the kernel still reports the same values:

POWER_SUPPLY_NAME=BAT1
POWER_SUPPLY_STATUS=Discharging
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_TECHNOLOGY=Unknown
POWER_SUPPLY_CYCLE_COUNT=0
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=11100000
POWER_SUPPLY_VOLTAGE_NOW=12096000
POWER_SUPPLY_POWER_NOW=8635000
POWER_SUPPLY_ENERGY_FULL_DESIGN=59940000
POWER_SUPPLY_ENERGY_FULL=59940000
POWER_SUPPLY_ENERGY_NOW=53946000
POWER_SUPPLY_CAPACITY=90
POWER_SUPPLY_MODEL_NAME=Venturi
POWER_SUPPLY_MANUFACTURER=13-17
POWER_SUPPLY_SERIAL_NUMBER=01317 01/24/2012

Read dsdt table from bios, all ENERGY_FULL_DESIGN and ENERGY_FULL are from BIF method. Their value are in same process.

BIF return package definition.
ACPI 5.0 spec page 497
Package {
	Power Unit // Integer (DWORD)
	Design Capacity // Integer (DWORD) 
	Last Full Charge Capacity // Integer (DWORD)
	Battery Technology // Integer (DWORD)
	Design Voltage // Integer (DWORD)
	Design Capacity of Warning // Integer (DWORD)
	Design Capacity of Low // Integer (DWORD)
	Battery Capacity Granularity 1 // Integer (DWORD)
	Battery Capacity Granularity 2 // Integer (DWORD)
	Model Number // String (ASCIIZ)
	Serial Number // String (ASCIIZ)
	Battery Type // String (ASCIIZ)
	OEM Information // String (ASCIIZ)
}

Method (_BIF, 0, NotSerialized)
{
    Name (STAT, Package (0x0D)
    {
        One,
        0x1770,<= initial value of ENERGY_FULL_DESIGN
        0x1770,<= initial value of ENERGY_FULL
        One,
        0x2A30,
        0x0258,
        0xB4,
        0x0108,
        0x0EC4,
        "PABAS0241231",
        "41167",
        "Li-Ion",
        "Hewlett-Packard"
    })
    Store (^^EC0.BAM0, Index (STAT, Zero))
    Store (^^EC0.GBMN (), Index (STAT, 0x09))
    Store (^^EC0.GUBS (), Index (STAT, 0x0A))
    Store (^^EC0.GUBT (), Index (STAT, 0x0B))
    Store (^^EC0.GUBI (), Index (STAT, 0x0C))
    If (ECOK ())
    {
        Store (^^EC0.BDN0, Local0)
        Store (Local0, BMDL)
        Store (Multiply (^^EC0.BDC0, 0x0A), Index (STAT, One))<= FULL_DESIGN
        Sleep (0x14)
        Store (Multiply (^^EC0.BDC0, 0x0A), Local2)
        Store (Local2, Index (STAT, 0x02))<= FULL
        Sleep (0x14)
        If (Local2)
        {
            Divide (Local2, 0x64, Local0, Local1)
            Multiply (Local1, 0x05, Local1)
            Store (Local1, Index (STAT, 0x05))
            Divide (Local2, 0x64, Local0, Local1)
            Multiply (Local1, 0x03, Local1)
            Store (Local1, Index (STAT, 0x06))
        }

        Store (^^EC0.BDV0, Index (STAT, 0x04))
        Sleep (0x14)
    }

    Return (STAT)
}

From the bios code, the values for ENERGY_FULL_DESIGN and ENERGY_FULL are always same. This is a bios bug.

Thanks, I think I can confirm that this is a BIOS bug: I had access to another HP Folio 13-1200 running Windows 7 today and I checked the battery information in Windows with 'powercfg -energy'. The reported values for 'Design capacity' (=ENERGY_FULL_DESIGN) and 'Last full charge' (=ENERGY_FULL) are the same: 59940.

The correct values for this notebook, which are reported by the 'HP UEFI Support Environment' as well as the Windows program 'HP Support Assistant', are: 'Design Capacity' (=ENERGY_FULL_DESIGN) 5400 mAh and 'Full Charge Capacity' (=ENERGY_FULL) 5075 mAh. Thus, the real charge capacity is 94%.


For more testing I downloaded a freeware tool to access more battery info. The tool provided just the same information as the linux kernel on my notebook. Now, the strange thing is, that the percentage (remaining CAPACITY) reported by Windows 7 (as well as the freeware tool) and the 'HP Support Assistant' are all the same – even if the ENERGY_FULL values are different.

How's that possible? Not only the ENERGY_FULL values, but *also the ENERGY_NOW values* differ, even though the reported values for VOLTAGE_NOW (terminal voltage) are the same. For example right now I get the following values:

1. With 'HP Support Assistant':
ENERGY_FULL_DESIGN = 5400 mAh
ENERGY_FULL        = 5036 mAh
ENERGY_NOW         = 4495 mAh
CAPACITY           = 89% (makes sense: 4495 / 5036 = 0,89257)
VOLTRAGE_NOW       = 11.996 mV

2. With the freeware tool under Windows 7:
ENERGY_FULL_DESIGN = 59.940 mWh
ENERGY_FULL        = 59.940 mWh
ENERGY_NOW         = 53.346 mWh
CAPACITY           = 89% (makes sense: 53.346 / 59.940 = 0,88999)
VOLTRAGE_NOW       = 11.996 mV.


I don't really get it. However, this really seems to be just another BIOS bug…

Look like you have encountered some other bios bugs.
Could you share your info?  :)
Close this bug first.

You were the one who told me bug #52111 would be a BIOS bug ;) I'd guess it was a symptom of this bug here.

There are several power management issues (symptoms?) on this notebook and I'm not sure if and how they are connected. Take for example bug #54621: I don't know how that bug could have anything to do with this issue, since it affects the battery as well as the ac adapter (the kernel doesn't produce uevents for any of those two devices) while here only the battery is affected.

I can think of easy workarounds for bug #52111 and this one: for example change org.gnome.settings-daemon.plugins.power use-time-for-policy to false and set percentage-critical to 7 and percentage-action to 5. However, this doesn't help as long as bug #54621 isn't fixed since upower will never update the status of the ac adapter. And I really can't think of an easy workaround for this. Maybe I could ask the upower developers to force status updates not only for the battery but also for the ac adapter…

At least I know that I shouldn't have any hope that the vendor will fix the broken BIOS. HP support told me, that as long as I don't touch the Windows power setting's defaults (send to hibernate at 5% battery capacity) I'd be just fine and that the notebook 'works as designed'.