As a hobby, I'm trying to run android-x86 2.3 with 64-bit linux 3.0.1
on a Samsung 700T1A. I've already done some changes in binder, ashmem
and alarm-dev, basically related to compat_ioctl.
By today, I have a quite normal boot process - the android logo, then
a home screen with widgets, but GUI doesn't respond to input devices,
nither a keyboard nor a mouse or touchscreen.
I'm sure that the system doesn't hang, cause I see widget animation
and even the battery indicator shows the actual state of an AC
adapter. I can switch to console and back with Alt-F1 and Alt-F7.
ts_calibrate works too.
I know it's hard to tell something without dmesg and logcat logs, but
I can't attach them right now, sorry.
Maybe someone knows how android work with input devices and what is a
cause of the issue?
Thanks,
Pavel.
In a console, can you run getevent to see if the kernel catches any
events, and getevent -p to see the flags that device drivers provide?
Looking at your logcat (I had recently to dig in it when playing
around with UML kernel):
EventHub at least sees your devices. But line 431
431.E/EventHub( 350): could not add watch for /dev/input, Function
not implemented
perhaps inotify is not in the kernel?
Android works with input devices by multiplexing anything that can be
read from /dev/input/eventN device files.
You may try to implement additional logging for the events to see how
they propagate. In Gingerbread it is libs/ui/EventHub.cpp * in the
platform/frameworks/base repo.
bool EventHub::getEvent(RawEvent* outEvent)
is called by applications to obtain input events.
Hope this helps.
------------------------------------------------------
* Interestingly, in ICS EventHub is gone, but there is something like
Input.cpp which must carry the same functions - we'll see.
Hmm... really, the getevent app, regardless to flags, prints:
could not add watch for /dev/input, Function not implemented
I'll take a deeper look at EventHub.cpp and share the results soon.
Thanks a lot, now, at least, it's clear where to dig.
Pavel.
I've compiled EventHub.cpp with a logging feature and now I have the
following logcat output:
...
V/EventHub( 362): /dev/input/event7 got: vt=7 t0=1894, t1=345817,
type=0, code=0, v=0
V/EventHub( 362): /dev/input/event7 got: vt=7 t0=1894, t1=401810,
type=1, code=31, v=0
V/EventHub( 362): iev.code=31 keyCode=47 flags=0x00000000 err=0
V/EventHub( 362): /dev/input/event7 got: vt=7 t0=1894, t1=401812,
type=0, code=0, v=0
V/EventHub( 362): /dev/input/event7 got: vt=7 t0=1894, t1=481809,
type=1, code=20, v=0
V/EventHub( 362): iev.code=20 keyCode=48 flags=0x00000000 err=0
V/EventHub( 362): /dev/input/event7 got: vt=7 t0=1894, t1=481811,
type=0, code=0, v=0
V/EventHub( 362): /dev/input/event7 got: vt=7 t0=1895, t1=233806,
type=1, code=56, v=1
V/EventHub( 362): iev.code=56 keyCode=57 flags=0x00000000 err=0
....Surprisingly, EventHub receives events from every device I have -
buttons on the device, tablet pen, touchscreen, keyboard, mouse, but
without response in GUI.
Any suggestions?
Pavel.
On Nov 21, 2:55 pm, Pavel Prokofiev <integral....@gmail.com> wrote:
> Played a little with getevent:
> 1) getevent /dev/input/event{digit} prints data when I interact with
> the input device
> 2) without a specific device it prints: could not add watch for /dev/
> input, Function not implemented. After including inotify into the
> kernel, getevent started to print multiplexed events from all devices
OK, so this was the main reason events were not seen.
>
> I've compiled EventHub.cpp with a logging feature and now I have the
> following logcat output:
> ...
> V/EventHub( 362): /dev/input/event7 got: vt=7 t0=1894, t1=345817,
> type=0, code=0, v=0
So, eventhub gets your events. You may try to add more log output to
see how events are propagated (that is, in the function which calls
getEvent - this must be in the same repo - grep to your help ;).
> ....Surprisingly, EventHub receives events from every device I have -
> buttons on the device, tablet pen, touchscreen, keyboard, mouse, but
> without response in GUI.
Yes, anything that has a EVDEV interface will be involved.
Few suggestions. In order to be recognized properly, event interface
devices should consistently set bits in their mask words. See include/
linux/input.h in the kernel tree. This is general Linux stuff, but
Android seems to mess with this too much.
In general, it recognizes the type of device by bitmasks its driver
provides.
If it is a mouse, it has to report relative movements. Thus, events
must be reported with REL_X and REL_Y type (in the driver).
if(diffx) input_report_rel(kd->mouse, REL_X, diffx);
if(diffy) input_report_rel(kd->mouse, REL_Y, diffy);
Also, mouse driver should when initializing set bits as follows:
set_bit(BTN_LEFT, kd->mouse->keybit);
set_bit(BTN_MIDDLE, kd->mouse->keybit);
set_bit(BTN_RIGHT, kd->mouse->keybit);
set_bit(EV_REL, kd->mouse->evbit);
set_bit(REL_X, kd->mouse->relbit);
set_bit(REL_Y, kd->mouse->relbit);
That is, it reports 3 buttons (keys), declares itself a relative
device (EV_REL) and tells the kernel that event bits are REL_X and
REL_Y
If a mouse reports absolute coordinates, Android would think it is a
touchscreen. And so on. Basically EventHub has all this logic. If a
mouse reports absolute coordinates, an event just gets dropped.
I got to this during my experiments with user-mode linux where I had a
framebuffer patch which emulated a mouse, but not all bits were
intact, so while getevent was able to print events, EventHub dropped
them. Code above is from that patch.
Regards.
Finally, I've got the keyborad works.
By the Dmitry's advice, I began the investigation from framework/base/
libs/ui/EventHub.cpp and found out that, in InputDispatcher.cpp, my
input events are droped cause they don't have a
POLICY_FLAG_PASS_TO_USER flag in the .policyFlag field.
As I understood, the workflow is following:
1) Before queueing event for dispatch, InputDispatcher asks
InputDispatcherPolicy to adjust policyFlag (or maybe a little more)
2) Execution goes to NativeInputManager::interceptKeyBeforeQueueing()
(frameworks/base/services/jni/com_android_server_InputManager.cpp).
This is a jni-wrapper for Java implementation of
interceptKeyBeforeQueueing()
3) Next, somewhere in Java, the events should receive their
POLICY_FLAG_PASS_TO_USER flag.
I found the real implementation of interceptKeyBeforeQueueing() in
frameworks/base/policy/src/com/android/internal/policy/impl/
PhoneWindowManager.java.
Code from PhoneWindowManager.java:
...
if (isScreenOn || isInjected) {
...
result = ACTION_PASS_TO_USER;
} else {
...
It turns out that the required flag is set only if a device screen is
on, but according to a value of *isScreenOn*, my screen is always off.
To prove my idea, I've changed isScreenOn -> true and it worked!
I continued looking for the root cause, and where *isScreenOn* comes
from.
The source of a value is
android_server_PowerManagerService_isScreenOn() (from frameworks/base/
services/jni/com_android_server_PowerManagerService.cpp and frameworks/
base/services/java/com/android/server/PowerManagerService.java)
While digging in the PowerManager code, I accidentally discovered that
I don't have /sys/power/wake_lock and next, I found a strange thing in
$(linux_kernel_top)/kernel/power/main.c:
..
static struct attribute * g[] = {
&state_attr.attr,
#ifdef CONFIG_PM_TRACE
&pm_trace_attr.attr,
&pm_trace_dev_match_attr.attr,
#endif
#ifdef CONFIG_PM_SLEEP
&pm_async_attr.attr,
&wakeup_count_attr.attr,
#ifdef CONFIG_PM_DEBUG
&pm_test_attr.attr,
#endif
#ifdef CONFIG_USER_WAKELOCK
&wake_lock_attr.attr,
&wake_unlock_attr.attr,
#endif <-----------------------------------| HERE
#endif <-----------------------------------| HERE
NULL,
};
...
CONFIG_USER_WAKELOCK only make sense if CONFIG_PM_SLEEP is defined,
but in Kconfig there is no dependance between them.
A long story short, after enabling "CONFIG_SUSPEND" in the kernel, all
input devices started to work.
The End:)
Thanks,
Pavel.
It's great that you got the keyboard to work. This is also a very good
explanation for somebody who eventually runs into the same things.
On Nov 23, 7:49 am, Pavel Prokofiev <integral....@gmail.com> wrote:
> A long story short, after enabling "CONFIG_SUSPEND" in the kernel, all
> input devices started to work.
Yes, I recall the same thing in the User-mode kernel (which obviously
has a lot of things excluded or not enabled by default) - some weird
and seemingly unrelated option turned input on for me. But that was
kernel 2.6.29 (and who knows how things turned around in 3.0 ;)
Thanks.
On Thursday, December 22, 2011 at 10:58 PM, fsck wrote:
Hi Pavel,
I also have a XE700T1A Samsung Series 7 Slate PC and interested to get Android working on it.
I managed to install android-x86-4.0-asus_laptop-20111209.iso but I have no wifi and no touch input (only USB keyboard)
I was wondering if got anything more working?
Can you share?
Is there a wiki/forum where we could collaborate on this topic?
Cheers,
--
fsck
Thanks for your answers.
I am currently stuck with a "white terminal" issue. When I use the
terminal application in android, the window is just white, I can enter
commands, but I can not 'really' see output. Also if I use ALT+F1
keys, similar behaviour happen. I can sometime quickly see
(sub-second) the black terminal with a kind of the android desktop at
the top. I saw in other thread that I may be due to a bug in android.
I have been trying with different "repo sync" for a week now. I didn't
have the issue with android-x86-4.0-asus_laptop-20111209.iso
Are you ever experienced the same issue?
I haven't tried your kernel yet but I am working on it. Following
http://www.android-x86.org/documents/how-to-add-new-x86-platforms I
guess I have to:
1. 'cd device && tar xvfz islate.tar.gz'
2. apply your patch: islate.patch in the android tree. 'cd kernel &'
patch --dry-run -p1 < ../../islate.patch'
3. re-compile kernel: 'make -j2 iso_img TARGET_PRODUCT=islate
CC=gcc-4.4 CXX=g++-4.4'
Please confirm this steps.
As you can see, I am currently using the iso_img to boot using USB
disk formated in FAT32. I was wondering if you installed it on SSD
drives and what partition size you used and how/if you managed to keep
dualboot with Windows.
Cheers,
--
fsck222
Hello,Sorry for the delay.Yes, I have working touchscreen and wifi on my tablet. The main reason for most issues is a wrong kernel config. For the touchscreen support I've added Atmel's MAXTouch USB ids to the "hid_touchscreen" driver and put a calibration file (see is islate.mk).
If you stuck with something, I'm very glad to collaborate on your problems with you, android-x86@googlegroups.com can be used for that.
--
You received this message because you are subscribed to the Google Groups "Android-x86" group.
To view this discussion on the web visit https://groups.google.com/d/msg/android-x86/-/PZ7swZerzWkJ.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-x86...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-x86?hl=en.
Hello folks,As a hobby, I'm trying to run android-x86 2.3 with 64-bit linux 3.0.1
on a Samsung 700T1A. I've already done some changes in binder, ashmem
and alarm-dev, basically related to compat_ioctl.
Hi,
I tested wifi again this morning on a different network. It did work. So I think it is linked to the security used on the network it worked on WPA but not on WPA-PSK.
Cheers,
Florent.
On Monday, April 16, 2012, яПНяПНяПНяПНяПНяПН яПНяПНяПНяПНяПНяПНяПНяПНяПН <floofy.la...@gmail.com> wrote:
> Hi,
> I got a bit further on the problem with wifi. It seems the 700t1a ships a "intel centrino 6230" wifi adapter that requires the iwlwifi kernel module.
> The options for iwlwifi were not set in kernel config, and the iwlwifi firmwares were not added to the built system. So I built a new one with Pavel's patches, I've set the IWL-related options in kernel config яПНto build modules, and added the IWL firmwares to the release. Then, when i enabled wifi in Android settings, dmesg complained about missing firmware file "iwlwifi-6000g2b.ucode".
> This firmware file does not exist in the android-x86 source tree, so I fetched the one installed on my linux desktop. This allowed me to enable wifi and scan networks under Android. But connecting to them fails, I'll do some more testing later on.
> Hey Pavel ! Are you still reading this thread ? It's been a long time we haven't seen you around !
> Cheers,
> Florent.
>
> On Thu, Apr 12, 2012 at 8:34 PM, яПНяПНяПНяПНяПНяПН яПНяПНяПНяПНяПНяПНяПНяПНяПН <floofy.la...@gmail.com> wrote:
>
> Hi Pavel,
>
> I see you've been changing stuff in the repo. So, what about this new directory (s7s) ? Should I now build this one or islate ?
>
> I've also seen a new tag in android-x86 repo. should I build from this one now ?
>
> Cheers,
> Florent.
>
> On Wed, Apr 4, 2012 at 10:13 AM, яПНяПНяПНяПНяПНяПН яПНяПНяПНяПНяПНяПНяПНяПНяПН <floofy.la...@gmail.com> wrote:
>
> Hi Pavel,
> I had no time to test the patch yet, but here's what I get in logcat when I try to enable wifi:
> ...
> E/WifiStateMachine(...): Failed to load driver!
> E/WifiStateMachine(...): DriverFailedState
> ...
> Can't see anything relevant in dmesg,
> On Tue, Apr 3, 2012 at 7:04 PM, Pavel Prokofiev <integr...@gmail.com> wrote:
>
> HiяПНFlorent,
> Thanks, I've really uploaded a single file twice.
> About patches...
> The amaxtouch patch is for enabling hid-multitouch driver to handle Atmel touchscreen device, it simply adds correspondent usb VID and PID to the driver.
> The android-x86_64 patch is a bit more complicated. Your tablet has an UEFI2 firmware which is 64bit, it requires the kernel to be booted in UEFI mode and the kernel processor architecture should match the firmware architecture. Some android-specific kernel modules are not compatible with 64bit mode, the patch workarounds this.
>
> Another way is to enable bios emulation mode in the Setup and use a 32-bit kernel configuration.
>
> So you will need to apply both patches if you want to use UEFI.
>
> What is logcat output, anything about Wifi malfunction?
> Pavel.
>
> 2012/4/3 яПНяПНяПНяПНяПНяПН яПНяПНяПНяПНяПНяПНяПНяПНяПН <floofy.la...@gmail.com>
>
> Thanks Pavel.
> I tried that yesterday. The system atяПН http://android-samsung700t.googlecode.com/files/android-x86_64-EFI2.zipяПНboots up properly, touchscreen is works. But Wifi doesn't. I tried to compile the system using the files fromяПНhttp://code.google.com/p/android-samsung700t/, but the gui doesn't show up, and the slate reboots continuously.
> Just to be sure, do I need to apply the patches from theяПНяПНhttp://code.google.com/p/android-samsung700t/яПНfiles or not ? Do I have to build the projects in fb_test and fb_test2 ?яПНI did a diff on the two patch files, and they are identical ?
> Cheers,
> Florent.
>
> On Mon, Apr 2, 2012 at 3:09 PM, Pavel Prokofiev <integr...@gmail.com> wrote:
>
> Hi,
> The islate device directory you have download was intended for android 3.x. Check out the sources and download section of http://code.google.com/p/android-samsung700t/. I've updated files to support 4.x.
> As I understood, there is an issue with audio support in ics (I could be wrong here), so for now I've disabled audio at all. It would be awesome If you'll find a time to investigate this.
> If you have exactly the 700T1A tablet you can try to boot withяПНhttp://android- --
Hello,
do you mean WPA enterprise, where the access point checks the computer / user account against a (Windows) server? If yes, i don't know if that is possible even with a standard linux, I tryed that about three years ago with special embedded Linux and WLAN enabled devices running Windows in the automotive industry, but I didn't found a way to do it. Maybe technology has advanced since my tests until today, but I don't think that Android has built in such mechnisms to login to a WLAn via a Windows domain computer account...
Stefan
Am 17.04.2012 12:28, schrieb Цветко ЛАГАЈОВИЋ:
Hi,
I tested wifi again this morning on a different network. It did work. So I think it is linked to the security used on the network it worked on WPA but not on WPA-PSK.
Cheers,
Florent.
On Monday, April 16, 2012, Цветко ЛАГАЈОВИЋ <floofy.la...@gmail.com> wrote:
> Hi,
> I got a bit further on the problem with wifi. It seems the 700t1a ships a "intel centrino 6230" wifi adapter that requires the iwlwifi kernel module.
> The options for iwlwifi were not set in kernel config, and the iwlwifi firmwares were not added to the built system. So I built a new one with Pavel's patches, I've set the IWL-related options in kernel config to build modules, and added the IWL firmwares to the release. Then, when i enabled wifi in Android settings, dmesg complained about missing firmware file "iwlwifi-6000g2b.ucode".
> This firmware file does not exist in the android-x86 source tree, so I fetched the one installed on my linux desktop. This allowed me to enable wifi and scan networks under Android. But connecting to them fails, I'll do some more testing later on.
> Hey Pavel ! Are you still reading this thread ? It's been a long time we haven't seen you around !
> Cheers,
> Florent.
>
> On Thu, Apr 12, 2012 at 8:34 PM, Цветко ЛАГАЈОВИЋ <floofy.la...@gmail.com> wrote:
>
> Hi Pavel,
>
> I see you've been changing stuff in the repo. So, what about this new directory (s7s) ? Should I now build this one or islate ?
>
> I've also seen a new tag in android-x86 repo. should I build from this one now ?
>
> Cheers,
> Florent.
>
> On Wed, Apr 4, 2012 at 10:13 AM, Цветко ЛАГАЈОВИЋ <floofy.la...@gmail.com> wrote:
>
> Hi Pavel,
> I had no time to test the patch yet, but here's what I get in logcat when I try to enable wifi:
> ...
> E/WifiStateMachine(...): Failed to load driver!
> E/WifiStateMachine(...): DriverFailedState
> ...
> Can't see anything relevant in dmesg,
> On Tue, Apr 3, 2012 at 7:04 PM, Pavel Prokofiev <integr...@gmail.com> wrote:
>
> Hi Florent,
> Thanks, I've really uploaded a single file twice.
> About patches...
> The amaxtouch patch is for enabling hid-multitouch driver to handle Atmel touchscreen device, it simply adds correspondent usb VID and PID to the driver.
> The android-x86_64 patch is a bit more complicated. Your tablet has an UEFI2 firmware which is 64bit, it requires the kernel to be booted in UEFI mode and the kernel processor architecture should match the firmware architecture. Some android-specific kernel modules are not compatible with 64bit mode, the patch workarounds this.
>
> Another way is to enable bios emulation mode in the Setup and use a 32-bit kernel configuration.
>
> So you will need to apply both patches if you want to use UEFI.
>
> What is logcat output, anything about Wifi malfunction?
> Pavel.
>
> 2012/4/3 Цветко ЛАГАЈОВИЋ <floofy.la...@gmail.com>
>
> Thanks Pavel.
> I tried that yesterday. The system at http://android-samsung700t.googlecode.com/files/android-x86_64-EFI2.zip boots up properly, touchscreen is works. But Wifi doesn't. I tried to compile the system using the files from http://code.google.com/p/android-samsung700t/, but the gui doesn't show up, and the slate reboots continuously.
> Just to be sure, do I need to apply the patches from the http://code.google.com/p/android-samsung700t/ files or not ? Do I have to build the projects in fb_test and fb_test2 ? I did a diff on the two patch files, and they are identical ?
> Cheers,
> Florent.
>
> On Mon, Apr 2, 2012 at 3:09 PM, Pavel Prokofiev <integr...@gmail.com> wrote:
>
> Hi,
> The islate device directory you have download was intended for android 3.x. Check out the sources and download section of http://code.google.com/p/android-samsung700t/. I've updated files to support 4.x.
> As I understood, there is an issue with audio support in ics (I could be wrong here), so for now I've disabled audio at all. It would be awesome If you'll find a time to investigate this.
> If you have exactly the 700T1A tablet you can try to boot with http://android- --
You received this message because you are subscribed to the Google Groups "Android-x86" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-x86...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-x86?hl=en.
--
You received this message because you are subscribed to the Google Groups "Android-x86" group.
To view this discussion on the web visit https://groups.google.com/d/msg/android-x86/-/0Uph1lSUZEoJ.
--
You received this message because you are subscribed to the Google Groups "Android-x86" group.
To view this discussion on the web visit https://groups.google.com/d/msg/android-x86/-/jKK0NNaLZgEJ.
To unsubscribe from this group, send email to android-x86+unsubscribe@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Android-x86" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-x86...@googlegroups.com.
在 2012年4月19日星期四UTC+8下午4时24分15秒,Цветко Лагајовић写道:
hi man,
did you find out how to make the wifi work on the s7s?
I hope I can the android on my s7s and I searched the whole google that nobody ever made it.
--
You received this message because you are subscribed to the Google Groups "Android-x86" group.
To view this discussion on the web visit https://groups.google.com/d/msg/android-x86/-/PhWvBUjX9MUJ.
Hello folks,As a hobby, I'm trying to run android-x86 2.3 with 64-bit linux 3.0.1
on a Samsung 700T1A. I've already done some changes in binder, ashmem
and alarm-dev, basically related to compat_ioctl.
By today, I have a quite normal boot process - the android logo, then
a home screen with widgets, but GUI doesn't respond to input devices,
nither a keyboard nor a mouse or touchscreen.
I'm sure that the system doesn't hang, cause I see widget animation
and even the battery indicator shows the actual state of an AC
adapter. I can switch to console and back with Alt-F1 and Alt-F7.
ts_calibrate works too.I know it's hard to tell something without dmesg and logcat logs, but
I can't attach them right now, sorry.
Maybe someone knows how android work with input devices and what is a
cause of the issue?Thanks,
Pavel.