Results 1 to 13 of 13
  1.    #1  
    If any of you are like me, you'd rather spend 2 minutes editing simple code to assist in saving your stock Pre battery than 80 bucks on a bigger, third party option. Thanks to Zinge's Brightness Unlinked (and a small convenience tweak of my own) you can more easily fine tune your screen and keypad brightnesses to promote reduced charge consumption.

    Please be aware, I haven't secured Zinge's permission to patch his app as of yet so you're going to have to manually edit the following using novacom/vi or whatever terminal/editor combination you prefer:

    (you may have to "mount -o remount,rw /" your filesystem)
    in you favorite editor.

    Change the following four entries to reflect your personal preferences:
    line 40:
    maxValue: 100;
    change 100 to the highest brightness you want your screen to be (i use 30)
    line 41:
    minValue: 0;
    change 0 to the lowest brightness you want (i use the default 0)
    line 48:
    maxValue: 100;
    change 100 to highest brightness value you want you keypad to reach (i use 20)
    line 49:
    minValue: 0;
    change 0 to the lowest brightness you want (i use 3 because the keypad turns off at 3, not zero for some reason)

    The screen can always be adjusted full spectrum by using the stock screen & lock app. Keypad remains relegated to brightness unlinked.

    This code adjustment effectively changes the scale of the brightness unlinked sliders to reflect your preferential range. This can help save battery in two ways. First, if you set your celing low (say, 50, for example) you limit the possibility of unnecessarily setting your screen brightness too high. As many will confirm, the screen eats up the battery faster than any overclock kernel will. The second way is simply a matter of precision. When you try to hit a target 1/100th of 2 inches wide, it's hard to be precise, especially with thick fingers! Setting your brightness range to 0 - 20 makes that target a whole lot bigger and therefore, easier to hit!

    Try it out, you'll see, at least until Zinge codes profiles or ambient light sensor support that makes this dirty adjustment irrelevant.

    Note: Of further interest are the update frequencies and the default values contained in the same file. Setting your default values to split your ranges down the middle may avoid a potential incongruency. I have not (defaults = 50 and both screen and keypad are less than this value) and BU hasn't crashed on me. updateInterval can smoothe the responsiveness of the slider motion.
    Last edited by jnever1; 07/30/2010 at 02:57 PM. Reason: Changed Title to better suit content, adjusted language to more directly reflect intent
  2. #2  
    Between Mode Switcher's ability to set brightness based on the mode you're using, and the patch that inverts the keyboard brightness based on the screen brightness (i.e. if screen is very dark the keyboard is bright and vice versa), I find there to be no use for brightness unlinked anymore.

    Why keep an app running in the background if you don't have to?
  3. #3  
    I like the patch that inverts brightness...
  4.    #4  
    I see that you have a link to the MS manual in your sig...

    Yes, mode switcher CAN be used to set a low consumption mode... when coupled with reduced minimum brightness patch, as with BU. However, I might liken doing so to using a swiss army knife to open a tin of sardines when twisting the key would do just as well. And the inverted lights patch? Kinda like buying an all electric car. Sure, your petroleum bill goes down, but the electric goes up...

    I get what you're saying, though. BU isn't for everyone. I, myself, wish Zinge had attempted to ballance the left, center, and right keypad LEDs rather than stick with the default brighter center. However, memory isn't an issue for me. Neither is needing any other "modes" than 'battery conservative.' Using the f102a psycho kernel on uberkernel default settings (userspace, 800/600/125), compcache off, and the settings as I've described above, I average -220mA (5 screen/0 keys), -270mA full bright (30 screen, 20 keys) while maintaining an OC'd 600MHz environment. Bonus: I don't have to hold my breath in order to hit exact numbers.

    Furthermore, who says it has to run in the BG? I set it up once. Close BU (including the dashboard BU). Done. When I want something different, I'll launch it/close it again.

    And, forgive me for asking, but how does MS know when all those triggers go off?
    Last edited by jnever1; 07/29/2010 at 10:47 PM.
  5. #5  
    Obviously MS runs in the background.

    But it provides a multitude of uses beyond simply handling brightness, so it's worth it.

    BU is an outdated app that does one very minor thing that really can be handled by a patch. Find me a patch that can do everything that Mode Switcher can do and you'll have an argument.

    I also don't get that electric car analogy at all. I have yet to see a single post denigrating the inverted brightness patch for any reason. In fact I bet even zinge is using it. :-)
  6.    #6  
    1.) MS's "multitude of uses beyond simply handling brightness" does not address battery conservation specifically. Fine-tuning LED and backlight brightness does.

    2.) "it's worth it" is subjective to the point of personal preference in application versatility. This thread is objective to the point of acheiving immediately reduced battery charge dissipation through the employ of simple code manipulation.

    3.) A "patch" is a one time event, period. You cannot adjust a "patch" on the fly, willy-nilly. Without going into great detail it would take at least 100^100 patches to do "everything" that BU can do. My intent here, is to LIMIT BU by reducing the range of possible "patches" it can APPly as an APPlication to those that are most conducive to charge conservation. The fact that it can be fine-tuned otherwise is simply a bonus that I would expect someone familiar with MS to be able to appreciate.

    4.) How is reiterating the concept of 'Inverse' "denigrating"? I said it does what it does, which is not what I've done.

    5.) "Outdated"? the last update was Mar 27th, 2010... 4 months ago.

    As far as the analogy goes, apparently I didn't flesh it out enough for some:
    If your car runs on rechargable batteries you will be paying for the electricity to charge it rather than for gasoline (most likely at a lessor rate, appropriately - as the keypad LEDs likely consume less power/unit-time than the screen backlight), unless you plug in at someone else's recepticle, which will probably be viewed as theft if the e-car becomes more prevalent. Likewise, the inverse brightness patch increases key pad brightness when the screen darkens. One light dims while another brightens. The cost of gas goes down but electricity goes up. Inverse relationships at their finest.

    Regardles,. I'm not badmouthing either the patch or MS. Both have their place in the webOS ecosystem. All I'm saying is that BU can be easily tweaked to provide improved charge conservation. Don't use BU? Good for you! But, then I suppose a thread on how to tweak BU to imporve battery conservation doesn't apply to you, does it?

    But, please, MS already has a thread. I've seen it. It's quite popular and has no need to be advertized here.
    Last edited by jnever1; 07/30/2010 at 12:12 AM. Reason: I went 'psycho' ;-)
  7. #7  
    The reason your analogy doesn't apply is because you apparently don't know that the inverted brightness patch is capped. The keyboard never goes to 0% or 100%, because frankly neither setting is any more useful than those in-between.

    Regardless, the only reason I posted in this thread was to suggest an alternative, easier, and automated way to achieve your goals. Mode Switcher was only suggested in direct response to your supposition that "some people" have troubles with accidentally setting screen brightness too high. The inverted patch is really all that's needed to ensure being able to see the keyboard regardless of the brightness of the screen.

    Please don't think I'm trying to convince you to do something else with your time or energy. My idea of WebOS centers around automation and convenience. If I had known you aren't a fan of such things, I never would have suggested alternative solutions to your interesting methods of saving precious battery power. :-)

    Anyways, I used to use Brightness Unlinked when it was the only method of seeing the keyboard with the brightness set low. When better solutions came along, I moved on. But I always hold out hope that a developer will update or improve an app with features that make it relevant, or that a user will come up with a patch to restore usefulness to an app that has lost most of it. Hence my reading this thread in the first place. :-)
  8.    #8  
    The first line in the Inverted Brightness patch thread: xanthinealkaloid ~
    Sets the keyboard brightness to the inverse value of the display brightness with a 15% minimum value & and 85% maximum value.
    I'm well aware that the patch is narrower in range than 0 -100. But, as anyone familiar with British Petroleum knows, just because it's capped doesn't mean it's not still leaking. I find it a flaw, sadly, that there is NO capability to have the keyad LEDs OFF, in direct sunlight with the keypad open, for example, with this patch. I see this as unnecessarily wasteful. Others may find these conditions ideal for their purposes.

    According to the author, 15% is the minimum for keypad brightness.

    15% /= 3%. 3% = keys lights OFF (with the keypad open)

    Maybe MS has that built into it -- to set the keypad brightness to zero under certain conditions? If so, why use the invBri patch at all?

    Once I(and if… because, frankly, I might not) secure Zinge's permission to patch his BU app it will be plenty easy to apply this and variations thereof to it. Effectively I will be appending a sort of versatility to BU that it is now lacking. According to your argument for MS over BU, this leaves MS with the alternative 'upper hand' per se on the automation front.

    On a personal note with respect to MS as an application, I see a lot of potential for MS an alternative OS to webOS, but not as a webOS app. MS is simply too glutted with control features to sit on top of Palm's less than perfect (but perfectly capable of being extended) set. For example, I've read in the MS thread of trying to use a mode switcher event to facilitate a reminder... IMO this seems like a lot of extra hoops to jump through when the alarm feature of the basic webOS clock does that kind of automation easily already. Other uses of MS seem awesome to me: A work mode based on GPS? Sweet! But it’s still not a battery saving function.

    Perhaps the control conflict between MS and webOS is a source for many of the issues users have been having with getting MS to work properly? It's hard to do everything well and I’m not faulting MS for trying. Doing one thing well is a lot easier, thus the reason for posting this thread in the first place.

    Anyway. IMO an app is as useful as you make it. I’m attempting to make BU more useful. Clearly, you and hundreds of others find MS more suited to your purposes, which, as you’ve stated, are automation and versatility. We share the goal of versatility. Unfortunately, the concepts of automation and charge conservation do not well coexist, the latter being a subset of the former. Since this is a thread regarding the charge conservation and NOT automation, I will thank you for keeping your comments thread relevant.

    On that note, if you can describe HOW MS can do exactly what I’m doing with BU, by all means, SPEAK UP! Maybe I should be focusing on MS rather than BU??? But if all you have to offer is MS is better because BU is older and narrowly focused, I'll thank you finally now and ask that you please do as you have in the past and “move on.” This is not the thread for that discussion and I don't see how the continued interjections are helping either cause.
    Last edited by jnever1; 07/30/2010 at 08:47 AM.
  9. #9  
    I think you're confused, bud.

    I suggested MS as a way to control the specific brightness your phone is at at any given moment based on your suggestion that some people can accidentally set their brightness too high and forget about it. i.e. my "Home" mode in MS sets the brightness to 4%.

    MS was never suggested as a sole replacement for the functionality of BU. It never could, because there is no setting for keyboard brightness in it (although I bet if a request of the developer was made, he would add it). I believe I started my first post in this thread with "Between MS and the inverted patch", because I was referring to two parts of your post: ways to keep the brightness from being set too high accidentally, and ways to keep the keyboard visible.

    Anyways, you seem to be getting a little more worked up over this than I expected, so I'll leave you with a quick tidbit about MS: countless people use it for battery conservation, by disabling certain functions of the phone at certain times when they're not needed, and by creating Low Battery modes with the Battery % Trigger. Maybe this info will help you on your journey towards ultimate versatility. :-)
  10.    #10  
    Confused? No. But perhaps the term "accidentally" was the wrong one for me to use. Perhaps "undesirably" or "unnecessarily" would have avoided the brain-dead implications that automation would assuage.

    I'll make an effort to be more aware of how the language I employ can subvert my message. If you care to look, I've edited my original post to reflect these efforts.

    Thank you for your input.
    Last edited by jnever1; 09/10/2010 at 04:56 PM.
  11. #11  
    where is this patch to "inverse brigthness", or whats the the exact name?
  12.    #13  
    Got the OK from Zinge to create a patch. It will take me a bit to get the preware reversible process completely understood (as this will be my first patch) but it will happen. :-)

Tags for this Thread

Posting Permissions