Re: [Debian] 2.6.34 Openmoko kernel package available
On 17 December 2010 10:10, Al Johnson openm...@mazikeen.demon.co.uk wrote: On Friday 17 December 2010, Timo Jyrinki wrote: Anyway, if one can come up with a perfect xorg.conf that disables the extra devices there and only configures glamo + touch input + hw buttons, that'd be nice. What about the SHR xorg.conf? SHR is also using 2.6.34, so is there any reason why their xorg.conf - or at least the InputDevice and AutoAddDevices parts - would not be correct for Debian with 2.6.34? I've appended it below. Neil Section Module Loadglx Loaddri2 EndSection Section Monitor Identifier LCD Panel EndSection Section Device Identifier Glamo Graphics Chip Driver glamo EndSection Section Screen Identifier Default Screen Device Glamo Graphics Chip Monitor LCD Panel EndSection Section InputDevice Identifier Power Button Driver evdev Option Device/dev/input/event0 EndSection Section InputDevice Identifier AUX Button Driver evdev Option Device/dev/input/event2 EndSection Section InputDevice Identifier Touchscreen Driver tslib Option Device/dev/input/event1 Option EmulateRightButtonTrue EndSection Section ServerFlags Option AutoAddDevices False EndSection Section ServerLayout Identifier Default Layout Screen Default Screen InputDevice Power Button InputDevice AUX Button InputDevice Touchscreen EndSection ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Debian] 2.6.34 Openmoko kernel package available
2010/12/16 Neil Jerram neiljer...@gmail.com: Even after removing the /dev/input files as you suggested (in /etc/rc.local), my observation is that XOrg still eats all CPU after an initial boot-up, but that if I then do /etc/init.d/nodm stop and /etc/init.d/nodm start, it returns to using a normal (small) amount of CPU. Is that as you would expect? That doesn't happen to me, but it's probably related to starting X in parallel with rc.local, so X gets to probe those before they are removed? Anyway, if one can come up with a perfect xorg.conf that disables the extra devices there and only configures glamo + touch input + hw buttons, that'd be nice. I noticed that wifi is powered on after boot-up. Is that expected? Note that I am not currently running frameworkd or other FSO daemons - so perhaps this is normal, and I haven't seen it before because the FSO daemons turn wifi OFF when they start up. (Alternatively, could wicd be powering on the wifi?) If I recall correctly that was always so in the old kernels as well, so even though it makes not much sense it may be so also now. But I'm using FSO so possibly it shuts the power off when starting (although, on the other hand, I wouldn't expect the FSO1 to know the sys paths in 2.6.34). For me, iwconfig shows the device but om wifi power confirms that it's not really powered up (and iwconfig says Tx-Power=off). I guess the interface is always there as ar6000 support is compiled into the kernel? -Timo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Debian] 2.6.34 Openmoko kernel package available
On Friday 17 December 2010, Timo Jyrinki wrote: 2010/12/16 Neil Jerram neiljer...@gmail.com: Even after removing the /dev/input files as you suggested (in /etc/rc.local), my observation is that XOrg still eats all CPU after an initial boot-up, but that if I then do /etc/init.d/nodm stop and /etc/init.d/nodm start, it returns to using a normal (small) amount of CPU. Is that as you would expect? That doesn't happen to me, but it's probably related to starting X in parallel with rc.local, so X gets to probe those before they are removed? Anyway, if one can come up with a perfect xorg.conf that disables the extra devices there and only configures glamo + touch input + hw buttons, that'd be nice. What about USB and Bluetooth input devices? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Debian] 2.6.34 Openmoko kernel package available
On 16 December 2010 06:53, Timo Jyrinki timo.jyri...@gmail.com wrote: 2010/11/14 Timo Jyrinki timo.jyri...@gmail.com: http://git.debian.org/?p=pkg-fso/linux-2.6-openmoko.git;a=shortlog;h=refs/heads/debian-2.6.34 New Debian pkg-fso kernel available: And another one thanks to having inspirational time yesterday evening. Thanks. I am using this series of kernels, so I appreciate your work on them. - X.Org eats all the CPU unless you disable AutoAddDevices or remove extra /dev/input files Even after removing the /dev/input files as you suggested (in /etc/rc.local), my observation is that XOrg still eats all CPU after an initial boot-up, but that if I then do /etc/init.d/nodm stop and /etc/init.d/nodm start, it returns to using a normal (small) amount of CPU. Is that as you would expect? - Sys paths have changed, so you most probably want to add om gsm power 1 to /etc/rc.local (and install newest omhacks from pkg-fso if you already haven't) I noticed that wifi is powered on after boot-up. Is that expected? Note that I am not currently running frameworkd or other FSO daemons - so perhaps this is normal, and I haven't seen it before because the FSO daemons turn wifi OFF when they start up. (Alternatively, could wicd be powering on the wifi?) Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Debian] 2.6.34 Openmoko kernel package available
2010/11/14 Timo Jyrinki timo.jyri...@gmail.com: http://git.debian.org/?p=pkg-fso/linux-2.6-openmoko.git;a=shortlog;h=refs/heads/debian-2.6.34 New Debian pkg-fso kernel available: And another one thanks to having inspirational time yesterday evening. Note that the original three 2.6.34 related caveats are still there: - No updated fso-config-gta02 yet in Debian, therefore you need to manually fix ALSA state files, see for example http://iki.fi/tjyrinki/moko/2.6.34/ - X.Org eats all the CPU unless you disable AutoAddDevices or remove extra /dev/input files - Sys paths have changed, so you most probably want to add om gsm power 1 to /etc/rc.local (and install newest omhacks from pkg-fso if you already haven't) --- http://pkg-fso.nomeata.de/sid/linux-image-2.6.34-openmoko-gta02 http://git.debian.org/?p=pkg-fso/linux-2.6-openmoko.git;a=shortlog;h=refs/heads/debian-qtmoko-v31 linux-2.6-openmoko (20101212.git049b71de-1) pkg-fso; urgency=low * Merge from qtmoko-v31 - Kernel 2.6.34.7 - Integrated GPS suspend patch, resume reason patch - Dumb battery support * Disable sysrq, unneeded * Add configuration from wishlists: - NFSv4 - XATTR for EXT* - CONFIG_TASK_DELAY_ACCT, CONFIG_TASK_IO_ACCOUNTING - CONFIG_OPENMOKO_RESUME_REASON * Remove 2.6.29 era patches and others that don't apply anymore -- Timo Jyrinki t...@debian.org Wed, 15 Dec 2010 19:32:13 +0200 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Debian] 2.6.34 Openmoko kernel package available
2010/10/18 Timo Jyrinki timo.jyri...@gmail.com: [1] http://pkg-fso.nomeata.de/sid/linux-image-2.6.34-openmoko-gta02 [3] http://git.debian.org/?p=pkg-fso/linux-2.6-openmoko.git;a=shortlog;h=refs/heads/debian-2.6.34 New Debian pkg-fso kernel available: linux-2.6-openmoko (20101108.git1508bbb5-1) pkg-fso; urgency=low * Merge from qtmoko-v29 - CONFIG_HZ=100 - Jitterless touch support - UbiFS support * As per request, enabled CONFIG_PROC_EVENTS and CONFIG_TASKSTATS * Add GPS suspend handling patch from Gennady Kupava - Needs also qi or fixed u-boot * Add also disabled patches which were missing from git * From lindi's patches: - Magic sysrq key enabled - Make PTRACE_SINGLESTEP work with user helpers - Do not print debug messages on every touchscreen event - Resume reason patch included, but disabled since fails to build -- Timo Jyrinki t...@debian.org Sat, 13 Nov 2010 15:53:24 +0200 Enjoy. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[Debian] 2.6.34 Openmoko kernel package available
Hi,
During the weekend I did a few cross-builds, emulated native builds
and finally native builds of the 2.6.34 Openmoko kernel for Debian.
It's now available at the pkg-fso repository [1]. It's basically
identical in code and configuration to Radek's qtmoko-v27 git branch
[2], with the added compilation of LED/vibration support. Debian
packaging [3] is virtually the same as with 2.6.29, only minimal
needed changes to bring it to 2.6.34 time. Huge thanks to Radek of
QtMoko fame and SHR people for dwelling through the git trees and
patching up on top of the git.openmoko.org trees to create an usable
kernel.
[1] http://pkg-fso.nomeata.de/sid/linux-image-2.6.34-openmoko-gta02
[2] http://github.com/radekp/linux-2.6/tree/qtmoko-v27
[3]
http://git.debian.org/?p=pkg-fso/linux-2.6-openmoko.git;a=shortlog;h=refs/heads/debian-2.6.34
I think the 2.6.34 is a great step forwards, although with a few
caveats for existing Debian w/ 2.6.29 users:
- ALSA switches have changed names. You need to update your state
files manually for now. Some reference can be found at
http://users.tkk.fi/~tajyrink/moko/2.6.34/ for a) phone calls and b)
so that also alerts are heard. I also hacked the headphones out
profile but didn't put it there. Those are probably not optimal, but
work. Updated state files should of course started to be offered by
us, Debian's FSO team.
- Many SYS paths have changed. I've om gsm power 1 in /etc/rc.local
as one easy workaround for GSM functionality, and I have also been
using the om tool (from omhacks) also otherwise. Newest omhacks is in
pkg-fso repository, and yet more 2.6.34 fixes for it coming reportedly
soon from lindi co. Most programs probably also don't know anymore
how to control the vibrator, since its path has also changed.
- X.org auto-configuration is in troubles compared to 2.6.29 kernel
(where at least I used xorg.conf with only glamo driver section). I
didn't have time to look at it, so I've just rm /dev/input/event{3,4}
/dev/input/js{0,1} /dev/input/mouse0 in /etc/rc.local for now...
But with those caveats / upgrade problems everything seems to work:
GSM, GPS, Bluetooth, WLAN, LEDs, suspend/resume, and reportedly also
power consumption under suspend is ok...
Note that of course this is not the correct way to do the kernel in
the long term, but I was just willing to spend some of my limited free
time on offering this 2.6.34 branch to the Debian users. What is
really needed to be done (yet again re-iterated) is upstreaming the
rest of the code needed by FreeRunner [4] and helping official s3c24xx
support in the Debian installer / kernel [5]. It is however noticeable
how huge improvement this is over the old 2.6.29 branch. The 2.6.29
kernel was based on _rc3_ of Linus' 2.6.29. There was a rc8 before the
stable 2.6.29 release and six stable updates. After the rc3 however
the git.openmoko.org:s andy-tracking tree was patched over the
following 1.5 years without merges from the stable tree. Compared to
that, with the current 2.6.34 tree [6] we're able to see stable/final
2.6.34 commit by Torvalds already on the second page of the commit
log.
[4]
http://lists.openmoko.org/pipermail/openmoko-kernel/2010-September/011205.html
[5] http://git.debian.org/?p=pkg-fso/kernel.git;a=shortlog;h=refs/heads/s3c24xx
[6]
http://git.debian.org/?p=pkg-fso/linux-2.6-openmoko.git;a=shortlog;h=refs/heads/debian-2.6.34
As a final note, Radek didn't yet include Glamo KMS/DRM support in the
2.6.34 (I think a bit more KMS/DRM problems have been seen with 2.6.34
than 2.6.32), and I didn't start doing it either. Naturally that's the
biggest omission we now don't yet have regarding the work done on
FreeRunner kernels during last and this year. The KMS support is
available in Thomas' branch [7] and SHR's patches [8] - I don't know
what's the delta between them.
[7] http://git.bitwiz.org.uk/?p=kernel.git;a=shortlog;h=refs/heads/gdrm-2.6.34
[8]
http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/linux/linux-openmoko-2.6.34
-Timo
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [Debian] 2.6.34 Openmoko kernel package available
On Mon, Oct 18, 2010 at 10:53:24AM +0300, Timo Jyrinki wrote: As a final note, Radek didn't yet include Glamo KMS/DRM support in the 2.6.34 (I think a bit more KMS/DRM problems have been seen with 2.6.34 than 2.6.32), and I didn't start doing it either. Naturally that's the biggest omission we now don't yet have regarding the work done on FreeRunner kernels during last and this year. The KMS support is available in Thomas' branch [7] and SHR's patches [8] - I don't know what's the delta between them. [7] http://git.bitwiz.org.uk/?p=kernel.git;a=shortlog;h=refs/heads/gdrm-2.6.34 [8] http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/linux/linux-openmoko-2.6.34 Hi, delta is mostly because this commit http://git.openmoko.org/?p=kernel.git;a=commit;h=a1a29d40be0ebe43bd26b0c5647e1273b45e9f00 and SHR kernel is rebased on top of om-gta02-2.6.34, so I've updated and moved KMS/DRM patches and gta02-drm-defconfig to apply on top of it. For easier git diff you can use this git repo http://gitorious.org/~jama/htc-msm-2-6-32/openmoko-kernel/commits/om-gta02-2.6.34 I always push SHR patches there before adding those to OE tree [8]. Regards, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Debian] 2.6.34 Openmoko kernel package available
Hi Timo,
On Mon, Oct 18, 2010 at 10:53:24AM +0300, Timo Jyrinki wrote:
Hi,
During the weekend I did a few cross-builds, emulated native builds
and finally native builds of the 2.6.34 Openmoko kernel for Debian.
It's now available at the pkg-fso repository [1]. It's basically
identical in code and configuration to Radek's qtmoko-v27 git branch
[2], with the added compilation of LED/vibration support. Debian
packaging [3] is virtually the same as with 2.6.29, only minimal
needed changes to bring it to 2.6.34 time. Huge thanks to Radek of
QtMoko fame and SHR people for dwelling through the git trees and
patching up on top of the git.openmoko.org trees to create an usable
kernel.
[1] http://pkg-fso.nomeata.de/sid/linux-image-2.6.34-openmoko-gta02
[2] http://github.com/radekp/linux-2.6/tree/qtmoko-v27
[3]
http://git.debian.org/?p=pkg-fso/linux-2.6-openmoko.git;a=shortlog;h=refs/heads/debian-2.6.34
I think the 2.6.34 is a great step forwards, although with a few
caveats for existing Debian w/ 2.6.29 users:
- ALSA switches have changed names. You need to update your state
files manually for now. Some reference can be found at
http://users.tkk.fi/~tajyrink/moko/2.6.34/ for a) phone calls and b)
so that also alerts are heard. I also hacked the headphones out
profile but didn't put it there. Those are probably not optimal, but
work. Updated state files should of course started to be offered by
us, Debian's FSO team.
- Many SYS paths have changed. I've om gsm power 1 in /etc/rc.local
as one easy workaround for GSM functionality, and I have also been
using the om tool (from omhacks) also otherwise. Newest omhacks is in
pkg-fso repository, and yet more 2.6.34 fixes for it coming reportedly
soon from lindi co. Most programs probably also don't know anymore
how to control the vibrator, since its path has also changed.
- X.org auto-configuration is in troubles compared to 2.6.29 kernel
(where at least I used xorg.conf with only glamo driver section). I
didn't have time to look at it, so I've just rm /dev/input/event{3,4}
/dev/input/js{0,1} /dev/input/mouse0 in /etc/rc.local for now...
But with those caveats / upgrade problems everything seems to work:
GSM, GPS, Bluetooth, WLAN, LEDs, suspend/resume, and reportedly also
power consumption under suspend is ok...
Note that of course this is not the correct way to do the kernel in
the long term, but I was just willing to spend some of my limited free
time on offering this 2.6.34 branch to the Debian users. What is
really needed to be done (yet again re-iterated) is upstreaming the
rest of the code needed by FreeRunner [4] and helping official s3c24xx
support in the Debian installer / kernel [5]. It is however noticeable
how huge improvement this is over the old 2.6.29 branch. The 2.6.29
kernel was based on _rc3_ of Linus' 2.6.29. There was a rc8 before the
stable 2.6.29 release and six stable updates. After the rc3 however
the git.openmoko.org:s andy-tracking tree was patched over the
following 1.5 years without merges from the stable tree. Compared to
that, with the current 2.6.34 tree [6] we're able to see stable/final
2.6.34 commit by Torvalds already on the second page of the commit
log.
[4]
http://lists.openmoko.org/pipermail/openmoko-kernel/2010-September/011205.html
[5]
http://git.debian.org/?p=pkg-fso/kernel.git;a=shortlog;h=refs/heads/s3c24xx
[6]
http://git.debian.org/?p=pkg-fso/linux-2.6-openmoko.git;a=shortlog;h=refs/heads/debian-2.6.34
As a final note, Radek didn't yet include Glamo KMS/DRM support in the
2.6.34 (I think a bit more KMS/DRM problems have been seen with 2.6.34
than 2.6.32), and I didn't start doing it either. Naturally that's the
biggest omission we now don't yet have regarding the work done on
FreeRunner kernels during last and this year. The KMS support is
available in Thomas' branch [7] and SHR's patches [8] - I don't know
what's the delta between them.
[7] http://git.bitwiz.org.uk/?p=kernel.git;a=shortlog;h=refs/heads/gdrm-2.6.34
[8]
http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/linux/linux-openmoko-2.6.34
-Timo
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
thanks for the package.
to ssh in the device i must add 'g_ether' in /etc/modules.
you should builtin this module in kernel.
and now ... let me test all the features. ;)
frank
--
sent with 100% wireless electrons
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [Debian] 2.6.34 Openmoko kernel package available
thanks for the package. to ssh in the device i must add 'g_ether' in /etc/modules. you should builtin this module in kernel. That's fine for you, but not for anyone who wants to use one of the other gadget modules. If you need it autoloading then autoload it as you are doing now. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
