Menu

Main Menu
Talk Get Daily Search

Member's Online

    User Name
    Password
    Poll: Can you use this release of Mer, on a daily basis?
    Poll Options
    Can you use this release of Mer, on a daily basis?
    View Poll Results

    Mer 0.12 released

    Reply
    Page 8 of 9 | Prev |   6     7   8   9   | Next
    qole | # 71 | 2009-05-13, 20:07 | Report

    I hope Mer eventually gets the conflicts resolved, because really, Mer should be an installable desktop environment from vanilla Ubuntu. That would be awesome beyond words.

    Edit | Forward | Quote | Quick Reply | Thanks

     
    Stskeeps | # 72 | 2009-05-13, 20:10 | Report

    Originally Posted by qole View Post
    I hope Mer eventually gets the conflicts resolved, because really, Mer should be an installable desktop environment from vanilla Ubuntu. That would be awesome beyond words.
    Yeah, that might just happen. You'd want to see this.

    Edit | Forward | Quote | Quick Reply | Thanks
    The Following 3 Users Say Thank You to Stskeeps For This Useful Post:
    benny1967, qole, timsamoff

     
    qole | # 73 | 2009-05-13, 20:53 | Report

    Originally Posted by Stskeeps View Post
    Yeah, that might just happen. You'd want to see this.
    Yes, exactly like that. I'm glad there are other people thinking like I do.

    Edit | Forward | Quote | Quick Reply | Thanks
    The Following User Says Thank You to qole For This Useful Post:
    timsamoff

     
    412b | # 74 | 2009-05-16, 11:46 | Report

    Not sure if it is to be posted here, but partly it is right.
    I've almost finished python daemon for working with BME server socket, so there will be no need in hald-addon-bme. Thanks for BME Protocol, but unfortunately it has some errors in message structs descriptions and black spots:
    Code:
    struct emsg_battery_info_reply {
        uint32      status; // I guess it's the reply status, 0 means all is OK, -1 means error
        uint32      a;
        uint32      flags;
        uint16      c;
        uint16      // Battery capacity. Have no another battery, so check needed, but seems to be it.
        uint16      temp;   // Battery temperature measured in Kelvin 
        uint16      instaneous_battery_voltage; // Instantaneous battery voltage (mV)
        uint16      // Lowest TX-Off voltage (mV)
        uint16      // Lowest TX-On voltage (mV)
        uint16      // Closed switch battery voltage (mV)
        uint16      // Open switch battery voltage (mV)
        uint16      k;
        uint16      l;
    };
    
    struct emsg_bme_bulk1_reply {
       uint32     status; // I guess it's the reply status, 0 means all is OK, -1 means error
       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;
    };
    Next thing is to think about calculating the battery percentage, 'cause there are enough values to use. And I guess I really should write it in pure C with D-Bus messaging. Any ideas and help appreciated.

    And Advanced Power (and Monitor) are fully ported to Mer now. Next release will be fully working on Maemo and Mer.

    Edit | Forward | Quote | Quick Reply | Thanks
    The Following 4 Users Say Thank You to 412b For This Useful Post:
    meizirkki, qole, Stskeeps, timsamoff

     
    meizirkki | # 75 | 2009-05-16, 16:39 | Report

    Originally Posted by 412b View Post
    Not sure if it is to be posted here, but partly it is right.
    I've almost finished python daemon for working with BME server socket, so there will be no need in hald-addon-bme. Thanks for BME Protocol, but unfortunately it has some errors in message structs descriptions and black spots:
    Code:
    struct emsg_battery_info_reply {
        uint32      status; // I guess it's the reply status, 0 means all is OK, -1 means error
        uint32      a;
        uint32      flags;
        uint16      c;
        uint16      // Battery capacity. Have no another battery, so check needed, but seems to be it.
        uint16      temp;   // Battery temperature measured in Kelvin 
        uint16      instaneous_battery_voltage; // Instantaneous battery voltage (mV)
        uint16      // Lowest TX-Off voltage (mV)
        uint16      // Lowest TX-On voltage (mV)
        uint16      // Closed switch battery voltage (mV)
        uint16      // Open switch battery voltage (mV)
        uint16      k;
        uint16      l;
    };
    
    struct emsg_bme_bulk1_reply {
       uint32     status; // I guess it's the reply status, 0 means all is OK, -1 means error
       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;
    };
    Next thing is to think about calculating the battery percentage, 'cause there are enough values to use. And I guess I really should write it in pure C with D-Bus messaging. Any ideas and help appreciated.

    And Advanced Power (and Monitor) are fully ported to Mer now. Next release will be fully working on Maemo and Mer.
    I'd like to see it working with other battery monitors too, since i use other desktop-environments too ("normal battery monitors [KDE and GNOME ones]" with hald-addon-bme can only show 25%,50%,75% and 100%)

    Edit | Forward | Quote | Quick Reply | Thanks

     
    [[ cold ]] | # 76 | 2009-05-19, 15:22 | Report

    still no word in 0.13?

    Edit | Forward | Quote | Quick Reply | Thanks

     
    jpt000 | # 77 | 2009-05-19, 15:35 | Report

    Originally Posted by [[ cold ]] View Post
    still no word in 0.13?
    Been reloading the 'New Posts' every 10 minutes waiting for it... Should we create a Meraholics thread?

    Edit | Forward | Quote | Quick Reply | Thanks

     
    Stskeeps | # 78 | 2009-05-19, 16:14 | Report

    Sorry, we have 0.13 delayed until Qt finishes building on armel :P We messed up in planning

    Edit | Forward | Quote | Quick Reply | Thanks

     
    fpp | # 79 | 2009-05-19, 19:47 | Report

    Well, just as long as it comes out before the Pandora *and* the N900, much will be forgiven :-)

    Edit | Forward | Quote | Quick Reply | Thanks
    The Following 2 Users Say Thank You to fpp For This Useful Post:
    Jaffa, timsamoff

     
    Thesandlord | # 80 | 2009-05-19, 22:29 | Report

    Qt is finished now right? At least according to the Wiki page (and Stskeeps)!

    I see there is still no sound though. Oh well...

    Edit | Forward | Quote | Quick Reply | Thanks

     
    Page 8 of 9 | Prev |   6     7   8   9   | Next
vBulletin® Version 3.8.8
Normal Logout