J.Manrique Lopez | 6 Apr 2005 18:15
Picon
Picon
Favicon

For Java users: Jarnal

Hello,

For those brave people using some Java in their linux
pda, I would suggest testing this app:
http://www.dklevine.com/general/software/tc1000/jarnal.htm

I think that it is one of the most promising apps I've
seen for touchscreen devices. Ok, it uses Java, but it
has some nice features I like a lot. Take a look into
it.

Thanks and best regards,

J.Manrique Lopez de la Fuente http://www.asturlinux.org/~jsmanrique
Jabber: jsmanrique <at> jabber.org || ICQ: 167 680 362
1077 HPCC Member http://www.hpcc.org
AsturLiNUX & HispaLiNUX Member

		
______________________________________________ 
Renovamos el Correo Yahoo!: ¡250 MB GRATIS! 
Nuevos servicios, más seguridad 
http://correo.yahoo.es
_______________________________________________
The Familiar Linux Distribution
Familiar mailing list
Familiar <at> handhelds.org
https://handhelds.org/mailman/listinfo/familiar
irc://irc.freenode.net #familiar

(Continue reading)

Paul Eggleton | 14 Apr 2005 14:59

Familiar 0.8.2 released

Hello all,

It gives us great pleasure to announce the the newest release of the Familiar 
Linux distribution for handheld devices, version 0.8.2.

Familiar now officially supports the HP Jornada 720 and 56x PDAs, in addition 
to the previously supported Compaq/HP iPAQ and Sharp Zaurus model handhelds. 
Also, many bugs have been fixed since the previous release. Check out the 
change log [1] for full details.

Installation and download information for Familiar 0.8.2 can be found here:

   http://familiar.handhelds.org/releases/v0.8.2/install/
   http://familiar.handhelds.org/releases/v0.8.2/install/files/   
     (for images/files other than those accessible via the download page)

As always, please check the release notes [2] for any known issues. Please 
report any other problems to the Familiar mailing list 
(familiar <at> handhelds.org) or use the bug tracker [3].

The Familiar release team would like to thank (in no particular order):

 * The OpenEmbedded team
 * The Opie and GPE teams
 * The OpenZaurus people
 * The handhelds.org kernel hackers
 * All package developers
 * Pre-release testers and bug-reporters
 * People who helped out on the wiki, mailing lists and IRC

(Continue reading)

Richard Purdie | 16 Apr 2005 19:38

2.6 kernel with gpe-image on c7x0 issues summary

Its known there are issues with the 2.6 kernel and gpe-image on the c7x0. I 
thought it may help if I summarised them (see below). It appears there are 
only a small number of problems but they are serious in nature.

Blocking issues:

1. For reasons unknown, the postinst isn't being run at least for pango, 
pango-modules-*, gdk-pixbuf-loader-*. This stops X from loading upon first 
boot making the machine inaccessible as the X init scripts just loop.
2. Upon a suspend/resume esd hangs (unkillable, locked up). There has been a 
report of opie's sound daemon hanging upon suspend/resume but only by one 
person and it works fine for me and others. It could be some kind of kernel 
sound driver race. I worked around this by renaming esd so it never loads. I 
could then see that:
3. Upon a suspend/resume the xserver segfaults unless you switch to a 
different virtual console before suspending/resuming.

The good news is that if I work around the above as described, gpe seems 
stable. (This is a openzaurus-3.5.3 build).

I also noticed a 2.6 kernel specific issue in that the backlight control is 
broken (unsurprisingly really). gpe should probably learn about the 2.6 
kernel backlight class.

Thoughts and suggestions welcome as I don't know gpe well (although I'd like 
to learn to use it). I will try and look into some of the issues but I'm not 
sure how far I'll get.

Cheers,

(Continue reading)

Koen Kooi | 16 Apr 2005 19:49
Picon
Picon

Re: 2.6 kernel with gpe-image on c7x0 issues summary

Richard Purdie wrote:
> Its known there are issues with the 2.6 kernel and gpe-image on the 
> c7x0. I thought it may help if I summarised them (see below). It appears 
> there are only a small number of problems but they are serious in nature.
> 
> Blocking issues:
> 
> 1. For reasons unknown, the postinst isn't being run at least for pango, 
> pango-modules-*, gdk-pixbuf-loader-*. This stops X from loading upon 
> first boot making the machine inaccessible as the X init scripts just loop.
With the image I baked they do get run, although it seems it's a bit of 
a gamble.

> 2. Upon a suspend/resume esd hangs (unkillable, locked up). There has 
> been a report of opie's sound daemon hanging upon suspend/resume but 
> only by one person and it works fine for me and others. It could be some 
> kind of kernel sound driver race. I worked around this by renaming esd 
> so it never loads. I could then see that:
> 3. Upon a suspend/resume the xserver segfaults unless you switch to a 
> different virtual console before suspending/resuming.
same here:(

> 
> The good news is that if I work around the above as described, gpe seems 
> stable. (This is a openzaurus-3.5.3 build).
> 
> I also noticed a 2.6 kernel specific issue in that the backlight control 
> is broken (unsurprisingly really). gpe should probably learn about the 
> 2.6 kernel backlight class.
Minilite (the panel backlight app) knows about 2.6 backlight, but 
(Continue reading)

Phil Blundell | 17 Apr 2005 09:55
Favicon

Re: [Gpe] 2.6 kernel with gpe-image on c7x0 issues summary

On Sat, 2005-04-16 at 18:38 +0100, Richard Purdie wrote:
> 2. Upon a suspend/resume esd hangs (unkillable, locked up). There has been a 
> report of opie's sound daemon hanging upon suspend/resume but only by one 
> person and it works fine for me and others. It could be some kind of kernel 
> sound driver race. I worked around this by renaming esd so it never loads. I 
> could then see that:

If it's unkillable, this has to be a kernel bug of some kind.  Does this
affect any process that holds /dev/dsp open, or just esd specifically?
Can you capture a strace transcript of esd across suspend/resume?  Where
does the WCHAN value point to when it gets stuck?

> 3. Upon a suspend/resume the xserver segfaults unless you switch to a 
> different virtual console before suspending/resuming.

Can you capture a backtrace from gdb or catchsegv when this happens?

p.
Richard Purdie | 18 Apr 2005 23:43

Re: [Gpe] 2.6 kernel with gpe-image on c7x0 issues summary

I've done some work on these issues:

[gpe-image + 2.6 kernel blocking issues]
> 1. For reasons unknown, the postinst isn't being run at least for pango, 
> pango-modules-*, gdk-pixbuf-loader-*. This stops X from loading upon first 
> boot making the machine inaccessible as the X init scripts just loop.

This is due to a number of the postinst files in packages gpe uses being 
incorrect. Specifically:

gdk-pixbuf-loader-xpm
gdk-pixbuf-loader-jpeg
gdk-pixbuf-loader-png
pango-module-basic-fc
pango-module-basic-x
ttf-bitstream-vera (maybe?)

all probably need something like this added to the beginning:
if [ "x$D" != "x" ]; then
  exit 1
fi

Could someone with knowledge in this area fix these please?

> 2. Upon a suspend/resume esd hangs (unkillable, locked up). There has been 
> a report of opie's sound daemon hanging upon suspend/resume but only by 
> one person and it works fine for me and others. It could be some kind of 
> kernel sound driver race. I worked around this by renaming esd so it never 
> loads. I could then see that:

(Continue reading)

Phil Blundell | 19 Apr 2005 02:07
Favicon

Re: [Gpe] 2.6 kernel with gpe-image on c7x0 issues summary

On Mon, 2005-04-18 at 22:43 +0100, Richard Purdie wrote:
> This is due to a number of the postinst files in packages gpe uses being 
> incorrect. Specifically:
> 
> gdk-pixbuf-loader-xpm
> gdk-pixbuf-loader-jpeg
> gdk-pixbuf-loader-png
> pango-module-basic-fc
> pango-module-basic-x
> ttf-bitstream-vera (maybe?)
> 
> all probably need something like this added to the beginning:
> if [ "x$D" != "x" ]; then
>   exit 1
> fi
> 
> Could someone with knowledge in this area fix these please?

This is a strange problem.  Although you're right that these postinsts
could usefully have that kind of construct added, it ought not to make
any real difference in practice since they will certainly fail if
executed at build time.  (Unless you're building as root, or something,
but presumably you are not doing that.)  So, it's a little bit of a
mystery why this would make a difference.  Did you confirm that the
packages were definitely getting marked as fully configured in the
status file?

I'll make the change, anyway.

p.
(Continue reading)

Phil Blundell | 19 Apr 2005 03:57
Favicon

Re: [Gpe] 2.6 kernel with gpe-image on c7x0 issues summary

On Mon, 2005-04-18 at 22:43 +0100, Richard Purdie wrote:
> gdk-pixbuf-loader-xpm
> gdk-pixbuf-loader-jpeg
> gdk-pixbuf-loader-png
> pango-module-basic-fc
> pango-module-basic-x

I checked in a patch that should fix these ones.

> Can someone tell me where [minilite] "detects a corgi" as it really needs to detect 
> a corgi running 2.4.

It looks for /proc/driver/fl/corgi-bl.  Koen, are you saying that this
file exists on 2.6 but doesn't have any useful effect?  If so, I guess
this is a kernel bug.

p.
Richard Purdie | 19 Apr 2005 10:09

Re: [Gpe] 2.6 kernel with gpe-image on c7x0 issues summary

Phil Blundell:
> This is a strange problem.  Although you're right that these postinsts
> could usefully have that kind of construct added, it ought not to make
> any real difference in practice since they will certainly fail if
> executed at build time.  (Unless you're building as root, or something,
> but presumably you are not doing that.)  So, it's a little bit of a
> mystery why this would make a difference.  Did you confirm that the
> packages were definitely getting marked as fully configured in the
> status file?

Whilst I'm not building as root, the setup of that box would probably allow 
some things to run that in a totally secure world, it wouldn't/shouldn't.

> I'll make the change, anyway.

Two down, one to go :)

Thanks,

RP 
Richard Purdie | 19 Apr 2005 10:13

Re: [Gpe] 2.6 kernel with gpe-image on c7x0 issues summary

Phil Blundell:
>> Can someone tell me where [minilite] "detects a corgi" as it really needs 
>> to detect
>> a corgi running 2.4.
>
> It looks for /proc/driver/fl/corgi-bl.  Koen, are you saying that this
> file exists on 2.6 but doesn't have any useful effect?  If so, I guess
> this is a kernel bug.

I think Koen said it detected a corgi and then automatically looked for the 
above file. I can confirm that /proc/driver/fl/* does not exist on the 2.6 
kernel so whatever is at fault, its not the kernel.

RP 

Gmane