Created attachment 64665 [details]
screenshot

The labels at least seem out of order.

You're using 0.5kW of power! That must be one hell of a laptop.

Seriously tho, what are the values from "lshal |grep rate" when you get these crazy numbers?

Richard.

lshal|grep rate
  battery.charge_level.rate = 27572400  (0x1a4b8b0)  (int)
  battery.reporting.rate = 2484  (0x9b4)  (int)

Ok, so they aren't out of order but rather truncated (I added a gpm_debug):
[gpm_graph_draw_labels] gpm-graph-widget.c:439 (13:30:25):       LABEL: 26190W
[gpm_graph_draw_labels] gpm-graph-widget.c:439 (13:30:25):       LABEL: 23571W
[gpm_graph_draw_labels] gpm-graph-widget.c:439 (13:30:25):       LABEL: 20952W
[gpm_graph_draw_labels] gpm-graph-widget.c:439 (13:30:25):       LABEL: 18333W
[gpm_graph_draw_labels] gpm-graph-widget.c:439 (13:30:25):       LABEL: 15714W
[gpm_graph_draw_labels] gpm-graph-widget.c:439 (13:30:25):       LABEL: 13095W
[gpm_graph_draw_labels] gpm-graph-widget.c:439 (13:30:25):       LABEL: 10476W
[gpm_graph_draw_labels] gpm-graph-widget.c:439 (13:30:25):       LABEL: 7857W
[gpm_graph_draw_labels] gpm-graph-widget.c:439 (13:30:25):       LABEL: 5238W
[gpm_graph_draw_labels] gpm-graph-widget.c:439 (13:30:25):       LABEL: 2619W
[gpm_graph_draw_labels] gpm-graph-widget.c:439 (13:30:25):       LABEL: 0W

Odd. Those are some big numbers. g-p-m reads battery.reporting.rate and uses the fact that it's normalised to mWh. Is this a multibattery machine? Can you post a full g-p-m --verbose --no-daemon log pls.

Thanks.

Sorry, I meant g-p-m reads battery.charge_level.rate as this is the normalised value. HAL is feeding us invalid info. Can you provide complete lshal pls.

Thanks.

Created attachment 64677 [details]
lshal output

So, I suppose there are two problems.

1. bogus values
2. not allocating enough space for the values in the widget

Even though these are admittedly bogus we should probably make sure they can fit even if only for more accurate bug reports.

Created attachment 64680 [details] [review]
temp fix for spacing issue

I think the correct fix would be to get the max extent of the y axis labels and adjust ->box_x for that but that seems a little tricky.  This is a simple workaround just by making the box_x a bit large but still hardcoded.

This also formats the labels as kW when they are above 900W.  Sure may never be needed but then again it was for me.

No, please don't apply this. The proper fix is to compute the proper width of the labels, which I can do easily as i've done this in other places.

We should really work on the hal fix:

hald/linux/acpi.c:

...
if (reporting_unit && strcmp (reporting_unit, "mAh") == 0) {
	voltage_design = hal_device_property_get_int (d, "battery.voltage.design");
	
	/* If design voltage is unknown, use 1mV. */
	if (voltage_design <= 0)
		voltage_design = 1;

	/* scale by factor battery.voltage.design */
	hal_device_property_set_int (d, "battery.charge_level.design",
		reporting_design * voltage_design);
	hal_device_property_set_int (d, "battery.charge_level.warning",
		reporting_warning * voltage_design);
	hal_device_property_set_int (d, "battery.charge_level.low",
		reporting_low * voltage_design);
	hal_device_property_set_int (d, "battery.charge_level.granularity_1",
		reporting_gran1 * voltage_design);
	hal_device_property_set_int (d, "battery.charge_level.granularity_2",
		reporting_gran2 * voltage_design);

	/* set unit */
	hal_device_property_set_string (d, "battery.charge_level.unit",
		"mWh"); /* not mAh! */
	}

this is wrong IMO.

You have battery.voltage.design in mV (11100)
You have battery.reporting.rate in mAh (2187)

We are currently multiplying to give:

mWh = mAh * mV

when we should be doing:

mWh = mAh * ( mV / 1000)

Does that make sense? Could you try patching HAL and seeing if that works for you please.

Richard.

The values that HAL reports are in no particular unit.  It's wrong to assume that they might be.

So we should remove the property in hal that tells us that it's mWh..

Created attachment 66121 [details] [review]
patch that's been reported to work

You might want to try the attached patch as it's been reported as working fine.

Closing as this will remain broken until HAL is patched.

My patch has been applied to HAL. The soon-to-be-released version 0.5.8 will contain this fix and should fix the issues with values being too large.