Maemo Wiki Mirror - User contributions [en]

Mer/Status/Battery

2009-06-30T02:04:14Z

130.194.69.10: typographical: use header markup

==Battery monitor via bme==
n8x0 support is in devel as of 0.14.
<pre>
apt-get install advanced-power
</pre>
To start the advanced-power applet:
<pre>
Mer->Settings->Settings
Panels
Status Bar
Advanced Power
Ok and reboot
</pre>

==Request for help==
smartq''x'' is still under development, anyone with a smartq''x'' and some python knowledge is encouraged to install hald-bme-smartq according to the instructions below and help debug the advanced-power applet, please contact toggles at the google mail domain for help or if you can provide any assitance.

==Battery monitor on smartq (currently broken)==
Thanks to zenvoid and qwerty12 for all the help 
As of 0.14 you need to upgrade to Devel and then as root (sudo was broken on the tablet I was borrowing time on):
<pre>
cd
wget http://tommywatson.com/Mer/hald-addon-smartq_0.02_armel.deb
dpkg -i hald-addon-smartq_0.02_armel.deb
apt-get install advanced-power
wget http://tommywatson.com/Mer/AdvancedPowerMonitor.tgz
cd /
tar -zxf /root/AdvancedPowerMonitor.tgz
</pre>

To start the advanced-power applet:
<pre>
Mer->Settings->Settings
Panels
Status Bar
Advanced Power
Ok and reboot
</pre>

Mer/Status/Battery

2009-06-30T01:59:25Z

130.194.69.10: typo

'''Battery monitor via bme''' 
n8x0 support is in devel as of 0.14 
<pre>
apt-get install advanced-power
</pre>
To start the advanced-power applet 
<pre>
Mer->Settings->Settings
Panels
Status Bar
Advanced Power
Ok and reboot
</pre>

 
'''Request for help''' 
smartq''x'' is still under development, anyone with a smartq''x'' and some python knowledge is encouraged to install hald-bme-smartq according to the instructions below and help debug the advanced-power applet, please contact toggles at the google mail domain for help or if you can provide any assitance.
 
'''Battery monitor on smartq''' (currently broken) 
Thanks to zenvoid and qwerty12 for all the help 
As of 0.14 you need to upgrade to Devel and then as root (sudo was broken on the tablet I was borrowing time on) 
<pre>
cd
wget http://tommywatson.com/Mer/hald-addon-smartq_0.02_armel.deb
dpkg -i hald-addon-smartq_0.02_armel.deb
apt-get install advanced-power
wget http://tommywatson.com/Mer/AdvancedPowerMonitor.tgz
cd /
tar -zxf /root/AdvancedPowerMonitor.tgz
</pre>

To start the advanced-power applet: 
<pre>
Mer->Settings->Settings
Panels
Status Bar
Advanced Power
Ok and reboot
</pre>

Mer/Documentation/BME Protocol

2009-06-12T07:19:27Z

130.194.69.10: /* Other information about battery life */ Link to and include Matan's information about the meaning of retu adc register 3

This documentation is entirely for the purpose of implementing software gathering battery information on Nokia Internet Tablets, not alteration of battery management state.

Existing code:
* Dummy server: https://garage.maemo.org/plugins/scmsvn/viewcvs.php/dsme/trunk/adhoc/dummy_bme.c?revision=155&root=dsm&view=markup , released as LGPL 2.1. (Bug: The server shouldn't send a status word before sending the response struct.)
* Simple command-line client written based on this web page: http://bowman.infotech.monash.edu.au/~pmoulder/bme-client.c . (GPLv2+, assuming that the text on this web page is compatible with that license.)

General protocol:

* UNIX socket connection to /tmp/.bmesrv
* Client: send('BMentity')
* Server: send('\n')

After handshake:

<pre>
typedef struct {
uint16 type, subtype;
} BMEHeader;
</pre>

types so far (NAME, (type, subtype)):

== EM_BATTERY_INFO_REQ (0x06, 0x00) ==

<pre>
typedef struct {
BMEHeader header;
u_int32_t flags; // Set to 0xFFFFFFFF to get all data
} BME_EM_BATTERY_INFO_Req;

struct emsg_battery_info_reply {
uint32 a;
uint32 flags;
uint16 c;
uint16 d;
uint16 temp; // Battery temperature measured in Kelvin
uint16 f;
uint16 g;
uint16 h;
uint16 i;
uint16 j;
uint16 k;
uint16 l;
};
</pre>

== Some BULK0 message (0x42, 0x00) ==

<pre>
typedef struct {
BMEHeader header;
u_int32_t flags; // Set to 0xFFFFFFFF to get all data
} BME_EM_BULK_Req;

struct emsg_bme_bulk_reply {
uint32 unknown1;
uint32 unknown2;
uint32 unknown3;
uint16 sw_status; // Battery monitor SW status
uint16 instaneous_battery_voltage; // Instantaneous battery voltage (mV)
uint16 // Remaining standby time to battery low (mins)
uint16 unknown4;
uint16 unknown5;
uint16 unknown6;
uint16 // Battery monitor check voltage (mV)
uint16 // Battery low warning interval counter
uint16 // Double median filtered battery voltage
uint16 // Initial battery monitor voltage (mV)
uint16 // Time per battery bar (mins)
uint16 // DMF voltage sampled at first battery low (mV)
uint32 // Average phone current (uA)
uint16 // Most recent battery charge condition (mAh)
uint16 // Lowest TX-Off voltage (mV)
uint16 // Lowest TX-On voltage (mV)
uint16 // Largest TX-Off/On voltage difference (mV)
uint8 // Battery bar level log mask
uint8 // Previous battery bar level
uint8 // Battery low reason
uint8 // CS state information
uint16 // Number of battery bars
uint16 // Battery type
uint16 // Temperature, in kelvin
uint16 // Battery capacity
uint16 // Battery impedance (mOhm)
uint16 // Present value of v_bat_full_level
uint16 // Present value of v_bat_low_ths_mv
uint16 unknown7;
uint16 unknown8;
uint16 unknown9;
uint16 // Load current estimated by Batmon4 (uA)
uint16 unknown10;
};
</pre>

The “Instantaneous battery voltage (mV)” field’s observed values have a certain regular spacing indicating a linear function of some integer value with a smaller range, presumably retu adc register #8. If it is indeed from that register, then note there is a non-zero offset involved: from memory, one function that gives values consistent with the set of values observed and that somewhat matches observations of both fields (unfortunately with non-negligible delay between sampling the two so far) is mV = 2252.361 + 2.81361 * adc#8 (where the multiplier is fairly accurate if I've correctly remembered it, but the constant could be out by some multiple of 2.81361). -- pjrm.

The “Battery monitor check voltage (mV)” field has similar values to the “Instantaneous battery voltage (mV)” field, but without obvious regular spacing. I don't know how it's calculated. -- pjrm.

== Some BULK1 message (0x43, 0x00) ==

<pre>
typedef struct {
BMEHeader header;
u_int32_t flags; // Set to 0xFFFFFFFF to get all data
} BME_EM_BULK1_Req;

struct emsg_bme_bulk1_reply {
uint32 unknown1;
uint32 unknown2;
uint32 unknown3;
uint16 // Elapsed model time (min)
uint16 // Tx-Off battery voltage (mV)
uint16 // Tx-On battery voltage (mV)
uint8 // Battery power state
uint8 // Batmon4 internal flags2
uint8 // Batmon4 internal flags3
uint8 // Charging method
uint16 // Present Phi value (mV)
uint16 // Present Delta Phi value (mV)
uint8 // Charging mode
uint8 // Previous charging mode
uint8 // Charger type
uint8 // Previous charger type
uint16 // Instantaneous battery voltage (mV)
uint8 // Number of charger checks (0-9) ?
uint8 // Charger recognition state
uint16 unknown4;
uint16 // Instantaneous charger current (mA)
uint16 unknown5;
uint16 // Charging time (min)
uint16 // Average Vchar (mV)
uint16 // Equivalent DC charger current (mA)
uint8 // Battery full flag (0 or 1)
uint8 // HW Cha PWM value L ??
uint8 // Cha PWM value L ??
uint8 unknown6;
uint16 // Open switch battery voltage (mV)
uint16 // Closed switch battery voltage (mV)
uint16 unknown7;
};
</pre>

== Some BULK2 message (0x44, 0x00) ==

<pre>
typedef struct {
BMEHeader header;
u_int32_t flags; // Set to 0xFFFFFFFF to get all data
} BME_EM_BULK2_Req;

struct emsg_bme_bulk2_reply {
uint32 unknown1;
uint32 unknown2;
uint32 unknown3;
uint16 // Conf. battery footprint
uint16 // Conf. minimum standby current (mA)
uint16 // Conf. Batmon battery low voltage (Safety level)
uint16 // Conf. Batmon battery low voltage (Empty)
uint16 // Configured number of battery bars
uint16 unknown4;
};
</pre>

= Other information about battery life =

Some battery-related information is also available from retu adc registers (which in turn are available via ioctl's on /dev/rutu: see retu-adc source).

It's said that register 3 shows whether charging is occurring: with value 0 meaning "not being charged", while "values 0xff and above" are an indication of the voltage being applied for charging. Matan adds (http://talk.maemo.org/showpost.php?p=259465&postcount=43) that values around 0x100 indicate charging, while values around 0x170 indicate that the power source is connected but we aren't charging.

Register 8 apparently indicates battery voltage. See the note above about “instantaneous battery voltage (mV)” for how it might correspond to one measure of voltage.

Note that this value can fluctuate a lot when the device is in use, but when idle it gets a good fit to the curve adc#8 = 438.3 + exp(p0 + p1*t) - exp(n0 + n1*t) where t is time (or more generally charge used or remaining), and p0,p1,n0,n1 are constants. (I forget the values I found for them, but in any case it would be good to fit for them again once more data is on hand.)

To invert this function to find idle time remaining (on assumption that the device was idle when the register was read), first see whether the adc#8 value is above or below 438.3, which tells you which exponential is dominant, and approximate the other exponential with a constant 3 (or a straight line if you like); can iterate and update this approximation for the neighbourhood of the solution found by the previous iteration. -- pjrm

Mer/Documentation/BME Protocol

2009-06-12T04:56:58Z

130.194.69.10: /* Other information about battery life */ Cross-reference bme information with retu adc description.

This documentation is entirely for the purpose of implementing software gathering battery information on Nokia Internet Tablets, not alteration of battery management state.

Existing code:
* Dummy server: https://garage.maemo.org/plugins/scmsvn/viewcvs.php/dsme/trunk/adhoc/dummy_bme.c?revision=155&root=dsm&view=markup , released as LGPL 2.1. (Bug: The server shouldn't send a status word before sending the response struct.)
* Simple command-line client written based on this web page: http://bowman.infotech.monash.edu.au/~pmoulder/bme-client.c . (GPLv2+, assuming that the text on this web page is compatible with that license.)

General protocol:

* UNIX socket connection to /tmp/.bmesrv
* Client: send('BMentity')
* Server: send('\n')

After handshake:

<pre>
typedef struct {
uint16 type, subtype;
} BMEHeader;
</pre>

types so far (NAME, (type, subtype)):

== EM_BATTERY_INFO_REQ (0x06, 0x00) ==

<pre>
typedef struct {
BMEHeader header;
u_int32_t flags; // Set to 0xFFFFFFFF to get all data
} BME_EM_BATTERY_INFO_Req;

struct emsg_battery_info_reply {
uint32 a;
uint32 flags;
uint16 c;
uint16 d;
uint16 temp; // Battery temperature measured in Kelvin
uint16 f;
uint16 g;
uint16 h;
uint16 i;
uint16 j;
uint16 k;
uint16 l;
};
</pre>

== Some BULK0 message (0x42, 0x00) ==

<pre>
typedef struct {
BMEHeader header;
u_int32_t flags; // Set to 0xFFFFFFFF to get all data
} BME_EM_BULK_Req;

struct emsg_bme_bulk_reply {
uint32 unknown1;
uint32 unknown2;
uint32 unknown3;
uint16 sw_status; // Battery monitor SW status
uint16 instaneous_battery_voltage; // Instantaneous battery voltage (mV)
uint16 // Remaining standby time to battery low (mins)
uint16 unknown4;
uint16 unknown5;
uint16 unknown6;
uint16 // Battery monitor check voltage (mV)
uint16 // Battery low warning interval counter
uint16 // Double median filtered battery voltage
uint16 // Initial battery monitor voltage (mV)
uint16 // Time per battery bar (mins)
uint16 // DMF voltage sampled at first battery low (mV)
uint32 // Average phone current (uA)
uint16 // Most recent battery charge condition (mAh)
uint16 // Lowest TX-Off voltage (mV)
uint16 // Lowest TX-On voltage (mV)
uint16 // Largest TX-Off/On voltage difference (mV)
uint8 // Battery bar level log mask
uint8 // Previous battery bar level
uint8 // Battery low reason
uint8 // CS state information
uint16 // Number of battery bars
uint16 // Battery type
uint16 // Temperature, in kelvin
uint16 // Battery capacity
uint16 // Battery impedance (mOhm)
uint16 // Present value of v_bat_full_level
uint16 // Present value of v_bat_low_ths_mv
uint16 unknown7;
uint16 unknown8;
uint16 unknown9;
uint16 // Load current estimated by Batmon4 (uA)
uint16 unknown10;
};
</pre>

The “Instantaneous battery voltage (mV)” field’s observed values have a certain regular spacing indicating a linear function of some integer value with a smaller range, presumably retu adc register #8. If it is indeed from that register, then note there is a non-zero offset involved: from memory, one function that gives values consistent with the set of values observed and that somewhat matches observations of both fields (unfortunately with non-negligible delay between sampling the two so far) is mV = 2252.361 + 2.81361 * adc#8 (where the multiplier is fairly accurate if I've correctly remembered it, but the constant could be out by some multiple of 2.81361). -- pjrm.

The “Battery monitor check voltage (mV)” field has similar values to the “Instantaneous battery voltage (mV)” field, but without obvious regular spacing. I don't know how it's calculated. -- pjrm.

== Some BULK1 message (0x43, 0x00) ==

<pre>
typedef struct {
BMEHeader header;
u_int32_t flags; // Set to 0xFFFFFFFF to get all data
} BME_EM_BULK1_Req;

struct emsg_bme_bulk1_reply {
uint32 unknown1;
uint32 unknown2;
uint32 unknown3;
uint16 // Elapsed model time (min)
uint16 // Tx-Off battery voltage (mV)
uint16 // Tx-On battery voltage (mV)
uint8 // Battery power state
uint8 // Batmon4 internal flags2
uint8 // Batmon4 internal flags3
uint8 // Charging method
uint16 // Present Phi value (mV)
uint16 // Present Delta Phi value (mV)
uint8 // Charging mode
uint8 // Previous charging mode
uint8 // Charger type
uint8 // Previous charger type
uint16 // Instantaneous battery voltage (mV)
uint8 // Number of charger checks (0-9) ?
uint8 // Charger recognition state
uint16 unknown4;
uint16 // Instantaneous charger current (mA)
uint16 unknown5;
uint16 // Charging time (min)
uint16 // Average Vchar (mV)
uint16 // Equivalent DC charger current (mA)
uint8 // Battery full flag (0 or 1)
uint8 // HW Cha PWM value L ??
uint8 // Cha PWM value L ??
uint8 unknown6;
uint16 // Open switch battery voltage (mV)
uint16 // Closed switch battery voltage (mV)
uint16 unknown7;
};
</pre>

== Some BULK2 message (0x44, 0x00) ==

<pre>
typedef struct {
BMEHeader header;
u_int32_t flags; // Set to 0xFFFFFFFF to get all data
} BME_EM_BULK2_Req;

struct emsg_bme_bulk2_reply {
uint32 unknown1;
uint32 unknown2;
uint32 unknown3;
uint16 // Conf. battery footprint
uint16 // Conf. minimum standby current (mA)
uint16 // Conf. Batmon battery low voltage (Safety level)
uint16 // Conf. Batmon battery low voltage (Empty)
uint16 // Configured number of battery bars
uint16 unknown4;
};
</pre>

= Other information about battery life =

Some battery-related information is also available from retu adc registers (which in turn are available via ioctl's on /dev/rutu: see retu-adc source).

It's said that register 3 shows whether charging is occurring: with value 0 meaning "not being charged", while "values 0xff and above" are an indication of the voltage being applied for charging.

Register 8 apparently indicates battery voltage. See the note above about “instantaneous battery voltage (mV)” for how it might correspond to one measure of voltage.

Note that this value can fluctuate a lot when the device is in use, but when idle it gets a good fit to the curve adc#8 = 438.3 + exp(p0 + p1*t) - exp(n0 + n1*t) where t is time (or more generally charge used or remaining), and p0,p1,n0,n1 are constants. (I forget the values I found for them, but in any case it would be good to fit for them again once more data is on hand.)

To invert this function to find idle time remaining (on assumption that the device was idle when the register was read), first see whether the adc#8 value is above or below 438.3, which tells you which exponential is dominant, and approximate the other exponential with a constant 3 (or a straight line if you like); can iterate and update this approximation for the neighbourhood of the solution found by the previous iteration. -- pjrm

Mer/Documentation/BME Protocol

2009-06-12T04:51:37Z

130.194.69.10: /* Some BULK0 message (0x42, 0x00) */ Add information on "instantaneous battery voltage" field.

This documentation is entirely for the purpose of implementing software gathering battery information on Nokia Internet Tablets, not alteration of battery management state.

Existing code:
* Dummy server: https://garage.maemo.org/plugins/scmsvn/viewcvs.php/dsme/trunk/adhoc/dummy_bme.c?revision=155&root=dsm&view=markup , released as LGPL 2.1. (Bug: The server shouldn't send a status word before sending the response struct.)
* Simple command-line client written based on this web page: http://bowman.infotech.monash.edu.au/~pmoulder/bme-client.c . (GPLv2+, assuming that the text on this web page is compatible with that license.)

General protocol:

* UNIX socket connection to /tmp/.bmesrv
* Client: send('BMentity')
* Server: send('\n')

After handshake:

<pre>
typedef struct {
uint16 type, subtype;
} BMEHeader;
</pre>

types so far (NAME, (type, subtype)):

== EM_BATTERY_INFO_REQ (0x06, 0x00) ==

<pre>
typedef struct {
BMEHeader header;
u_int32_t flags; // Set to 0xFFFFFFFF to get all data
} BME_EM_BATTERY_INFO_Req;

struct emsg_battery_info_reply {
uint32 a;
uint32 flags;
uint16 c;
uint16 d;
uint16 temp; // Battery temperature measured in Kelvin
uint16 f;
uint16 g;
uint16 h;
uint16 i;
uint16 j;
uint16 k;
uint16 l;
};
</pre>

== Some BULK0 message (0x42, 0x00) ==

<pre>
typedef struct {
BMEHeader header;
u_int32_t flags; // Set to 0xFFFFFFFF to get all data
} BME_EM_BULK_Req;

struct emsg_bme_bulk_reply {
uint32 unknown1;
uint32 unknown2;
uint32 unknown3;
uint16 sw_status; // Battery monitor SW status
uint16 instaneous_battery_voltage; // Instantaneous battery voltage (mV)
uint16 // Remaining standby time to battery low (mins)
uint16 unknown4;
uint16 unknown5;
uint16 unknown6;
uint16 // Battery monitor check voltage (mV)
uint16 // Battery low warning interval counter
uint16 // Double median filtered battery voltage
uint16 // Initial battery monitor voltage (mV)
uint16 // Time per battery bar (mins)
uint16 // DMF voltage sampled at first battery low (mV)
uint32 // Average phone current (uA)
uint16 // Most recent battery charge condition (mAh)
uint16 // Lowest TX-Off voltage (mV)
uint16 // Lowest TX-On voltage (mV)
uint16 // Largest TX-Off/On voltage difference (mV)
uint8 // Battery bar level log mask
uint8 // Previous battery bar level
uint8 // Battery low reason
uint8 // CS state information
uint16 // Number of battery bars
uint16 // Battery type
uint16 // Temperature, in kelvin
uint16 // Battery capacity
uint16 // Battery impedance (mOhm)
uint16 // Present value of v_bat_full_level
uint16 // Present value of v_bat_low_ths_mv
uint16 unknown7;
uint16 unknown8;
uint16 unknown9;
uint16 // Load current estimated by Batmon4 (uA)
uint16 unknown10;
};
</pre>

The “Instantaneous battery voltage (mV)” field’s observed values have a certain regular spacing indicating a linear function of some integer value with a smaller range, presumably retu adc register #8. If it is indeed from that register, then note there is a non-zero offset involved: from memory, one function that gives values consistent with the set of values observed and that somewhat matches observations of both fields (unfortunately with non-negligible delay between sampling the two so far) is mV = 2252.361 + 2.81361 * adc#8 (where the multiplier is fairly accurate if I've correctly remembered it, but the constant could be out by some multiple of 2.81361). -- pjrm.

The “Battery monitor check voltage (mV)” field has similar values to the “Instantaneous battery voltage (mV)” field, but without obvious regular spacing. I don't know how it's calculated. -- pjrm.

== Some BULK1 message (0x43, 0x00) ==

<pre>
typedef struct {
BMEHeader header;
u_int32_t flags; // Set to 0xFFFFFFFF to get all data
} BME_EM_BULK1_Req;

struct emsg_bme_bulk1_reply {
uint32 unknown1;
uint32 unknown2;
uint32 unknown3;
uint16 // Elapsed model time (min)
uint16 // Tx-Off battery voltage (mV)
uint16 // Tx-On battery voltage (mV)
uint8 // Battery power state
uint8 // Batmon4 internal flags2
uint8 // Batmon4 internal flags3
uint8 // Charging method
uint16 // Present Phi value (mV)
uint16 // Present Delta Phi value (mV)
uint8 // Charging mode
uint8 // Previous charging mode
uint8 // Charger type
uint8 // Previous charger type
uint16 // Instantaneous battery voltage (mV)
uint8 // Number of charger checks (0-9) ?
uint8 // Charger recognition state
uint16 unknown4;
uint16 // Instantaneous charger current (mA)
uint16 unknown5;
uint16 // Charging time (min)
uint16 // Average Vchar (mV)
uint16 // Equivalent DC charger current (mA)
uint8 // Battery full flag (0 or 1)
uint8 // HW Cha PWM value L ??
uint8 // Cha PWM value L ??
uint8 unknown6;
uint16 // Open switch battery voltage (mV)
uint16 // Closed switch battery voltage (mV)
uint16 unknown7;
};
</pre>

== Some BULK2 message (0x44, 0x00) ==

<pre>
typedef struct {
BMEHeader header;
u_int32_t flags; // Set to 0xFFFFFFFF to get all data
} BME_EM_BULK2_Req;

struct emsg_bme_bulk2_reply {
uint32 unknown1;
uint32 unknown2;
uint32 unknown3;
uint16 // Conf. battery footprint
uint16 // Conf. minimum standby current (mA)
uint16 // Conf. Batmon battery low voltage (Safety level)
uint16 // Conf. Batmon battery low voltage (Empty)
uint16 // Configured number of battery bars
uint16 unknown4;
};
</pre>

= Other information about battery life =

Some battery-related information is also available from retu adc registers (which in turn are available via ioctl's on /dev/rutu: see retu-adc source).

It's said that register 3 shows whether charging is occurring: with value 0 meaning "not being charged", while "values 0xff and above" are an indication of the voltage being applied for charging.

Register 8 apparently indicates battery voltage. Note that this value can fluctuate a lot when the device is in use, but when idle it gets a good fit to the curve adc#8 = 438.3 + exp(p0 + p1*t) - exp(n0 + n1*t) where t is time, and p0,p1,n0,n1 are constants. (I forget the values I found for them, but in any case it would be good to fit for them again once more data is on hand.)

To invert this function to find idle time remaining (on assumption that the device was idle when the register was read), first see whether the adc#8 value is above or below 438.3, which tells you which exponential is dominant, and approximate the other exponential with a constant 3 (or a straight line if you like); can iterate and update this approximation for the neighbourhood of the solution found by the previous iteration.

Mer/Documentation/BME Protocol

2009-05-18T06:25:29Z

130.194.69.10: Link to a simple client program. Document a bug in the dummy server.

Mer/Releases/0.13testing1

2009-05-13T06:03:46Z

130.194.69.10: /* Bugs in testing1 */ clarify one of the issues i added yesterday (pjrm)

By using these testing images, you're '''morally obligated to test them''' and to edit this page and report -every single bug you find-, no matter if they're theme flaws, quirks, bugs or crashes. You can optionally also use [https://bugs.maemo.org/enter_bug.cgi?product=Mer bugzilla] , use version 0.13.

'''Please send the bug report urls to mer-chatter (see [[Mer/Awareness]] ) as well and share your bugs, testing experiences.'''

Test master is Meizirkki, and can be found in #mer on irc.freenode.net usually and you can ask him if there's some specialized areas that need testing. Take [http://wiki.maemo.org/Mer/Sprints/0.13#Component:_Testing these testing things first].

These images will not be the only ones this week. In N8x0 installer, when it asks for URL=, write URL=http://the.image.intended. Instructions on [[Mer/Releases/0.12]] still apply.

[http://stskeeps.subnetmask.net/mer/0.13-testing1/mer-x86-generic-image-v0.13-testing1.vmdk.zip Mer X86 VMDK]

[http://stskeeps.subnetmask.net/mer/0.13-testing1/mer-x86-generic-image-v0.13-testing1.tar.gz Mer X86 rootfs version]

[http://stskeeps.subnetmask.net/mer/0.13-testing1/mer-armel-n8x0-image-v0.13-testing1.tar.gz Mer N8x0, rootfs version] or http://tinyurl.com/q4vj97

== Bugs in testing1 ==

* Hardware keyboard/slider events on N810 when device is in standby only turns on backlight, and doesn't unblank the screen. Touchscreen events work fine in this respect.
* Touchscreen using xf86-input-tslib does not work (N8x0, SmartQ). Fix will be in testing2 image (redownload image and it should be fixed)
* Brightness applet makes hildon crash (not always) http://pastebin.ca/1418638
* Freezing at shutdown if the command is given from the new gui
* Enhancement: jffs2 images, kernels, etc.
** Potential fix: Edit kernel-diablo in Maemo:Mer:Devel:HW:N8x0:Devel to include a variant (like -oprofile or such) that is built to sed CONFIG_CMDLINE from 'CONFIG_CMDLINE="root=1f03 rootfstype=jffs2 ro console=tty0 console=ttyMTD5" to:'CONFIG_CMDLINE="root=1f04 rootfstype=jffs2 init=/sbin/tablet-init ro console=tty0 console=ttyMTD5"'
* Minor issues:
** [0.12, not verified to be in 0.13testing1] /etc/init.d/powered produces a message similar to ‘[: 105: false: invalid operator’. The fix is to change ‘==’ to ‘=’ in all lines of the form ‘[ "$FOO" == "true" ]’. (Just search for ‘==’ in all init.d scripts.)
** [0.12, not verified to be in 0.13testing1] Near the top of /usr/sbin/set_dim_and_blank.py is ‘if dim > blank: print "Dim must be >= blank"’; the message should say ‘<=’ rather than ‘>=’.

====x86 VMDK====
* Text in text fields can not be drag-selected (cursor jumps to start of field instead)
* Applications installed prompt for folder location but are always stored in Extras
** Artifact of Fremantle Application Manager i think
*** (Irrelevant. It's a bug)
* Organize dialog nonresponsive to any input
* Locale hardcoded to en_GB.utf8 (?)
** There is a .current-locale feature, needs control panel (+ reboot), look in /usr/bin/start-hildon
*** the file is ~/.osso/current-locale and it doesn't work.
* Terminal menu text is not replaced with localized text - e.g. "webameedit - webamecopy" etc.
* Terminal toolbar Ctrl button non-functional (try Ctrl + d, Ctrl + h, Ctrl + g, Ctrl + c)
** Work on including patches in libvte on garage.maemo.org/projects/osso-xterm into vte - there's some not included yet.
* Terminal toolbar (likely other) has significanly misaligned background image when selected.
** Icon sizes are changed in Fremantle, so a theme issue probably
*** no. There are no icons on the toolbar. Screenshot: [http://www.quicksnapper.com/JMarkevich/image/toolbar-bug Toolbar Bug] (this has been a persistent bug in Maemo, though mostly for all python programs, evidently)