New solution for resume after suspend in ICS!

[StefanS]

Dear group,

thanks to the great work and help from René van den Braken, I have found a solution for the suspend/resume issue which is simple and works for me very reliably (although sometimes the power button needs to be held a little bit longer to really wake up).
See the attached patch file for the kernel (yes, another kernel patch, and only a kernel patch).

For explanation:
This last comment made by rvdb made me think:

The last I see is a message :
 LOGD("Screen about to return, flinger = %p", flinger.get());

from DisplayHardwareBase.cpp

It just looks like the hardware is displaying the wrong framebuffer ????

So I digged into it -> I enabled the console and tried to switch back to the UI. I couldn't find it. Even with chvt from 1 to 63, I wasn't getting back to the UI. So I searched in the code which allocates a VT and I couldn't find it. But I found it in the froyo and gingerbread code.
So I concluded: ICS simply doesn't allocate a VT. At all. So the next logical thing is to look in kernel/power/suspend.c and find that it switches to a "SUSPEND_CONSOLE" VT. And then tries to switch back to the original VT, which isn't going to work if it has never been allocated. Thus, the solution is simple and consists of disabling this VT switch at suspend/resume time (I skip it when CONFIG_FB_EARLYSUSPEND is set, which is required in ICS kernel).

Then, everything falls in place: the power button is passed through to the UI, not the suspend console, and the device wakes up and stays up.

I do see some video distortion on suspend, but it's not critical and could be "fixed" by sending the DPMS off command to the screen beforehand.

Please do let me know if this works on your device(s)!

Stefan
P.S.: I see that the other option would be to disable CONFIG_VT or CONFIG_VT_CONSOLE in the kernel config, but I'm not sure what implications this may have. Since we're not targeting for running multiple VTs, but only the Android UI, it could be safe.

[Corvus]

The kernel config solution doesnt work... at least in wetab.

Corvus

>  suspend.patch
> < 1 KBVerDescargar

[rvdb]

Hi,

So finally we are getting there.
I can confirm both messages above.
The VT_CONFIG doesn't work, but
patching suspend.c does !!!!!

I can now suspend with the wetab powerkey.
Resume with this key will show the last screen, and within a few
seconds
show the lock screen.

Need some more testing, but nice work Stefan.

Greetings Rene

[Ahmet]

Yesterday,i accidentaly fixed same problem i dont know how it happened
so i will share what i did maybe it helps to people working on this.

i was set my acer w500 to debug over wifi
started coding & debugging some hello world apps
then went to developer settings
enabled force to gpu render
enabled strict mode
then resume & suspend start working
except :
on suspend all i see was frozen screen , screen was not shutting down

Thanks for your solution Stefan S :)
will try that ASAP :)

>  suspend.patch
> < 1KGörüntüleİndir

[rvdb]

On Feb 3, 11:05 am, Ahmet <yildirimco...@gmail.com> wrote:
> Yesterday,i accidentaly fixed same problem i dont know how it happened
> so i will share what i did maybe it helps to people working on this.
>
> i was set my acer w500 to debug over wifi
> started coding & debugging some hello world apps
> then went to developer settings
> enabled force to gpu render
> enabled strict mode
> then resume & suspend start working
> except :
> on suspend all i see was frozen screen , screen was not shutting down

If the screen is still shown even with a very low brightness,
the system is NOT suspended.
Something is preventing the system to go to sleep.

Greetings Rene

[Chih-Wei Huang]

Thank you for the effort to solve the big issue.

Actually I'm going to add back the vt switch feature
in ics-x86. Google took it out probably they think
android phone doesn't need that.
But we do need. It helps debugging a lot.

With that change, do you think we still need your patch?

2012/2/3 StefanS <and...@stefanseidel.info>:

--
Chih-Wei
Android-x86 project
http://www.android-x86.org

[Stefan Seidel]

Thanks, Chih-Wei.

I think that'll help, adding the vt switch back, but please make it configurable if you can. I have built a "release" version for me now, and I have disabled CONFIG_VT_CONSOLE but left CONFIG_VT on - this works great for "production" environment, because the UX is so smooth:
When Android boots, there are no messages except the text "A N D R O I D" (probably because I enabled the framebuffer console) and then the graphical Android boot logo. And when suspending, there is no ugly console switch with text, but just standby and then resume.

I'm about to release a new image soon.

Stefan
P.S.: I'm already writing this message on my Thinkpad with the Android GMail client. Quite nice :)

--
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.

[Ron M]

Nice work!!! End of "Always stay awake" ? :-)

Chih-Wei, do you think re-enabling CONFIG_VT_CONSOLE will effect any
of the following:
- Input on serial comm (I only managed to see output for some reason)
- Alt+F1/Alt+F7 - switching from/to console/GUI

[Chih-Wei Huang]

OK, vt switch is now back.

You can disable it by
system_init.startsurfaceflinger=0

2012/2/6 Stefan Seidel <pub...@stefanseidel.info>:

> Thanks, Chih-Wei.
> I think that'll help, adding the vt switch back, but please make it
> configurable if you can. I have built a "release" version for me now, and I
> have disabled CONFIG_VT_CONSOLE but left CONFIG_VT on - this works great for
> "production" environment, because the UX is so smooth:
> When Android boots, there are no messages except the text "A N D R O I D"
> (probably because I enabled the framebuffer console) and then the graphical
> Android boot logo. And when suspending, there is no ugly console switch with
> text, but just standby and then resume.

--

[Peter Gratineau]

Please.how to install this for lenovo S10-3T

--

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/-/AAfWCsB1V0oJ.

[StefanS]

On Sunday, February 5, 2012 9:26:52 AM UTC+1, Chih-Wei Huang wrote:

With that change, do you think we still need your patch?

No, if VT switch is possible then the patch is not needed. However, it is needed if you want "nice" suspend.

I have discovered, that the patch originally enabled the suspend/resume to work at all, but it still had the problem that Android often didn't really wake up (because, as Rene has discovered, the power button is not passed to Android, and even if it would, it would only go to powerbtnd).

So I applied the "other" patch (which is already in the 3.2 kernel tree) from here: https://groups.google.com/d/msg/android-x86/2ogFBowPGXk/WvXuOaXDJpQJ

Then the device would not go to sleep again, but would stay in a intermediate stage where the screen was on, the CPU running, but the UI not responding. The UI would immediately come up again when I pushed a button which I had mapped to keycode 116 (POWER). So I decided to implement this programatically in a kernel module.

The attached file contains it. It basically registers an input device "Wakup Buton" and an early_resume handler. Then, on resume, the "Wakeup Button" generates a KEY_POWER keypress which is successfully read by Android/EventHub and thus the system is signalled a power button key press, which means it wakes up.

This is working very reliably for me, but I don't know if it is needed on other devices, too.

Stefan
 

2012/2/3 StefanS

[Peter Gratineau]

Hallo there,is it possible a quick how to :installing this file please

2012/2/27 StefanS <and...@stefanseidel.info>

--

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/-/RV_xK8u9ul8J.

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.

--
Lg .Peter

[rvdb]

Hi,

I did almost the same as Stefan, but.......

I am afraid, but didn't test that the latest fix in eventhub, will
give us problems again,
as it did in Ginger.

Eventhub will filter keys if vt 7 is not "up".
In gingerbread during resume when we needed a powerkey to go to
andoid,
vt 7 was not yet up, and my key was filtered.

Need to do some testing.

Rene

On Feb 27, 3:52 pm, StefanS <andr...@stefanseidel.info> wrote:
> On Sunday, February 5, 2012 9:26:52 AM UTC+1, Chih-Wei Huang wrote:
>
> > With that change, do you think we still need your patch?
>
> No, if VT switch is possible then the patch is not needed. However, it is
> needed if you want "nice" suspend.
>
> I have discovered, that the patch originally enabled the suspend/resume to
> work at all, but it still had the problem that Android often didn't really
> wake up (because, as Rene has discovered, the power button is not passed to
> Android, and even if it would, it would only go to powerbtnd).
>
> So I applied the "other" patch (which is already in the 3.2 kernel tree)
> from here:https://groups.google.com/d/msg/android-x86/2ogFBowPGXk/WvXuOaXDJpQJ
>
> Then the device would not go to sleep again, but would stay in a
> intermediate stage where the screen was on, the CPU running, but the UI not
> responding. The UI would immediately come up again when I pushed a button
> which I had mapped to keycode 116 (POWER). So I decided to implement this
> programatically in a kernel module.
>
> The attached file contains it. It basically registers an input device
> "Wakup Buton" and an early_resume handler. Then, on resume, the "Wakeup
> Button" generates a KEY_POWER keypress which is successfully read by
> Android/EventHub and thus the system is signalled a power button key press,
> which means it wakes up.
>

> This is working *very* reliably for me, but I don't know if it is needed on

>  wakeup_button.c
> 1KViewDownload

[StefanS]

Hmm, I always run without VT switch, so that's a non-issue for me. I
think that should be the way for every "user" build i.e. builds that
are not ment for debugging.

Stefan

> --
> You received this message because you are subscribed to the Google Groups "Android-x86" group.

[StefanS]

On Monday, February 27, 2012 3:54:59 PM UTC+1, subzerolives wrote:

Hallo there,is it possible a quick how to :installing this file please

Short version: No.
Long version: you need to apply the patch to the kernel and rebuild the kernel. See also http://www.android-x86.org/getsourcecode

Stefan

2012/2/27 StefanS <and...@stefanseidel.info>

To unsubscribe from this group, send email to android-x86+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/android-x86?hl=en.

--
Lg .Peter

[Stefan]

Hello all,

would it be possible that somebody could maintain a device tree for the
Lucid platform?

rvbd and Corvus have done a nice job (amnd they still do!) in developing
all necessary changes based on the Tegav2 device gtree and even some of
their changes where going back in the generic repository of Android X86.

rvdb's sources can be found here:
https://github.com/rbraken/wetab-ICS-device-tree

But unfortunately some of their changes, for example for autorotation,
LCD backlight can not be integrated in the Tegav2 device tree as this
would prevent the original Tegav2 to function with this changes. So
currently the disadvantage is, that any time when there is a new
official release of Android X86, somebody has to implement again those
changes made by Corvus and rvbd back to the Tegav2 device tree to get a
fully working Android for the Lucid platform.

In the WeTab forum rvbd (alias xyyzzy) already claimed these days that
for him it would be too much responsibility and work to maintain an
official device tree for the WeTab and it's sisters.

My question is, if somebody else would be able to maintain it? I think
this would simplify a lot. What do you think?

Stefan

[Chih-Wei Huang]

2012/3/2 Stefan <matthaeu...@googlemail.com>:

I think the best approach is to integrate necessary changes
for wetab into tegav2 target.
The reasons are we are getting more targets.
It's troublesome to maintain very similar targets,
and it increase my work for each release cycle.
Besides, we are run out of storage of Google code
download area. I need to delete old files before
uploading new isos.

For the HAL parts, I don't think you made significant
changes that cannot be integrated together.
For example, the liblights we used now is
developed by StefanS. I remember rvdb
said it works for him in some of the replies.
For libsensors, seems wetab uses a different
input event queue. That's easy to be conquered
by getting the event name from a system property.

So my suggestion is, send me patches for wetab
so we can review what need to be changed, and
how to change that.

[Stefan]

See below

Hello Chih Wei,

all of fvbd's changes are public accessible in rvbd's github at

https://github.com/rbraken/wetab-ICS-device-tree

Would it be possible for you to integrate that completely into the Tegav2 device tree? Then rvbd could repo his changes to that device tree instead of his own little github.

Would that be Ok for you, and you, rvbd???

Stefan

[rvdb]

Stefan,

Chih-Wei knows this github, he also already changed a lot in the
tega tree, so some of our changes are not needed anymore.
I do not believe we could ask Chih-Wei for more.
He can ofcourse not keep up with all the different devices, with
different hardware.
I think he is trying to get the best for most devices, and what else
can we ask from him ?

As for the changes needed for the wetab, it is up to people who own
such a device
to make it work, and If and When they feel like it, share it with
others.
As long as the vendor of the device is not providing android, it will
always be
some extra work.
You can not expect "someone else" to do all that.

If you are not able to do it youreself (using the github sources), you
will always be dependend on people
like halver,corvus, and maybe me, to provided the extra stuff.
And remember, it's a hobby for us.
But I think a new corvus image is coming, just be patient.

As for the future, I think changes for the wetab might come as
additions to the generic tega image, just need to find a way to add a
kernel module (including depmod) to
an image :-)

Greetings RvdB

On Mar 2, 11:26 am, Stefan <matthaeus.ste...@googlemail.com> wrote:
> See below
>
> Am 02.03.2012 05:04, schrieb Chih-Wei Huang:
>
>
>
>
>
>
>
>
>

> > 2012/3/2 Stefan<matthaeus.ste...@googlemail.com>:

[Chih-Wei Huang]

2012/3/2 rvdb <rene.van....@gmail.com>:

> Stefan,
> Chih-Wei knows this github, he also already changed a lot in the
> tega tree, so some of our changes are not needed anymore.
> I do not believe we could ask Chih-Wei for more.
> He can ofcourse not keep up with all the different devices, with
> different hardware.
> I think he is trying to get the best for most devices, and what else
> can we ask from him ?

Thank you for the understanding.
Yes, I have tried to pick changes from your tree
and integrated into ics-x86 branch.
But it's likely I still miss some parts
since I don't have the device to try.
I still need your help to tell me what else
need to be changed.

So let me ask more concretely:
* What kernel changes are needed?
including kernel source and config?
* Which hals need to be changed?
So far I see libsensors needs to be
generalized to handle different input name.
Anything else?

Please send me patches to address the issues.

> As for the changes needed for the wetab, it is up to people who own
> such a device
> to make it work, and If and When they feel like it, share it with
> others.
> As long as the vendor of the device is not providing android, it will
> always be
> some extra work.
> You can not expect "someone else" to do all that.
>
> If you are not able to do it youreself (using the github sources), you
> will always be dependend on people
> like halver,corvus, and maybe me, to provided the extra stuff.
> And remember, it's a hobby for us.
> But I think a new corvus image is coming, just be patient.
>
> As for the future, I think changes for the wetab might come as
> additions to the generic tega image, just need to find a way to add a
> kernel module (including depmod) to
> an image :-)

[Corvus]

I am doing the images, so i can say you what are the things that i add
to the tegav2 device tree.

- libsensors (you know about this)
- libgps for huawei cards (is libgps in rvdb sources). Maybe this can
be added as a new generic hardware and could be build for other
devices
- libhuawei-ril (not already in rvdb sources, because is a beta by now
and i'm doing test to make it work). This is interesting because with
some changes supports too some compatible external usb 3g dongles
- some changes in vold.fstab and other files in device tree (to load
correct firmware)

About kernel modules, we have 3 that needs to be modified from default
kernel modules: btusb, ath3k and asus-laptop. This can be added as new
modules in kernel tree, simply adding it with other names, like
btusb_wetab and so on and compiled them using wetab_defconfig, but i
dont have the experience to do it.

I'm in process of a new image with your latest sources (i have to
rebuild the device tree for wetab to clean all the waste), when i
finish all the changes i will send the device tree to rvdb so he can
upload to github.

Corvus

On 2 mar, 17:38, Chih-Wei Huang <cwhu...@android-x86.org> wrote:
> 2012/3/2 rvdb <rene.van.den.bra...@gmail.com>:

[Chih-Wei Huang]

2012/3/3 Corvus <lcu...@gmail.com>:

> I am doing the images, so i can say you what are the things that i add
> to the tegav2 device tree.
> - libsensors (you know about this)
> - libgps for huawei cards (is libgps in rvdb sources). Maybe this can
> be added as a new generic hardware and could be build for other
> devices

Right. But we already have gps hal (hardware/gps).
Not sure how it differs from yours.

> - libhuawei-ril (not already in rvdb sources, because is a beta by now
> and i'm doing test to make it work). This is interesting because with
> some changes supports too some compatible external usb 3g dongles

Maybe I can just added it since tegav2 doesn't
have a real ril now.

> - some changes in vold.fstab and other files in device tree (to load
> correct firmware)

The current vold implementation is a big trouble to be generic.
I'm still seeking for a better approach.

> About kernel modules, we have 3 that needs to be modified from default
> kernel modules: btusb, ath3k and asus-laptop. This can be added as new
> modules in kernel tree, simply adding it with other names, like
> btusb_wetab and so on and compiled them using wetab_defconfig, but i
> dont have the experience to do it.

OK, I checked your btusb and ath3k.
I think it's better to re-check if these changes are
really necessary. I remember I saw some discussions
about that in lkml or fedora bugzilla.
Maybe you should ask help from the developer
of ath3k.

For asus-laptop, it's changed a lot.
I suggest you ask help from Corentin Chary, the
author of asus-laptop (also a good friend of mine),
to see how to integrated it into upstream.

> I'm in process of a new image with your latest sources (i have to
> rebuild the device tree for wetab to clean all the waste), when i
> finish all the changes i will send the device tree to rvdb so he can
> upload to github.

[rvdb]

On Mar 4, 10:42 am, Chih-Wei Huang <cwhu...@android-x86.org> wrote:
> OK, I checked your btusb and ath3k.
> I think it's better to re-check if these changes are
> really necessary. I remember I saw some discussions
> about that in lkml or fedora bugzilla.
> Maybe you should ask help from the developer
> of ath3k.

The problem with the two modules are that the wetab
used different usb-ids when coldbooted (no firmware loaded id = 3000)
and warmbooted (after loading firmware id = 3002).
BUT different hardware from this manifacture uses pci-id's in an
inconsistant
way.
There seems to be a device that reports id 3002 when the firmware is
not loaded !
(N.B without firmware ath3k should take control, with firmware btusb)


Looking at the history of these modules you see that some patches are
submitted
to changes id's for different hardware, to solve one problem, but then
it breaks
some other hardware, so some months later the patches are reversed.

At this stage the normal modules (ath3k and btusb) asmune 3002 is
without firmware.
That is wrong for our hardware.

After reading more, there might be another solution. There seems to be
some
(patched??) firmware that changes the id to 3005. If that is the case,
both hardware id=3000 and id=3002 would switch to id 3005.
Then we would not need patches kernel modules, only another
ath3k-2.fw.
I will try to find that, unless somebody already has this.

[rvdb]

Oke, some more test, the firmware in the latest android-x86 tree, will
switch to id=3005 !!!!
But: the name is ath3k-1.fw, and the ath3k.ko wants ath3k-2.fw.
After renaming this it is working.
Unfortunatly it is not as great as I would like.

Because wetabOS is still using other firmware that switches to 3002,
after a warm reboot
from WetabOS to Android, the id is still 3002, so btusb will not use
it.

My patches in ath3k and btusb will work in all cases, but only perfect
on the wetab.

dillema's :-(

[Stefan]

Hello,to get

has anybody already tryed to get a WeTab 32G sample for Chih-Wei from
4tito (42) ? I think this would make things much easier.

Stefan

[StefanS]

On Sun, Mar 4, 2012 at 14:56, Stefan <matthaeu...@googlemail.com> wrote:
>
> has anybody already tryed to get a WeTab 32G sample for Chih-Wei from 4tito
> (42) ? I think this would make things much easier.

Funny, that's what I thought from the beginning: just find someone
with time and expertise and send him a device. That'll solve all your
problems :) (almost)

StefanS

> --
> 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.

[Stefan Matthäus]

Hello Chih-Wei, Corvus, Rene (rvbd) and StefanS and other WeTab/ExoPC
interested,

did somebody tryed to request a sample of WeTab 3G at 4tito for
Chih-Wei, or not?

Should I try to contact 4tito ask them if they can provide a sample to
Chih-Wei? As I remember I have read somewhere (here or WeTab community
forum), also 4tito is interested to run ICS on the WeTab, so asking them
for the (sponsored) sample would be easy as it is expected that they
would like to cooperate. What do you think?

Stefan

[rvdb]

Stefan (and Chih-Wei),

As I told earlier, my solution, sending a power-key from powerbtn.c
to let android know we are awake, doesn't work.
It is too early, and gets filtered in EventHub.
" if (vs.v_active != android_vt) "

But the solution from Stefan is working, probably because it is send a
bit later.
So I stole this now, to use in wetab tree

Thanks.

On Feb 27, 3:52 pm, StefanS <andr...@stefanseidel.info> wrote:

> On Sunday, February 5, 2012 9:26:52 AM UTC+1, Chih-Wei Huang wrote:
>
> > With that change, do you think we still need your patch?
>
> No, if VT switch is possible then the patch is not needed. However, it is
> needed if you want "nice" suspend.
>
> I have discovered, that the patch originally enabled the suspend/resume to
> work at all, but it still had the problem that Android often didn't really
> wake up (because, as Rene has discovered, the power button is not passed to
> Android, and even if it would, it would only go to powerbtnd).
>
> So I applied the "other" patch (which is already in the 3.2 kernel tree)
> from here:https://groups.google.com/d/msg/android-x86/2ogFBowPGXk/WvXuOaXDJpQJ
>
> Then the device would not go to sleep again, but would stay in a
> intermediate stage where the screen was on, the CPU running, but the UI not
> responding. The UI would immediately come up again when I pushed a button
> which I had mapped to keycode 116 (POWER). So I decided to implement this
> programatically in a kernel module.
>
> The attached file contains it. It basically registers an input device
> "Wakup Buton" and an early_resume handler. Then, on resume, the "Wakeup
> Button" generates a KEY_POWER keypress which is successfully read by
> Android/EventHub and thus the system is signalled a power button key press,
> which means it wakes up.
>

> This is working *very* reliably for me, but I don't know if it is needed on

>  wakeup_button.c
> 1KViewDownload

[StefanS]

On Thu, Mar 8, 2012 at 16:36, rvdb <rene.van....@gmail.com> wrote:
> Stefan (and Chih-Wei),
>
> As I told earlier, my solution, sending a power-key from powerbtn.c
> to let android know we are awake, doesn't work.
> It is too early, and gets filtered in EventHub.
> " if (vs.v_active != android_vt) "
>
> But the solution from Stefan is working, probably because it is send a
> bit later.
> So I stole this now, to use in wetab tree

It's GPL, no stealing possible ;)

But anyway, yes because my kernel module uses late_resume, it can send
the button keypress after the "screen is on" event from Android, at
which point the UI is already up and running again.
So I'm glad it works for you, too!

Stefan

[G Born]

According to Stefan Matthäus and StefanS suggestions:

To prevent further queries to 4tiitoo (the German vendor of WeTab) - I
contacted 4tiitoo today and got the feedback, that Chih-Wei Huang
already received a WeTab tablet pc for developing/testing since march
2012 - hope that is true.

BTW: Thx for the work on this project (I just mentioned it here
http://bit.ly/I1swIk)

Günter Born


On 6 Mrz., 10:04, Stefan Matthäus <matthaeus.ste...@googlemail.com>
wrote:
> Hello Chih-Wei,Corvus, Rene (rvbd) and StefanS and otherWeTab/ExoPC
> interested,
>
> did somebody tryed to request a sample ofWeTab3G at 4tito for

> Chih-Wei, or not?
>
> Should I try to contact 4tito ask them if they can provide a sample to
> Chih-Wei? As I remember I have read somewhere (here orWeTabcommunity

> forum), also 4tito is interested to run ICS on theWeTab, so asking them

> for the (sponsored) sample would be easy as it is expected that they
> would like to cooperate. What do you think?
>
> Stefan
>
> Am 04.03.2012 23:53, schrieb StefanS:
>
>
>
>
>
>
>

> > On Sun, Mar 4, 2012 at 14:56, Stefan<matthaeus.ste...@googlemail.com>  wrote:
> >> has anybody already tryed to get aWeTab32G sample for Chih-Wei from 4tito

> >> (42) ? I think this would make things much easier.
> > Funny, that's what I thought from the beginning: just find someone
> > with time and expertise and send him a device. That'll solve all your
> > problems :) (almost)
>
> > StefanS
>
> >> Am 04.03.2012 10:42, schrieb Chih-Wei Huang:
>

> >>> 2012/3/3Corvus<lcue...@gmail.com>:

> >>>> rebuild the device tree forwetabto clean all the waste), when i

[Stefan]

Hello,

yes this is true.

Stefan

Am 25.04.2012 18:39, schrieb G Born:
> According to Stefan Matth�us and StefanS suggestions:

[Holger Pandel]

Sadly, the resume doesn't work anymore. With a fresh build the WeTab comes back to VT. I tried to comment out CONFIG_VT_CONSOLE in the kernel config, but that had no effect.

> To unsubscribe from this group, send email to android-x86+unsubscribe@googlegroups.com.