Hi, all:
I am now debugging some tough bug on the ICS of origen board(some samsung
exynos4210 A9). For this board, it will use some gpio-keys.kcm as its
keymap, but I got something wrong from its logfile:
E/KeyCharacterMap(2024): /system/usr/keychars/gpio-keys.kcm:1: Expected
keyboard type label, got 'QWERTY'.
Anyone knows why and how to modify the following kcm file?
Thanks!
-jack
On 8 March 2012 00:01, YongQin Liu <yongqin.liu(a)linaro.org> wrote:
> Hi, Zach
>
> Here is what you write in the memo:
> https://docs.google.com/a/linaro.org/document/d/1mtaw5sVwVD4CD1fbAk0XU9jxIs…
>
> 1. Pass TESTCOMMANDFILE1=a file from git via Android build
> 2. Pass TESTCOMMAND1=”command opt1 opt2” via Android build
> the command should be executed on the android, that means the command should
> be an android command. not a command of the host.
>
> 3. Be able to reboot the unit within one test
> 4. CTS
> 5. Pass a meta file back for parsing, or just a parser
>
>
> Here I can understand the 1st and the 2nd and the 5th.
>
> About the 3rd, we have talked about yesterday, the attachment file
> (talk.log) is the content of our talk yesterday.
> and I understand it like this:
>
>
> In some test case, there are the possibilities that the android image will
> reboot,
> and we should be able to handle such cases so that we can get the exact test
> result.
>
>
> and I thought about that again after the talk, there are also other
> possibility like reboot, such as power down, crash, freeze
> you mean all of these cases should be handled too?
Right. If a command in the command log causes the unit-under-test to
do any of those things, then the unit should be rebooted (in the case
of a hang) or the reboot should be sensed (in case the command caused
a reboot) and when the unit boots back up, LAVA would continue the
test on the command after the one that caused it to hang, reboot,
freeze, etc. LAVA should save the logs for the entire command file
run, including all hangs and reboots.
> About the 4th one CTS, sorry, I am still not clear about what do you mean
> here by CTS,
> if possible, could you describe a test case about that?
Take a look at: http://source.android.com/compatibility/cts-intro.html
The suite is available here:
http://source.android.com/compatibility/downloads.html
We simply need to run the existing test cases:
http://dl.google.com/dl/android/cts/android-cts-4.0.3_r2-linux_x86-arm.ziphttp://dl.google.com/dl/android/cts/android-cts-verifier-4.0.3_r1-linux_x86…
Which are written against:
http://source.android.com/compatibility/4.0/android-4.0-cdd.pdf
> Thanks,
> Yongqin Liu
>
--
Zach Pfeffer
Android Platform Team Lead, Linaro Platform Teams
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
Hi all,
I'm working on a PXA320 on gingerbread. After implementing the GCU graphics acceleration, I'm working on having skia and android using fixed float. It is not
a patch submission but give an idea about the problem that we have.
index a10371f..93c162f 100644
--- a/WebCore/platform/graphics/skia/FloatRectSkia.cpp
+++ b/WebCore/platform/graphics/skia/FloatRectSkia.cpp
@@ -36,14 +36,14 @@
namespace WebCore {
FloatRect::FloatRect(const SkRect& r)
- : m_location(r.fLeft, r.fTop)
- , m_size(r.width(), r.height())
+ : m_location(SkScalarToFloat(r.fLeft), SkScalarToFloat(r.fTop))
+ , m_size(SkScalarToFloat(r.width()), SkScalarToFloat(r.height()))
{
}
FloatRect::operator SkRect() const
{
- SkRect rect = { x(), y(), right(), bottom() };
+ SkRect rect = { SkFloatToScalar(x()), SkFloatToScalar(y()), SkFloatToScalar(right()), SkFloatToScalar(bottom()) };
return rect;
}
This fix on the webcore help to start to render webpage. But there are several points to fix.
I would like to know if there is some interest on this topic
Michael
