Your development board might be using matrix
keyboard mode instead of directly connecting each button on each single
GPIO.
I got similar sympton when porting on the Asus P535 and got it solved
by changing the keypad driver.
Jinjun wrote:
Hi,
I am using PXA270 as my development board for A
Hi,
I guess your display driver doesn't support panning function.
Each time you press the cursor key, Android updates frame buffer,
but if frame buffer driver doesn't support panning function, only once
between twice your display is actually updated.
On Dec 10, 11:39 am, Reed Huang <[EMAIL PRO
Thanks.
Is it easy to modify the framebuffer driver to support panning
function? Can you provide a brief description?
Jinjun
On Dec 9, 7:42 pm, mizmit1222 <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I guess your display driver doesn't support panning function.
>
> Each time you press the cursor key, An
I just checked my drivers/video/vfb.c, in which vfb_pan_display is
defined, with the one from Android SDK downloaded. They are
identical.
Am I looking in the wrong place?
Thanks,
Jinjun
On Dec 10, 2:52 pm, Jinjun <[EMAIL PROTECTED]> wrote:
> Thanks.
> Is it easy to modify the framebuffer driver
Hi Reed,
I am using USB mouse and keyboard. How do I change the kpad driver?
Thanks,
Jinjun
On Dec 9, 7:42 pm, mizmit1222 <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I guess your display driver doesn't support panning function.
>
> Each time you press the cursor key, Android updates frame buffer,
> bu
Hi,
I'm playing with Sharp Zaurus C3000 whose CPU is PXA270.
The frame buffer driver is pxafb.
See pxafb_pan_display() in the patch file of this page.
http://androidzaurus.seesaa.net/article/105551643.html
Also, ypanstep should be set to none-zero at initialization.
Cheers,
On Dec 11, 10:16 a
Thanks,
I have taken a look at my pxafb.c file and it is different from your
file "a", the one before the patch you provided.
We have tried to integrate your patch to our current code and it did
not solve our problem. Is it good enough that just add
pxafb_pan_display function to our current code
Hi Jinjun,
You can take a look at my pxafb.c here:
http://sites.google.com/site/siteofhx/Home/android/android-porting-steps/english/pxafb.c?attredirects=0
And you should set one of your button's keycode as KEY_BACK. Then you
will be able to get back to previous screen by pressing that butto
Sorry, the file has been moved to this link address:
http://sites.google.com/site/siteofhx/Home/android/relevant-porting-files
--~--~-~--~~~---~--~~
unsubscribe: android-porting+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-porting
-~-
Hi
I'm having similar problems with a Freescale iMX31 processor. Any
iMX31 users that solved this problem?
On Dec 12, 9:53 am, reedhuang wrote:
> Sorry, the file has been moved to this link
> address:http://sites.google.com/site/siteofhx/Home/android/relevant-porting-f...
--~--~-~--~---
On Dec 9, 9:39 pm, Reed Huang wrote:
> Your development board might be using matrix keyboard mode instead of
> directly connecting each button on each single GPIO.
> I got similar sympton when porting on the Asus P535 and got it solved by
> changing the keypad driver.
Reed,
Can you give a few
Hi Reed,
We just compiled our kernel with the pxafb.c file provided by you. It
solved our problem. Thank you for your help.
We still have problem of getting back to previous screen. I have done
the following in my "Dell USB Keyboard Hub.kl" file
1) Added a line of "key 68 MENUKEY_BACK". Sti
>
> For the rest of people who is interested in this topic, the following
> is the difference between my pxafb.c and the one provided by Reed.
>
Reed had mentioned changes to the keyboard driver. I see that he also
made modifications to his fb driver, but those are for a pxa target
and I'm using
You may have some other issues that I don't know how to fix it.
However, you can still choose the icons and menus you like. Just to
remember that the frame buffer is refreshed every other key stroke.
For example, if you want to select a icon that is down right to the
current one, press right and d
Hi Twebb,
Please refer to my p535_keypad.c file here:
http://sites.google.com/site/siteofhx/Home/android/relevant-porting-files
Which will give you a clear view of how a matrix keypad driver is
written.
twebb wrote:
On Dec 9, 9:39 pm, Reed Huang wrote:
Your development board m
Hi Jinjun,
It's no the kl file needed to be changed. It's your keypad driver.
In my case, there is a line defined in qwerty.kl file as following:
key 158 BACK WAKE_DROPPED
which means that Android will regard the key code 158 sent by keypad
driver as BACK key.
So the change
Hi Reed,
In order for my board to take my USB keyboard input, I just copied
qwerty.kl file to "Dell USB Keyboard Hub.kl". Their content are
identical. There is a key 158 BACK WAKE_DROPED entry there. Just don't
know what is the key
combination for key code 158.
Thanks for help and I will keep you
I am not sure about how USB keyboard driver works,
but in my case, the P535 keypad is connected as a 3*6 keypad matrix, so
in the keypad driver, just define the key code for each key as follows:
static unsigned int p535_key_map[] = {
KEY(0, 0, KEY_BACK),
KEY(0, 1, KEY_MENU),
KEY(0
> Please refer to my p535_keypad.c file
> here:http://sites.google.com/site/siteofhx/Home/android/relevant-porting-files
> Which will give you a clear view of how a matrix keypad driver is written.
Reed,
I have a matrix keypad driver already, and it works fine for all key
presses. The problem i
Hi Twebb,
At first, I thought each button on P535 was directly connected with
each GPIO, so I used a GPIO button driver. With that driver, I got a
problem with was similiar to what you described. After I figuring out
that it was a matrix keypad and changed the keypad driver, the problem
got
> Have you got the frame buffer driver work correctly? If not, maybe you could
> try making it work first and then see whether the keypad problem still exists.
I have frame buffer driver working OK. Unless of course it's a frame
buffer issue that is resulting in the cursor highlight not followi
You can use ddms to get a snapshot of the screen... which I believe does
this be re-compositing the windows into an off-screen buffer, so should let
you see what the system actually things it is displaying before any driver
problems get in the way.
On Mon, Dec 15, 2008 at 12:58 PM, twebb wrote:
> You can use ddms to get a snapshot of the screen... which I believe does
> this be re-compositing the windows into an off-screen buffer, so should let
> you see what the system actually things it is displaying before any driver
> problems get in the way.
>
That sounds like a good approach. Ho
23 matches
Mail list logo
