Salut, > > The good things: > > > > * keyboard, keys, buttons, switches, touchscreen works fine (no > > multitouch though) > > you get all the keyboard keys ? / tab etc ?
Yes, at least from an input device level node, i'm not using X, so I don't know whether the xmodmap is correct. > > > * leds, backlight, power supply reporting works fine > > * telephony works fine (htc_qualcomm_dream plugin) > > * UMTS data connectivity works fine (pdp_qmi plugin) > > Can gprs and phone be used in 2G ? where can it be choose ? (in android, I > have > seen that 3G can be enable or diseable). GPRS (or EDGE) can be used fine, both works, even in parallel. As for chosing, a canonical approach is to use the proper +COPS call, there you can choose as last parameter which access technology you want. I'm not 100% sure whether there is any other means to "forbid" 3G networks. > > echo "on" >/proc/power/state resumes it. > > A very stupid question : how can I do this if the phone is suspended ? This is all due to a misunderstanding. Previously, we thought there is no halting of the main CPU at all (so no "real" suspend), but just downclocking, which would mean you are still logged in and can "resume" everytime. The truth is, obviously in our 2.6.32 for some reason that is unknown, we don't get the "freezing tasks... CPU halted" messages, which probably means the earlysuspend (android invention :/) or the wakelocks (android invention :/) are giving us problems / aborting the suspend / whatever. This needs someone comparing with how it works under Android and checking whether we did anything wrong when we uplevelled the kernel to 2.6.32. As far as I know it never worked in "our" kernel (linux-leviathan). > > I need to take this back, apparantly suspend/resume is completely broken > > in our kernel, what we see is only sleep mode, i.e. automatic CPUfreq on > > demand. With this we get 7h of runtime, which is ok, but out of question > > for day 2 day use. > > echo mem > /sys/power/state is in fact a cpufreq ? Have I well understood ? No, I did wrongly explain. It's just broken in our kernel, echo mem > /sys/power/state will "look" like it succeeds, but in reality it doesn't. It only blanks the display and disables the input nodes, but it doesn't suspend. (The cpufreq on-demand is working all the time without manual intervention, that's quite good...) > > > Someone needs to look into why suspend/resume is broken in our 2.6.32 -- > > again, kernel experts necessary. > > With which kernel was suspend working ? Unfortunately only the android one :/ So someone has to look into the suspend/resume path and compare to android. Cheers, -- :M: _______________________________________________ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
