yashsingh1/xdaforums huggingface dataset:
[G1 Android Development] shafty023:
On which command did you get a "link failed file exists"?

If the file already exists then you don't need to do the symlink so you can skip whichever command is giving you that error.

Explanation of your error:

Contents of /system/lib/hw

sensors.hero.so

sensors.trout.so

Then you try and do "adb shell ln -s /system/lib/hw/sensors.hero.so /system/lib/hw/sensors.trout.so" . Obviously it's going to tell you link failed file exists b/c the file as you can tell already exists.

Log into your phone "adb shell" and then cd to that directory "cd /system/lib/hw" and then check the contents of that directory "ls -l". If you already see the file then there's no use in trying to create a symlink.

If you're not a linux person, a symlink is kind of like a windows shortcut. The command is

ln -s sourcefile destinationfile

If the file already exists you can't create a shortcut on top of it with the same name.
[G1 Android Development] Breakthecycle2:
Ok, I typed the adb shell....etc. It came back with

-s: not found
[G1 Android Development] shafty023:
So you typed

adb shell ln -s /system/lib/hw/sensors.msm7k.so /system/lib/hw/sensors.trout.so

And it tells you that the switch "-s" is not found? You are remembering to type "ln" <- That is L followed by N all lowercase of course
[G1 Android Development] Breakthecycle2:
ok, no I didn't type the "ln" part. I did that now and i got "link failed file exists" error.
[G1 Android Development] shafty023:
As explained earlier that means the file already exists and you can skip that part
[G1 Android Development] Breakthecycle2:
Right, and enter:

echo "1" > /sys/devices/platform/i2c-adapter/i2c-0/0-0062/blink

chmod 666 /sys/devices/platform/i2c-adapter/i2c-0/0-0062/leds/blue/brightness

chmod 666 /sys/devices/platform/i2c-adapter/i2c-0/0-0062/leds/red/brightness

chmod 666 /sys/devices/platform/i2c-adapter/i2c-0/0-0062/leds/green/brightness

Correct?
[G1 Android Development] shafty023:
That's correct
[G1 Android Development] Breakthecycle2:
That's the problem...lol. It didn't do anything
[G1 Android Development] shafty023:
These do not enable the leds to function like they did in cupcake. we haven't progressed to that point yet. this basically gets them working, but not able to be manipulated by android software. If you want to verify its working do the following

echo "256" > /sys/class/leds/blue/brightness
[G1 Android Development] Breakthecycle2:
I did it and it just repeated it after i hit enter, but there not on. I know that they are real dim, but there is nothing.
[G1 Android Development] chevycowboyusa:
blue light turned on!

Now how do I turn it off? (in terminal) without rebooting??
[G1 Android Development] shafty023:
put 0 (zero) into each of the brightness files.

echo "0" > /sys/class/leds/green/brightness

echo "0" > /sys/class/leds/blue/brightness

echo "0" > /sys/class/leds/red/brightness
[G1 Android Development] shafty023:
I'm not sure why yours aren't working and since this is more for developers helping to get LED "FULLY" functional I'd say hold off for now. I wanted to post my results in hopes that others could help with solutions to getting them 100% functional. Sorry I should have made that clear in the original post. Doing these commands will turn them on, but the Android OS will not be able to interact with them. So unread messages won't trigger the LED, missed call won't trigger LED, etc. That's where I need other people to chime in and help with development.
[G1 Android Development] Breakthecycle2:
Well noted. Thanks again!
[G1 Android Development] chevycowboyusa:
Thanks!

Thank you!
[G1 Android Development] johnnylicious:
any more progess on this :]]

i really want this =(
[G1 Android Development] shafty023:
Still sifting through libraries with a hex editor to see which are related to LED functionality. I already know HTC modified the services.jar file in /system/framework to include dual LED methods. We can't just that jar with the old one as it breaks other HTC services that are needed
[G1 Android Development] funbacon:
Hero doesn't use LED notification, it uses A color led under trackball to show up notification.
[G1 Android Development] johnnylicious:
nothing new yet =(

i want this more than BT lol.
[G1 Android Development] Mighty07:
I've also spent some time checking this.

If that is correct and in Hero the dual_leds are located in the jogball than the system maybe trying to send the requests to device jogball_backlight that is seen in the sensors lib.

Thing is this would be easy to check having a HTC Hero not having more complicated.

As changing the services.jar is out of the question the path may go by faking the jogball_backlight device and link it to the the existing ones in dream and magic. As the structure maybe the same.

Just a thought. :cool:
[G1 Android Development] shafty023:
Unfortunately /sys is a sysfs filesystem created by the kernel. It is read-only so we can't symlink anything in there.
[G1 Android Development] allstate973rd:
gmail

is anyone missin the gmail app and widget?
[G1 Android Development] Aquilo:
If anyone's looking for something interesting involving the LEDs, try this

Go into Terminal (or ADB, your choice), and prepare to set the brightness. However, instead of issuing a command to set the brightness, issue this one instead:

echo "heartbeat" > /sys/class/leds/red/trigger

Try setting "sleep", which causes the LED to light whenever the sleep setting is changed. There's a few more listed in the kernel source, and they're not really relevant to getting things working, but they're amusing enough :)

Got it!

Right, init.rc must issue the commands to the triggers at start-up.

Possible triggers are:

none

rfkill0

battery-charging-or-full

battery-charging

battery-full

usb-online

ac-online

mmc0

mmc1

timer

heartbeat

sleep

Enjoy, I've tested them, and they're working :)

Edit: You can also issue the triggers as a command, as I've demonstrated above. These will only work for the duration of your session, though. Still, it works until the ROM Builders have integrated it into their releases.

Also of note is the delay_on and delay_off properties of each colour. These take the duration in milliseconds the LED should be on or off respectively. Using this with the "heartbeat" option would likely give us a method of reproducing the yellow "heartbeat" found in cupcake roms (For while the phone is on)

Edit 3: So now we need to redirect the dual LED calls to these, right?
[G1 Android Development] johnnylicious:
Aquilo

great job think you can post what files to push to the hero build to make the led work =D

i just neeed them asap =( so many missed messages lol
[G1 Android Development] Aquilo:
As it stands, only the kernel triggers will cause LEDs to activate. We need to find out where the other LED calls are going to, and send them in the direction of those LEDs. Possibly see if we could add extra LED triggers?

Thus it'll work to show when you're charging, etc, but not when you've got missed calls. Give me some more time, and I'll see if I can't get it working for all solutions :P

--

Edit: This looks awkward. Seems that libandroid_servers.so is our culprit for the LED_DUAL error messages. I had hoped that we could simply replace & make up some dummy redirection code and replace whatever was generating these, but libandroid_servers looks pretty important, and I'm guessing HTC will have made some large changes to it to support sense, etc. I'm going to try pushing the AOSP(master-current) one in it's place, but I'm expecting a phone crash fairly soon.

--

Edit 2: The plot thickens. I did a strings [filename] on both versions of libandroid_servers, and the main difference lied in functions to do with the Dual LEDs and with ethernet sharing. Having looked at the source of this bit, it does indeed look quite important. If I can discern what the dual-led functions are supposed to tell the outside world, we might be able to use the AOSP source to compile a new libandroid_servers.so, with our dummy functions that point to the G1's led points.

Anyone good at reverse engineering .so's? ;)
[G1 Android Development] johnnylicious:
alright great job :] i mainly need the one for sms notification i can wait for the others lol
[G1 Android Development] Mighty07:
Indeed. :)

In my post i said link but i wasn't meaning to create a symlink that would be very simple. Unfortunately is not possible. :mad:
[G1 Android Development] johnnylicious:
so what the alternative to help link the symlink?

lol
[G1 Android Development] Aquilo:
Well, I tracked down the actual LED_Dual code to libhardware_legacy.so. Size-wise, there's quite a large difference between the two. A strings comparison shows the following values which seem to pertain to our LED trouble:

JOGBALL
open failed errno: %d
write failed errno: %d
/sys/class/leds/jogball-backlight/brightness
LED_CAPS
/sys/class/leds/caps/brightness
/sys/class/leds/func/brightness
LED_DUAL
/sys/class/leds/amber/brightness
/sys/class/leds/amber/blink
%d %d
/sys/class/leds/amber/off_timer
/sys/class/leds/green/brightness
/sys/class/leds/green/blink
/sys/class/leds/green/off_timer

Now, herein lies an interesting thing. There are only two colours mentioned there, amber and green. Indeed, this is the same throughout the file. I wonder if we could change amber and green to red/green/blue (selection of the two). Obviously we'd need to change the properties to match, or try adapting the AOSP implementation of these properties to match. However, this seems like a promising route to take.
[G1 Android Development] johnnylicious:
good find aquilo hope you can expand on what you found and find a fix for it =D
[G1 Android Development] shafty023:
I'll modify the file in a hex editor and see if I can make it work. I'll post back. You also should check out I think its either services.jar or svcs.jar in /system/framework as it is responsible for actually calling those dual led functions
[G1 Android Development] Aquilo:
I tried modifying the file in a hex editor, with little success. I'm now thinking that implementing a dummy redirection method in the AOSP version might be our best plan. However, we'll need to know which lights blink when, so we can come up with a remapping scheme that doesn't wind up mixing red & green LEDs, for example (I'm Red-Green deficient, so this would be a very bad idea ;))

I'll look at services.jar, but hopefully if we modify it at the lowest level, we'll avoid any disruption or cases where our fix fails.

Edit: Checked the services.jar file. As I suspected, it's hooked into a great many things. As such, I'd be reluctant to mess with it too much, as if we break it during testing, I reckon it'd take the whole system down.

libhardware_legacy deals with far less (the most important thing being battery state management), so I reckon breaking that temporarily would be a bit safer.

Time to de-rust my C skills ;)

Edit 2: Does anyone know a way to get information on the parameters taken by methods in .so files (shared libraries)?

Edit 3: Ok, so, it appears you can get an idea for what HardwareService is being called to do, at the very least, by calling DexDump on services.odex, and searching for "dual". So if we don't patch libhardware_legacy, I guess we might be able to patch HardwareService.

Oh well, I think I'll have a day out from working away on it, having spent the past few on it I reckon I've deserved a break :P
[G1 Android Development] johnnylicious:
great progress aquilo + shafty
[G1 Android Development] johnnylicious:
any new development =(

wish i could make this work
[G1 Android Development] johnnylicious:
does the terminal code still work ;)

i might try it again.
[G1 Android Development] josevtome:
Any news?

Hi there! any news about dual-led-redirecting or anything that makes the leds to work? HTC really put this hard for everybody!! :(
[G1 Android Development] Chahk:
Forget the flashy lights, let's get something important working, such as Bluetooth, first! ;)
[G1 Android Development] shafty023:
I've been splitting my time between LED debugging and Bluetooth debugging. Haven't looked at LEDs in a bit, BT has a little bit more priority right now. I did give someone a tip where they could write a root only app that listens for any mms/sms/voicemail notifications and enables the LEDs manually. That would be a temporary hack though, nothing permanent.

So everyone is clear, no one has made an app to do this. I suggested it and how to implement it to someone. Haven't heard any word back from him.
[G1 Android Development] shafty023:
I agree and I've spent more of my time on BT than LED debugging.
[G1 Android Development] josevtome:
That's ok. I know that BT is very important for lot of people, not for me actually. I use BT very little as I don't have a car to use a BT device with, and don't like to go on the street talking with no handset and people looking weird to me :) And I don't share a lot of things with BT as I have the internet connection either by wifi or 3G connections so I use my G1 to share over mail, or another method over the web.

Instead notifications are kinda important for me, so for example I can know when my battery is nearly dead if I haven't used my phone for a while, when it completes a battery charge without having to get in the phone, see if I have a widget notification, or an email, or an sms, or any other (programmed with different colors so I can know if it's more or less important to check). This can be done with sound notifications, but leds are there for you to see, sounds are just once poped.

Anyway, just hope you guys get both things to work... I'm really looking forward for the solution, you're doing a nice job with all this! :D
[G1 Android Development] :
OK guys don't flame me if this has already been mentioned as i havent read the whole thread because i don't have enough time

from what i have read the hero device has 2 sets of leds one for charging and one for notifications. on the g1 the normal leds are being recognized as the charging notification leds because whenever i turn off my phone and plug in the charger the led comes on, so i am thinking that if you switch the settings of the leds so that instead of using them as charging notifications they are used as normal notifications although you wouldn't have charging leds they would be used then the device is on for notifications which is better. Hope u guys understood everything i have just said
[G1 Android Development] alritewhadeva:
Agreed, I need flashing lights...DOn't use bluetooth though.
[G1 Android Development] mikkodd:
me too... i never use bluetooth but would love when i have a message because i hardly hear my ringtone...
[G1 Android Development] shafty023:
The kernel is compiled with trigger support on the leds, these triggers are apparent and used in cupcake /sys/class/leds/green/trigger . They are not used in Hero and are now handled by a service which attempts to make a call to amber & green leds (dual) which do not exist. So in other words we can't "trick" or "change" the leds to work as charging leds b/c there is no "job role" for the leds. The modifications need to be done in the framework jars which will require modifying the java code. I've already attempted modifying leds.c and recompiling the kernel which did not work.

Believe me, there is not a simple answer to this. It can not be done with a simple shell script or flipping a switch unfortunately. It will require development time which I'm trying to split between this and BT and a full time job. I definitely welcome any "developers" who want to contribute and collaborate with me on led debugging. I do want to stress the word "developers" b/c like I said, it won't be something simple.

I will continue to keep everyone updated as I continue debugging leds and making progress and thank everyone for following my thread.
[G1 Android Development] neok44:
well i gotta say it's sucks that this isn't simple. right now this is the only thing i'm not liking about hero.
[G1 Android Development] shafty023:
Well I'm pretty damn close to getting BT working and then I'll be able to devote more time to making LEDS working. I believe at issue is the lights.trout.so file in /system/lib/hw was compiled for a different kernel than we're using which is why we're unable to get some of the functionality working. I have some ideas to making LEDs work just don't have the time to work on it. Juggling a lot of projects + work.
[G1 Android Development] twistedumbrella:
Proven by the mytouch having proprietary led support straight from a default Hero build, its mostly that the code is meant for both a speaker-side and wheel LED, meaning the code is meant to split the signal to both. Without a second one present the code more or less does a wtf, lol. It is different hardware. The code you first posted works, it;s just still a little rough around the edges. The important part is it works. Kudos.
[G1 Android Development] twistedumbrella:
Also, as proven by my userinit and later JACs addition to the boot image, the code activates and will hold permanantly it just had to be initiated sometime between boot up and full system on each boot.
[G1 Android Development] browerb:
It appears the only led that is working is green and when charging it looks like it only comes on when the phone is fully charges. Also I installed missed call and picked different led colors in the app but they all come on green. Anyone having this issue?
[G1 Android Development] Fictionles:
I'm going to share a simple (read SIMPLE) shell script I wrote to light up the LEDs for charging the battery while running a Hero ROM (currently tested using JACHeroSKi 2.1). It will light up red when it is charging, and will change to green (does this by default) when the charge is full.

Should work for both USB and AC plugs, since its just simply detecting whether or not the battery is being charged. It currently checks every two seconds for a status change. I have it set to run from my user.conf file to ensure it runs at startup.

I'm already planning on modifying it to only change those values when it changes "state". Feel free to modify as per your own use.
[G1 Android Development] shafty023:
Not bad, I'd take it a step further and toss it in init.rc as a service. If your init.rc is set to launch /system/init.rc then toss it in there that way you don't have to repack your boot img. It would look as follows

service leds /system/bin/sh /system/bin/leds.sh

disabled

The disabled is there so it isn't automatically run upon system start. It's probably best to run it after Android finishes booting. Leave off "oneshot" so if the script gets killed by the garbage collector then it'll automatically get relaunched again :)

Good job by the way. I'd send this script along with my recommendation to run it as a system service to the ROM devs.
[G1 Android Development] kingklick:
so do LED's work for notifications such as mms or missed calls with these commands?
[G1 Android Development] rpmccormick:
So correct me if I'm wrong, but we are still not on the verge of a solution so that all 3 leds work with normal apps (like ChompSMS allows you to chose from many colors-combos of the 3 leds), are we?
[G1 Android Development] Fictionles:
Thanks! Just battery charging notification works with that script. A different method would have to be used for message notification.
[G1 Android Development] shafty023:
That is correct, we are not on the verge of a full fledged implementation. The reason battery notifications can work is b/c a file in the actual linux filesystem is modified when the battery status changes. We are able to read that file and act on it to turn on leds.

There isn't such a file for mms/sms/voicemail/etc. Those events are handled through the android java platform. You would need to write a program in java that would intercept those events and then manually turn on leds. It would actually be pretty simple to do and would be a root only app but I don't have the time to spend and write it. Got too much stuff on my plate already.
[G1 Android Development] Fictionles:
I've been running my script the rest of yesterday and today and noticed that it somehow broke the normal LED notification. So I quickly wrote another script that runs in the background and if it sees any of the other LEDs brightness being set to 1, it'll reset it to 50. So far its working again for SMS and email, but only for Green. No other colors (still.)

Will keep everyone posted.
[G1 Android Development] shafty023:
Perhaps you should reset all LEDs to 0 before checking for a battery state. I'm wondering if we could use init.rc by adding an "on property:xxxxxx" to launch a service which in turn launches your script. That would be a lot better as your script is polling every 2 seconds which could cause an issue with load/cpu
[G1 Android Development] Fictionles:
I'll admit my script is just a band-aid proof-of-concept to see if it works.

I'll add those value resets and see if it helps. But yeah, calling it on a property change would be the preferred solution.

Here's my latest version of the script I'm using. It keeps track of the battery's last "state". So it only updates those values when it changes. Should be less resource intensive when calling it directly.
[G1 Android Development] javacody:
I've tried to set this up as a service in Jac Hero 2.1. It's not working. Any ideas? I did chmod the file and can execute it. Once I execute it however, the red LED stays on until I reboot (even after unplugging).

EDIT:

Here's what I get from the console:

$ adb shell /system/bin/batt.sh

oldvarname: not found

oldvarname: not found

oldvarname: not found

oldvarname: not found

oldvarname: not found
[G1 Android Development] Fictionles:
The script is still very raw. I'm going to pull it until I can iron out the issues.
[G1 Android Development] javacody:
Thanks for working on this, and I'd be glad to test for you.
[G1 Android Development] Fictionles:
I'm currently running a newer version of the script I posted (and later pulled due to me finding numerous errors with it). I've cleaned it up and have been running it without any error messages when called from the terminal. I've modified the code slightly so that it will only make changes if it detects a change in the battery status, so it should help improve performance.

My only issue with it right now is I can't keep it from getting killed. I used the Autostart app from the market to kick it off during boot it was fine for a few hours I was using it, then after going to bed and waking up 8 hours later it was gone.

Currently trying the Scheduled Scripting App jinx was brilliant enough to create and I've re-coded the script to only run for less than a minute and have the scheduler kick it off. I'll post the script later tonight if it works better today.
[G1 Android Development] javacody:
Sounds great! Thanks for sharing.
[G1 Android Development] shafty023:
Ya the garbage collector and memory manager are going to kill it. Only way to workaround this is to run it as a system service via the init.rc script which you can only modify by opening the boot.img file, putting it in init.rc and then repacking/flashing the new boot.img file. If that's the route you want to take shoot your script over to the ROM devs so they can incorporate it
[G1 Android Development] javacody:
Shafty, I tried setting it up as a service, but nothing happened. JAC Hero images call /system/init.rc (which is where I added it). Any tips on debugging?
[G1 Android Development] Fictionles:
Since I don't have access to a Linux (or Unix) box to explode those img files, I'll be posting a newer version of the script I'm currently using later. I've removed the recursion (constantly running) aspect of it, since I was experiencing some weird behavior; either the process would just die on its on, or my phone wouldn't wake up from standby.

The process dying aspect looks like its going to be a given until it (or someone) can add it to a init.rc file in their boot.img file. I want to at least ensure it'll run for several hours before I post the code here.
[G1 Android Development] javacody:
Fictionles, you want to pm me the file? I can test it out as well. I have it set up to run as a service in /system/init.rc (which is called by /init.rc).