[SOLVED: nueKBLight] Quest to modify the timeout for hardware keyboard. - Page 2

eptd · #11 (**permalink**) 11-15-2008, 04:50 AM

This is the one thing I would change also. I think with every other phone used, the keyboard/keypad was synchronized with the screen backlight. This seems very logical, I don't know why they would have the keyboard light go out so soon.

Defiler · #12 (**permalink**) 11-15-2008, 06:17 AM

This is prolly my number one complaint ATM with this phone...

**LilRico** · #13 (**permalink**) 11-15-2008, 06:27 AM

Subscribed!

musiqlives · #14 (**permalink**) 11-15-2008, 02:12 PM

Quote:

Originally Posted by Cicatrize

Ok...I'm going to do this. It's probably going to take a while, but it will happen. Everyone knows the keyboard backlight goes out after about 6 or 7 seconds, and it's very frustrating. If there was one thing I could change about the Touch Pro, this would probably be it. So, let's get this project rolling...

I'm fairly fluent in VB and C++, so as long as the alleged system dll's that control these lights are coded in one of these two languages, I could, in theory, recode and compile with the proper tools. One of the following needs to happen:

1. Someone with a dll/exe decompiler needs to decompile the code and send it to me.
2. Someone needs to donate enough money to pay for a decompiler license (not cheap, $100+)

Since 2 is unlikely to happen, please let me know if you have access to a decompiler.

I think there are further possibilities as well, but I don't know. I haven't seen this talked about before. If you have, please chime in as well.

Man I'm so glad someone else feel the same. Its a pain in the "you know what" when you are trying to you the keyboard in the dark. I'll be watching this thread. Thanks for trying.

mdodge · #15 (**permalink**) 11-15-2008, 04:37 PM

Just of note since I've been playing a little with this. The GSM version of the pro responds to the qkeytimeout reg key, but sprints does not. I tried to install some dll's from the gsm rom but it only disabled my key lights completely. But you may want to look at those to get an idea. I'm convinced its not hardware because of this.

**Cicatrize** · #16 (**permalink**) 11-15-2008, 09:14 PM

Quote:

Originally Posted by mdodge

Just of note since I've been playing a little with this. The GSM version of the pro responds to the qkeytimeout reg key, but sprints does not. I tried to install some dll's from the gsm rom but it only disabled my key lights completely. But you may want to look at those to get an idea. I'm convinced its not hardware because of this.

Hmm...this brings some new light to it, I guess. Now I just need to get this DLL decompiled!

mdodge · #17 (**permalink**) 11-15-2008, 10:16 PM

I tried a few programs to decompile it but was unsuccessful. Said there is no CLI header. I'm refering to Microp.dll and allledmgr.dll. I'm wondering if they can even be decompiled at all

**Cicatrize** · #18 (**permalink**) 11-15-2008, 11:49 PM

Anything can be decompiled.

What disassembler are you using, and what language are you trying to disassemble?

If there's no CLI header, then it can't be .NET, which I didn't expect, but I guess that's the deal. All your decompilers must only handle managed code. Do you have access to a diassembler that will handle unmanaged or native code?

EDIT: Now that I think about it, I'm not surprised if it's not managed code. Hell, they've been using these same DLL's for ages, most likely. Probably before .NET even became a programming standard. It's probably coded in old C++.

**stroths** · #19 (**permalink**) 11-16-2008, 12:29 AM

Quote:

Originally Posted by mdodge

I tried a few programs to decompile it but was unsuccessful. Said there is no CLI header. I'm refering to Microp.dll and allledmgr.dll. I'm wondering if they can even be decompiled at all

There is another approach one can take as well. Write an intermediate driver that sits between the system and the regular driver. For example, no2chem wrote an intermediate driver that talked to the alledmgr.dll on the 6800s and 6900s. It allowed us to control the LED behavior. The registry was changed to the new intermediate driver which in turned talked to alledmgr.dll.

mdodge · #20 (**permalink**) 11-16-2008, 01:16 AM

Quote:

Originally Posted by Cicatrize

Anything can be decompiled.

What disassembler are you using, and what language are you trying to disassemble?

If there's no CLI header, then it can't be .NET, which I didn't expect, but I guess that's the deal. All your decompilers must only handle managed code. Do you have access to a diassembler that will handle unmanaged or native code?

EDIT: Now that I think about it, I'm not surprised if it's not managed code. Hell, they've been using these same DLL's for ages, most likely. Probably before .NET even became a programming standard. It's probably coded in old C++.

I only have PE explorer and reflector (which is free btw). I tried the following:

IL
MC++
C#
Visual Basic
Delphi
Chrome

I'm sure a way exists to do it but I'm not an experienced in decompiling but thought I would help in anyway I could, cause this problem drives me nuts lol

And I'm sure a new driver could be introduced by someone with the know-how. But without seeing the current structure, source of the dll's, I would assume it would be much harder to make one. Kind of like programming in the dark.