[MeMO Pad 7 Q&A, Help & Troubleshooting] tuxic001:
Hi Mis012,

sorry for not responding for a while: I had to buy something to eat and drink. ;)

By the way: May be it would ease the postings exchange a little bit; I am here at UTC+1 (+1 additional hour

summer saveing time. Currently it is 17:19 local time).

To the code and the handling of keys in general (please excuse if I am talking about already known for centuries...):

The SoC( System on Chip) -- in this case the CPU and the chipset) in embedded system often are handling the recognition

of key pressing events via GPIOs (General Purpose Input/Output <pins>). This CPU/chipset pins can be configured via software

to what they have act as: Input line, output (signal) line, A/D converter input, PWM pins etc....

There are only three keys (on/off switches): Volume Up, Volum Down (two seperate switched combined under one big plastic "bridge")

and one power switch (on/off). ALL switches are open by default and if released. Even the power switch is no bistable switch with two

rest positions but a switch witch only gives contact when pressed.

There are three GPIO lines - each used for one of the switches. Each line is "pulled up" via a resistore to 5V+. The switch pulls the line

down to ground when pressed.

When done a certain bit in a certain register of the CPU is switched and/or an interrupt is generated.

A piece of software is tied to that interrupt (good solution) or is polling the according registers (active idle processing. BAD!).

What use see in the source code is the keyScanCode, which is the software representation of the register/s in question.

The case-switch is comparing the keyScancode with the bit pattern of the register for that case of certain key press events.

The reason, why "on/off" is not recognized is either: The case switch is not asking for the correct keyScanCode for "Power button pressed"

OR (which would be bad) "Volume up/down" is represented by the content of "keyScanCode" and "Power key pressed" is handled via

another register.

If you can find a piece of code, which seems to print anything onto the screen AND you can get out of the program while it is executed, my suggestion would be to

modify the code like this:

[/COLOR]

// react to key press
### Add print code here THIS IS ONLY AN EXAMPLE!
printf( "[keycode]>0x%02<\n",key.ScanCode );
switch (key.ScanCode) {
case SCAN_UP:
UpdateScroll(&State, SCROLL_LINE_UP);
break;
case SCAN_LEFT:
UpdateScroll(&State, SCROLL_LINE_LEFT);
break;
case SCAN_DOWN:
UpdateScroll(&State, SCROLL_LINE_DOWN);
break;
case SCAN_RIGHT:
UpdateScroll(&State, SCROLL_LINE_RIGHT);
break;
case SCAN_HOME:
UpdateScroll(&State, SCROLL_FIRST);
break;
case SCAN_END:
UpdateScroll(&State, SCROLL_LAST);
break;
case SCAN_PAGE_UP:
UpdateScroll(&State, SCROLL_PAGE_UP);
break;
case SCAN_PAGE_DOWN:
UpdateScroll(&State, SCROLL_PAGE_DOWN);
break;
case SCAN_ESC:
MenuExit = MENU_EXIT_ESCAPE;
break;
case SCAN_INSERT:
case SCAN_F2:
MenuExit = MENU_EXIT_DETAILS;
break;
case SCAN_F10:
egScreenShot();
break;
case 0x0016: // F12
if (EjectMedia())
MenuExit = MENU_EXIT_ESCAPE;
break;
}

This way each keycode is printed onto the screen (ATTENTION! This can and will completly scre up the contents of the screen!!! That's why you need a way

out of it *blindly*!)

No press power and release it. WIth luck you can see the changes in the print and can change the case-switch accordingly.

But this is only a rugh idea.

First I need something to eat and later I will take a look into the code itsself...

Keep hacking! 8)

Best regards

tuxic