Re: Buzzing (was :The forbidden topic: Glamo OpenGL)

[Lally Singh]

On Sat, Nov 15, 2008 at 4:49 AM, The Rasterman Carsten Haitzler
<[EMAIL PROTECTED]> wrote:
> On Sat, 15 Nov 2008 07:22:29 + Stroller <[EMAIL PROTECTED]>
> babbled:
>
>>
>> On 15 Nov 2008, at 07:08, Kishore wrote:
>>
>> > On Friday 14 Nov 2008 8:13:20 pm Gothnet wrote:
>> >> Also, I know everyone loves X, but is it really the best choice for
>> >> a low
>> >> powered device that needs a responsive UI?
>> > ...
>> > I still would like to know more in terms of performance and memory
>> > consumption
>> > and scalability.
>>
>> You guys should search some of Raster's previous posts on this
>> subject. Although you may have to go through quite a lot of posts to
>> find his comments (!), I think you will find he has stated more than
>> once that the performance of X is much maligned (as long as
>> programmers are sensible and use appropriate practices).
>
> indeed it is. i have seen x (+efl) drastically (by many times) outperform
> directfb - on the same device. every time someone thinks that the ui sucks and
> the solution is "dump x" it is almost always from a position of lack of
> knowledge just what is the cause of the problem. a bit of analysis and you'll
> find the problem is almost always one (or more) of
>
> 1. just bad hardware (affects everyone x and others)
> 2. incomplete or just bad drivers (not x itself and the same problem will
> happen anywhere you try and accelerate so if its within x or somewhere else -
> same problem).
> 3. simple bad x apps or toolkits doing things badly, inefficiently or just
> trying to do things in a way that just reacts badly with the target hardware.
>
> whatever you do in replacing x - you will just replace it with the same thing
> under a different name. you won't improve or solve anything, as long as you 
> want
> to have more than 1 process be able to display. if it's only one, dumb-fb is 
> an
> option but you still need to then do the whole toolkit so see the above 
> problem
> list. and you just lost multi-process access, lost a lot of support for a lot
> of toolkits, apps etc. if you want to x CAN be used as a dumb-fb with little
> extra overhead.
>
> if you really want to sink a lot of time i can go into gory detail one thing 
> at
> a time... but you can also just search these lists and save me the effort :) x
> gives you the ability to share input devices (kbd, ts, etc.) and share the
> screen. you want that. it is not big and fat. it is rather small and lean.
> extensions exist to do just about everything. very little does not exist in
> some x extension these days.

I just wanted to second Raster's point with a small bit of data: X was
designed with much less powerful devices than the moko in mind.  If
you're worried about X being fat, it's not X.  It's stuff built on top
of X, which we don't need.  X ran fine on my 8mb 486.

-- 
H. Lally Singh
Ph.D. Candidate, Computer Science
Virginia Tech

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)

[Lally Singh]

Well then,

  Therein lies the question, how long is OM going to be using the
Glamo?  There's apparently some real potential in the device, but
that's really measured as much by the chip's relevance as its
functionality.

  The GTA02's been on the brink of obsolescence since the day it was
introduced.  It can't even take most modern (3G) SIMs.  If the Glamo
(or something compatible) is going to be around for a while, either in
a long production life of the GTA02, or in newer phones, then all this
makes sound engineering sense to work on.

  Otherwise, I have real doubts about the longevity of a software
project aggressive enough to attempt major work (e.g. accellerated
OpenGL) on this chip.  Lots of open source projects start off with a
bang of enthusiasm, and die with a whimper.  If the chip's gone in a
few months, I don't think we'll see the project survive.

  Hence, my earlier suggestion on just using the acceleration for some
Gtk operations.  Small, effective changes.  Get that done to make the
device feel responsive.  If someone wants to do the big OpenGL
implementation later, fine, use this Gtk work as a sandbox for getting
a feel for the device.

  $400 for a phone is a reasonable investment.  But months of work in
one's spare time is much bigger.  Before anyone commits to a
large-scale project, I think it's fair to ask OM what their plans are
with this chip.

-ls

On Sun, Nov 16, 2008 at 11:43 PM, Neng-Yu Tu (Tony Tu)
<[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>> Those are some good questions.  From what I understand the Glamo is
>> fixed-function and supports OpenGL ES 1.1.  As far as changing Xglamo to
>> be based on X over kdrive, I think to start, it would be best to leave
>> Xglamo the way it is and just add-in OpenGL ES support, but if there
>> were people dedicated to getting X support I would vote for it.
>>
>
> Glamo3363 support:
>
> * OpenGL ES 1.0
> * OpenGL ES 1.1
> * Mobile D3D
>
> 3D pipe line:
>
> * transform
> * cull
> * lighting
> * clipping
> * setup
> * rasterizer
>
> The glamo datasheet is full of register settings, as wolfgang said, we
> hope could resolve this NDA issue in someway that could help people
> develop 3D development on FR.
>
> - --
> Neng-Yu Tu (Tony Tu)
> Openmoko, Inc.
> Support.
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkkg9oEACgkQmV6sZhhBn2+FKQCgq+A2HsKkNTlKHvZgi/zjlale
> qXsAn2gi5L3cc0/SKjYF54ve6KtzIABW
> =fJkN
> -END PGP SIGNATURE-
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>



-- 
H. Lally Singh
Ph.D. Candidate, Computer Science
Virginia Tech

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Xlib (was :The forbidden topic: Glamo OpenGL)

[Kishore]

On Monday 17 Nov 2008 11:24:55 am John Lee wrote:
> On Sun, Nov 16, 2008 at 10:05:16AM +1100, Carsten Haitzler wrote:
> > x's internals are definitely up for improvement - callium3d is  there to
> > try and fix this by providing a better more organised and better
> > accelerated driver layer - but again - they aren't going to replace x...
> > just clean up internals. what it means is - the rest of us can continue
> > happily writing x apps and just "wait" for an improvement to pop out the
> > pipeline. indeed x's internal acceleration layer could be improved. it
> > has in the past (especially with xaa) proved an impediment if you have to
> > code AT the driver layer. as such - x was originally designs (as a system
> > - not specifically the xorg tree etc.) to allow full freedom to implement
> > the internals of x any way you like - so as such if you wanted to spend
> > the effort x could accelerate just about everything as long as hardware
> > can do it, somehow - but the points at which that acceleration knowledge
> > need to go into might be much higher up than xaa/exa. you'd have to write
> > a "forked" x with all sorts of hooks higher up. - but it's possible...
> > and then x client work as they always did - and get more use of the
> > hardware :)
>
> MicroXwin ?
>
> http://www.microxwin.com/
>
> "MicroXwin is binary compatible to the Xlib API. However it is niether
> client server nor network oriented. Graphics operations are
> implemented in the linux kernel via a kernel module. An open source
> Xlib library sends graphics commands to the kernel. There is no
> network overhead and no context switch from X client to X server. This
> makes our solution smaller and faster than traditional X Windows."

Looks good and is a direct binary compatible replacement. Perhaps the 
proprietary licence for the kernel module is what is keeping it from being 
used?
-- 
Cheers!
Kishore

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [FDOM] ePDFViewer

[Chaosspawn23]

Hi there!

> Crossposted to Fdom-developement
> 
> Giovanni wrote:
>> Today I installed FDOM 20081023.
>>
>> When I open ePDFViewer, it asks for a password, saying that the 
>> documented is encrypted.
>> I cannot open any of my documents, because of this problem.
> 
> this is a bug I have been meaning to report for a while now.
> 
>> How to fix this?
> 
> The issue arises because I think the launching dialog launches it with 
> an %s argument or something which specifies the path of the file that 
> should be loaded. because it apparently can't deal with no being able to 
>   find the file gracefully, it aassumes something is encrypted and asks 
> for a password.
> 
> Launching from the terminal epdfviewer works fine...
> 
> fixing this *should* (in theory) be trivial, however I don't know, 
> without looking exactly how to do this...

Editing /usr/share/FDSubmenu/viewers/epdfview.desktop and changing

epdfview %f

to

epdfview

should do the trick. :)
On a completely unrelated note - someone should change the way FDSubmenu calls
applications, as the current implementation freezes fdsubmenu until the started
process terminates - I think using subprocess.Popen should work, but I haven't
really looked that closely at the source, yet.

HtH,
Konstantin

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Buzzing (was :The forbidden topic: Glamo OpenGL)

[John Lee]

On Sun, Nov 16, 2008 at 10:05:16AM +1100, Carsten Haitzler wrote:
> 
> x's internals are definitely up for improvement - callium3d is  there to try
> and fix this by providing a better more organised and better accelerated 
> driver
> layer - but again - they aren't going to replace x... just clean up internals.
> what it means is - the rest of us can continue happily writing x apps and just
> "wait" for an improvement to pop out the pipeline. indeed x's internal
> acceleration layer could be improved. it has in the past (especially with xaa)
> proved an impediment if you have to code AT the driver layer. as such - x was
> originally designs (as a system - not specifically the xorg tree etc.) to 
> allow
> full freedom to implement the internals of x any way you like - so as such if
> you wanted to spend the effort x could accelerate just about everything as 
> long
> as hardware can do it, somehow - but the points at which that acceleration
> knowledge need to go into might be much higher up than xaa/exa. you'd have to
> write a "forked" x with all sorts of hooks higher up. - but it's possible...
> and then x client work as they always did - and get more use of the hardware 
> :)

MicroXwin ?

http://www.microxwin.com/

"MicroXwin is binary compatible to the Xlib API. However it is niether
client server nor network oriented. Graphics operations are
implemented in the linux kernel via a kernel module. An open source
Xlib library sends graphics commands to the kernel. There is no
network overhead and no context switch from X client to X server. This
makes our solution smaller and faster than traditional X Windows."


- John

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)

[Neng-Yu Tu (Tony Tu)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> Those are some good questions.  From what I understand the Glamo is
> fixed-function and supports OpenGL ES 1.1.  As far as changing Xglamo to
> be based on X over kdrive, I think to start, it would be best to leave
> Xglamo the way it is and just add-in OpenGL ES support, but if there
> were people dedicated to getting X support I would vote for it.
> 

Glamo3363 support:

* OpenGL ES 1.0
* OpenGL ES 1.1
* Mobile D3D

3D pipe line:

* transform
* cull
* lighting
* clipping
* setup
* rasterizer

The glamo datasheet is full of register settings, as wolfgang said, we
hope could resolve this NDA issue in someway that could help people
develop 3D development on FR.

- --
Neng-Yu Tu (Tony Tu)
Openmoko, Inc.
Support.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkg9oEACgkQmV6sZhhBn2+FKQCgq+A2HsKkNTlKHvZgi/zjlale
qXsAn2gi5L3cc0/SKjYF54ve6KtzIABW
=fJkN
-END PGP SIGNATURE-

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)

[Nicola Mfb]

2008/11/17 Gothnet <[EMAIL PROTECTED]>

>
>
> If OM drop efforts to make 02 better, then they'll probably have a lot of
> folks that just won't buy the 03 because they're angry.
>

About freerunner in general if Openmoko will drop effort on it they'll have
to ship a gta03 without issues otherwise peoples will not trust them anymore
:). About the glamo, did someone evaulate how much it will cost to produce
the wanted 3d driver, and how much *customers* will be happy of this?

Regards

Nicola
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

And one more presentation to the list

[David Samblas]

Hi all

here 
http://www.openmoko-spain.org/files/presentacion_neo-freerunner_openmoko-spainv5_english.odp
http://www.openmoko-spain.org/files/presentacion_neo-freerunner_openmoko-spainv5_english.pdf
you will find a quick and dirty english translation of the presentation
done last Friday in Universidad Carlos III de Madrid anfitrions will
release a video in short, as soon as it's release I will post it on the
list too.

Here there is a draft article where you will find the original spanish
presentation.
http://www.openmoko-spain.org/tiki-read_article.php?articleId=3

Best regards 
-- 
David Reyes Samblas Martinez
http://www.tuxbrain.com
Open ultraportable solutions
Openmoko, Openpandora, GP2X the Wiz, Letux 400
Hey, watch out!!! There's a linux in your pocket!!!


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)

[Lally Singh]

On Sun, Nov 16, 2008 at 7:42 PM, Gothnet <[EMAIL PROTECTED]> wrote:
> Lally Singh wrote:
>> Just fair warning here.  As I don't think OM will use the Glamo in
>> future devices, doing the "right thing" isn't as critical as normal
>> software projects...
> Doing the right this IS critical to support the freerunner, going forward.
> I, personally, get rather worried by all this talk of supporting future
> revisions and not putting in too much freerunner-specific energy because "it
> won't be loing until GTA03 is here"
>
> If OM drop efforts to make 02 better, then they'll probably have a lot of
> folks that just won't buy the 03 because they're angry.

I think the FR needs an accelerator going forward, but I doubt it's the Glamo.

More importantly, I think there's a lot of potential fun to be had with this:
http://www.clutter-project.org/

-ls

-- 
H. Lally Singh
Ph.D. Candidate, Computer Science
Virginia Tech

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)

[Gothnet]

Lally Singh wrote:
> 
> 
> Just fair warning here.  As I don't think OM will use the Glamo in
> future devices, doing the "right thing" isn't as critical as normal
> software projects...
> 
> -- 
> H. Lally Singh
> Ph.D. Candidate, Computer Science
> Virginia Tech
> 
> 

Doing the right this IS critical to support the freerunner, going forward.
I, personally, get rather worried by all this talk of supporting future
revisions and not putting in too much freerunner-specific energy because "it
won't be loing until GTA03 is here"

If OM drop efforts to make 02 better, then they'll probably have a lot of
folks that just won't buy the 03 because they're angry.
-- 
View this message in context: 
http://n2.nabble.com/Calling-interested-Glamo-OpenGL-developers-%28was%3A-The-forbidden-topic%3A-Glamo-OpenGL%29-tp1505667p1507674.html
Sent from the Openmoko Community mailing list archive at Nabble.com.


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Yet Another OpenMoko Presentation

[Tim Dobson]

David Samblas wrote:
> El sáb, 08-11-2008 a las 12:38 +0100, David Samblas escribió:
>> Count with an Spanish translation in short too :)
>>
> I want to use it in more general presentation of openmoko not FDOM
> focused, Can I make a smooth version regarding other distributions...
> you have been ummh eemmhh a little mh rough?

When I get some more free time, I'll see what I can do.

originally it was used for an event where other people were presenting 
the different distributions (and in their cases saying why it wasn't 
their main phone) so in context it didn't look so harsh on them but I do 
take your point.

At the moment (always actually) my life is really busy, and I can't see 
when I will have time, but when I will do my best :)

tim

-- 
www.tdobson.net

If each of us have one object, and we exchange them, then each of us
still has one object.
If each of us have one idea, and we exchange them, then each of us now
has two ideas.   -  George Bernard Shaw

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [FDOM] ePDFViewer

[Tim Dobson]

Crossposted to Fdom-developement

Giovanni wrote:
> Today I installed FDOM 20081023.
> 
> When I open ePDFViewer, it asks for a password, saying that the 
> documented is encrypted.
> I cannot open any of my documents, because of this problem.

this is a bug I have been meaning to report for a while now.

> How to fix this?

The issue arises because I think the launching dialog launches it with 
an %s argument or something which specifies the path of the file that 
should be loaded. because it apparently can't deal with no being able to 
  find the file gracefully, it aassumes something is encrypted and asks 
for a password.

Launching from the terminal epdfviewer works fine...

fixing this *should* (in theory) be trivial, however I don't know, 
without looking exactly how to do this...

Tim

-- 
www.tdobson.net

If each of us have one object, and we exchange them, then each of us
still has one object.
If each of us have one idea, and we exchange them, then each of us now
has two ideas.   -  George Bernard Shaw

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [Om2008.9] How to power off Wifi?

[jidanni]

When I visited the Taipei office in to buy my GTA02 in 9/2008, I spent
the entire day with the engineers adjusting this and that. I asked
them about disabling the four antennas in the GTA02. They said for the
other three powering down via software commands was enough. But for
the WIFI antenna, one must also unscrew (TROX screwdriver) the back
and remove it for complete power savings.

On my 10/2008 visit however, I was not able to spend more than five
minutes there, as I was informed that they are too busy to have people
come in and directly ask engineers questions anymore, and instead to
post questions here.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)

[Lally Singh]

On Sun, Nov 16, 2008 at 4:34 PM, Andy Green <[EMAIL PROTECTED]> wrote:
> FWIW I talked this over with an experienced 3D guy recently about
> something related and he was all in favour of discarding the kdrive
> implementation and making a pure xorg one as a way forward: he told that
> kdrive itself was long dead.  I also know that XGlamo is not that great
> a solution since it is largely the Linux framebuffer driver basically
> cut and pasted into userspace with the locking not being shared between
> kernel and userland.  Whatever it's replaced with ought to be glued into
> kernel Glamo framebuffer driver I think at the very least for any
> critical shared parts like locking and this modal commandqueue stuff.
>
> He also said the same that Glamo was ES, I think 1.1.  Since Graeme is
> going ahead with xorg generally it sounds like this is the recommended
> path to follow if at all possible.
>
> Lastly he mentioned 2442 has no float unit so this impacts the
> implementation, but apparently it's not a killer to used fixed in ES.


Just fair warning here.  As I don't think OM will use the Glamo in
future devices, doing the "right thing" isn't as critical as normal
software projects.  Spend the energy making the best performing, most
functional implementation possible.  If that goal's met, *then* go
back and shove it into Xorg.


-- 
H. Lally Singh
Ph.D. Candidate, Computer Science
Virginia Tech

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

[FDOM] ePDFViewer

[Giovanni]

Today I installed FDOM 20081023.

When I open ePDFViewer, it asks for a password, saying that the documented
is encrypted.
I cannot open any of my documents, because of this problem.

How to fix this?
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: (Debian) IceWm running!

[Timo Juhani Lindfors]

Tha_Man <[EMAIL PROTECTED]> writes:
> However, I'm still not able to switch my desktop to landscape mode :-(

apt-get install xserver-xglamo

and xrandr -o 3 works.


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

[Android] freerunner answercall,

[Andreas Wallin]

Is it possible to answer call by using bluetooth headset och wired
headset when running android on freerunner?

This can be an easy way to implement answercall by writing a custom
application for android on freerunner, The lack of onscreen keyboard may
be a problem when pair:ing bluetooth devices,

greetings !







___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)

[Andy Green]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:

| I have some questions, the glamo chip contains 3d support, what
| version of OpenGL (or OpenGL ES) is implemented?
| Are we still going to keep Xglamo (kdrive) or are we goint to use
| X.org server? (this question arised after Rastermans e-mail)

| Those are some good questions.  From what I understand the Glamo is
| fixed-function and supports OpenGL ES 1.1.  As far as changing Xglamo to
| be based on X over kdrive, I think to start, it would be best to leave
| Xglamo the way it is and just add-in OpenGL ES support, but if there
| were people dedicated to getting X support I would vote for it.

FWIW I talked this over with an experienced 3D guy recently about
something related and he was all in favour of discarding the kdrive
implementation and making a pure xorg one as a way forward: he told that
kdrive itself was long dead.  I also know that XGlamo is not that great
a solution since it is largely the Linux framebuffer driver basically
cut and pasted into userspace with the locking not being shared between
kernel and userland.  Whatever it's replaced with ought to be glued into
kernel Glamo framebuffer driver I think at the very least for any
critical shared parts like locking and this modal commandqueue stuff.

He also said the same that Glamo was ES, I think 1.1.  Since Graeme is
going ahead with xorg generally it sounds like this is the recommended
path to follow if at all possible.

Lastly he mentioned 2442 has no float unit so this impacts the
implementation, but apparently it's not a killer to used fixed in ES.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkkgkdUACgkQOjLpvpq7dMr+kgCfcJFz7F2qCJWXtB+63c0scJ5x
Yq0An1dfewn2MdpYXxPwl1T73kgegoTd
=0qfk
-END PGP SIGNATURE-

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)

[RzR www.rzr.online.fr]

What about using a software opengl es implementation ?
I used to play on this on wince targets (using vincent)

Anyway that's a job I'd like to be involved in , if I had time to
-- 
Related Obsession : http://rzr.online.fr/q/OpenGlEs

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: (Debian) IceWm running!

[Paul]

Tha_Man wrote:
> However, I'm still not able to switch my desktop to landscape mode :-(
> setting the options in xorg.conf doesn't seem to matter, is IceWM using a
> different (X) config file or something? Paul, did you do anything special
> besides removing xfce (I presume) and installing icewm?
>   

I didn't even remove XFCE. I set up IceWM, edited both entries in 
xorg.conf and that was really all.
If you want me to, I can e-mail you the xorg.conf I have, tomorrow evening.

See you on tweakers.net!

Paul

-- 
He who sacrifices his conscience to ambition
burns a picture to obtain the ashes.
-Chinese Proverb

http://www.nlpagan.net
Running on Mandriva Linux 2008 and Ubuntu 8.10


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: (Debian) IceWm running!

[Tha_Man]

Paul-8 wrote:
> 
> 
>> I could not figure out a way so I switched to xvkbd that respects the
>> -geometry option.
>>   
> 
> I am messing with that too, and it seems to work reasonably well. Just 
> wish it would stop pressing enter continuously when I only press it 
> once. But I'll RTFM first. hahaha
> 
> Paul
> 
> 
Accessing the xvkbd options (in the lower left corner) and setting
'Automatic click' to Off fixed that for me :-) I'm using it as well now,
works pretty nicely once configured well.
However, I'm still not able to switch my desktop to landscape mode :-(
setting the options in xorg.conf doesn't seem to matter, is IceWM using a
different (X) config file or something? Paul, did you do anything special
besides removing xfce (I presume) and installing icewm?

Cheers, Tha_Man
-- 
View this message in context: 
http://n2.nabble.com/%28Debian%29-IceWm-running%21-tp1498057p1507063.html
Sent from the Openmoko Community mailing list archive at Nabble.com.


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)

[Jacob Peterson]

On Sun, Nov 16, 2008 at 8:49 PM, Aliner <[EMAIL PROTECTED]> wrote:

> You can count me in. I have experience doing kernel development. Since the
> documentation is not available, I saw a couple of pointers on how to start
> on the nouveau project. They have an excellent section on tools and
> documentation. http://nouveau.freedesktoplorg/wiki.
>
> I have some questions, the glamo chip contains 3d support, what version of
> OpenGL (or OpenGL ES) is implemented?
> Are we still going to keep Xglamo (kdrive) or are we goint to use X.org
> server? (this question arised after Rastermans e-mail)
> Are we going to support full OpenGL or OpenGL ES on the implementation?
> Or is it going to be a OpenGL driver and a OpenGL ES driver?
>
> Thank you


Those are some good questions.  From what I understand the Glamo is
fixed-function and supports OpenGL ES 1.1.  As far as changing Xglamo to be
based on X over kdrive, I think to start, it would be best to leave Xglamo
the way it is and just add-in OpenGL ES support, but if there were people
dedicated to getting X support I would vote for it.

-Jacob
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

debian on neo1973: ogpsd failing?

[Brad Midgley]

Hi everybody

I've been using debian on neo1973 using the wiki instructions at
http://wiki.debian.org/DebianOnNeo1973

I added gllin and I can see it's getting a fix:

[EMAIL PROTECTED]:~$ cat /tmp/nmeaNP
$GPGGA,171809.00,4026.092943,N,11147.023140,W,1,08,0.5,1506.0,M,0.347000,M,0.009
$GPGSV,2,1,08,28,64,048,41,08,39,144,42,26,32,250,34,15,28,272,40*7E
$GPGGA,171810.00,4026.092907,N,11147.023193,W,1,08,0.5,1506.0,M,0.347000,M,0.00F
$GPGSV,2,1,08,28,64,048,42,08,39,144,41,26,32,250,36,15,28,272,39*72
$GPGSA,A,3,04,08,09,11,15,26,27,28,1.1,0.5,1.0*3C
$GPGGA,171811.00,4026.092885,N,11147.023230,W,1,08,0.5,1506.0,M,0.348000,M,0.000
$GPGSV,2,1,08,28,64,048,43,08,39,144,42,26,32,250,34,15,28,272,37*7C
$GPGSA,A,3,04,08,09,11,15,26,27,28,1.1,0.5,1.0*3C

but gpspipe (talking to fso-gpsd) is not getting any of this. I
believe this means that ogpsd is failing to send dbus messages for the
current fix. What should I do to make ogpsd work?

[EMAIL PROTECTED]:~$ gpspipe -r
GPSD,R=1
$GPGGA,,0,00,,,*66
$GPGSA,A,0,,,*1f
$GPGSV,1,1,00*79
$GPRMC,,V,*31
$GPGLL,,V*06
$GPVTG*52
$GPGGA,,0,00,,,*66
$GPGSA,A,0,,,*1f
$GPGSV,1,1,00*79
$GPRMC,,V,*31
$GPGLL,,V*06
$GPVTG*52

Brad

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Root password required?

[Denis Galvao]

try 192.168.0.202

On 11/16/08, Peter Neubauer <[EMAIL PROTECTED]> wrote:
> Hi there,
> flashing my FR with the latest builds from
> http://downloads.openmoko.org/daily/ it seems I suddenly cannot login
> via
>
> ssh [EMAIL PROTECTED]
>
> with an empty password, but I can ping the device, using OSX. Has
> anything changed there? If not, I need to investigate further ...
>
> /peter
>
> http://www.oredev.se - Be there or be gone.
>
> GTalk:neubauer.peter
> Skypepeter.neubauer
> ICQ18762544
> Phone   +46704 106975
> LinkedIn   http://www.linkedin.com/in/neubauer
> Twitter  http://twitter.com/peterneubauer
>
> http://www.neo4j.org - New Energy for Data - the Graph Database.
> http://www.ops4j.org - New Energy for OSS Communities - Open
> Participation Software.
> http://www.qi4j.org- New Energy for Java - Domain Driven
> Development.
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [Qt Extended] Disabling predictive text ?

[Chris Samuel]

- "Thomas Bertani" <[EMAIL PROTECTED]> wrote:

> Just remove the dictionary files in /opt/Nokia/Qtopia/etc/dict/

Thanks Thomas, Tomas and Paul!

Now I'm going to have to buy a USB cable to do that, I managed to
leave mine behind in Australia!

cheers,
Chris
-- 
 Chris Samuel  :  http://www.csamuel.org/  :  Melbourne, VIC

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Root password required?

[Peter Neubauer]

Hi there,
flashing my FR with the latest builds from
http://downloads.openmoko.org/daily/ it seems I suddenly cannot login
via

ssh [EMAIL PROTECTED]

with an empty password, but I can ping the device, using OSX. Has
anything changed there? If not, I need to investigate further ...

/peter

http://www.oredev.se - Be there or be gone.

GTalk:neubauer.peter
Skypepeter.neubauer
ICQ18762544
Phone   +46704 106975
LinkedIn   http://www.linkedin.com/in/neubauer
Twitter  http://twitter.com/peterneubauer

http://www.neo4j.org - New Energy for Data - the Graph Database.
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.
http://www.qi4j.org- New Energy for Java - Domain Driven Development.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)

[Aliner]

You can count me in. I have experience doing kernel development. Since the
documentation is not available, I saw a couple of pointers on how to start
on the nouveau project. They have an excellent section on tools and
documentation. http://nouveau.freedesktoplorg/wiki.

I have some questions, the glamo chip contains 3d support, what version of
OpenGL (or OpenGL ES) is implemented?
Are we still going to keep Xglamo (kdrive) or are we goint to use X.org
server? (this question arised after Rastermans e-mail)
Are we going to support full OpenGL or OpenGL ES on the implementation?
Or is it going to be a OpenGL driver and a OpenGL ES driver?

Thank you

On Sun, Nov 16, 2008 at 2:11 PM, "Marco Trevisan (Treviño)"
<[EMAIL PROTECTED]>wrote:

> Jacob Peterson wrote:
> > There has been some discussion on the recently about the Glamo and
> > OpenGL where Wolfgang called for serious developers to get in touch with
> > him and he would see what could be done about getting access to the
> > NDA'ed Glamo documents [1].  A couple of developers responded saying
> > they were interested.  I would like to see how many people are
> > interested and willing to commit to working on and OpenGL driver in this
> > thread.  If there is enough interest I will start a project one
> > projects.openmoko.org  and then we can
> > work with Openmoko on the legal aspects of the NDA.
> >
> > So please, if you are interested and motivated lets discuss it here,
> > then we can work on getting the rest in motion.
>
> What about cross-posting this also to mesa-devel and dri-devel?
>
> --
> Treviño's World - Life and Linux
> http://www.3v1n0.net/
>
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [Qt Extended] Disabling predictive text ?

[Thomas Bertani]

Just remove the dictionary files in /opt/Nokia/Qtopia/etc/dict/

2008/11/16 Chris Samuel <[EMAIL PROTECTED]>:
> Hi folks,
>
> Does anyone know if it's possible to disable the predictive
> text in the alpha-only keyboard in Qt Extended 4.4.2 ?
>
> I find the handwriting method too hard to get right and
> the full size QWERTY keyboard is too small for fingers.
>
> The purely alpha keyboard looks about the right size for
> doing an SMS, but it seems to only do predictive text with
> no way to just be able to type what you want..
>
> Anyone got any clues ?
>
> cheers,
> Chris
> --
>  Chris Samuel  :  http://www.csamuel.org/  :  Melbourne, VIC
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [Qt Extended] Disabling predictive text ?

[Paul]

> Does anyone know if it's possible to disable the predictive
> text in the alpha-only keyboard in Qt Extended 4.4.2 ?
>   

It's on the wiki:
http://wiki.openmoko.org/wiki/Qtopia_/_Qt_Extended_on_FreeRunner#Internationalization

Good luck!
Paul

-- 
He who sacrifices his conscience to ambition
burns a picture to obtain the ashes.
-Chinese Proverb

http://www.nlpagan.net
Running on Mandriva Linux 2008 and Ubuntu 8.10


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [Qt Extended] Disabling predictive text ?

[Tomas Riveros Schober]

I think that you have to delete the dictionaries for the keyboard to 
stop doing its predictive thing.
i dont have the exact location of the files at hand, but it should be 
easy to find in the wiki (or the list archives).

Tom

Chris Samuel escribió:
> Hi folks,
>
> Does anyone know if it's possible to disable the predictive
> text in the alpha-only keyboard in Qt Extended 4.4.2 ?
>
> I find the handwriting method too hard to get right and
> the full size QWERTY keyboard is too small for fingers.
>
> The purely alpha keyboard looks about the right size for
> doing an SMS, but it seems to only do predictive text with
> no way to just be able to type what you want..
>
> Anyone got any clues ?
>
> cheers,
> Chris
>   

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)

[Marco Trevisan (Treviño)]

Jacob Peterson wrote:
> There has been some discussion on the recently about the Glamo and
> OpenGL where Wolfgang called for serious developers to get in touch with
> him and he would see what could be done about getting access to the
> NDA'ed Glamo documents [1].  A couple of developers responded saying
> they were interested.  I would like to see how many people are
> interested and willing to commit to working on and OpenGL driver in this
> thread.  If there is enough interest I will start a project one
> projects.openmoko.org  and then we can
> work with Openmoko on the legal aspects of the NDA.
> 
> So please, if you are interested and motivated lets discuss it here,
> then we can work on getting the rest in motion.

What about cross-posting this also to mesa-devel and dri-devel?

-- 
Treviño's World - Life and Linux
http://www.3v1n0.net/


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

[Qt Extended] Disabling predictive text ?

[Chris Samuel]

Hi folks,

Does anyone know if it's possible to disable the predictive
text in the alpha-only keyboard in Qt Extended 4.4.2 ?

I find the handwriting method too hard to get right and
the full size QWERTY keyboard is too small for fingers.

The purely alpha keyboard looks about the right size for
doing an SMS, but it seems to only do predictive text with
no way to just be able to type what you want..

Anyone got any clues ?

cheers,
Chris
-- 
 Chris Samuel  :  http://www.csamuel.org/  :  Melbourne, VIC

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: (Debian) IceWm running!

[Paul]

> I could not figure out a way so I switched to xvkbd that respects the
> -geometry option.
>   

I am messing with that too, and it seems to work reasonably well. Just 
wish it would stop pressing enter continuously when I only press it 
once. But I'll RTFM first. hahaha

Paul

-- 
He who sacrifices his conscience to ambition
burns a picture to obtain the ashes.
-Chinese Proverb

http://www.nlpagan.net
Running on Mandriva Linux 2008 and Ubuntu 8.10


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Re: Font size problem #2

[rhn]

Od: Stefan Monnier <[EMAIL PROTECTED]>
> The problem is that many programs use "inches" not as a way to talk
> about the size as measured on the screen (i.e. physical size), but as
> a way to talk about the size as seen by the user (i.e. visual size).
> Currently, those two issues are completely conflated (at least for all
> apps I'm familiar with, under X11).  So there's no way to fix one
> without breaking the other.  As it happens, I look at objects on my
> screen a lot more than I measure them, so I don't care about the
> physical size of pixels nearly as much as I care about their visual
> size.  So I ask my FR's X server to lie about its pixel density.
> I originally tried to just adjust the font size, but it's a lot more
> painful: font size is set at too many places, including at places over
> which I have no control (e.g. web pages).
> 
> In theory setting DPI to 100 is the wrong solution, but in practice it
> seems to be the best one.
> 
> 
> Stefan
> 
I agree. For now, there seems to be no better solution.
I think the problem lies in what you pointed - the visual size, but not quite 
the way you said.
The visual size should be set by the user, according to his/her tastes. This is 
done in theory by setting the prefferred font size. Unfortunately, there is the 
problem with setting it so that all the applications take it into account. 
Currently, even if you set the font size in all the places necessary, some 
misbehaving app might set it as it wants, anyway - this results in the illusion 
of not being able to control the font size of webpages.
But solving it this way (which I unhumbly consider elegant) would require 
change in the way aplications (and webpages) are created.

rhn

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Logging of the FR, for now

[Minh Ha Duong]

Le dimanche 16 novembre 2008, Nishit Dave a écrit :
> All the best, and sayonara, arrivederci, hasta la vista.

  So you go back to Real Life (tm) ? Please send us a postcard, because I have 
a feeling that Freeing the Phone is a timeeater for many of us too - my wife 
totally agrees. In any case I am sure that you will engage for other worthy 
causes and communities soon, there are so many ways to improve this world.

  Thanks for the encouragements.
Wishing you well too,
Minh
-- 
Minh HA DUONG, Chargé de Recherche, CNRS
CIRED, Centre International de Recherches sur l'Environnement et le 
Développement
http://minh.haduong.com

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Logging of the FR, for now

[Nishit Dave]

Hi folks,

The past few months have been an interesting ride, quite like a roller
coaster, ever since I got my Freerunner.  There were the thrills of the new
phone and new software versions, getting things working and trying out new
packages.  There were the obvious, much documented disappointments.

I would love to continue to be a FR owner, but I need a working business
phone and can't afford a new one.  The fine folks at IDA Systems had offered
me a special return and refund opportunity, and some fine folk here in the
community advised me to take it so I could [quote] fucking stop whining!
[unquote]

Well, I have finally done so, and would be leaving this list now.  I will
miss my FR dearly, because no other phone currently made lets me do so much
with it.  My only trouble was that that so much resulted into so little
productivity.

This is not a defeat of philosophy to practicality, just a temporary truce.
I will be back in time for the GTA03 or GTA04 if and when they mature to be
daily phones.

Meanwhile, I encourage all of you to carry on valiantly.  Going by what I
read, the GTA02 should become usable shortly, and it would be terrific
hardware to own with all the nifty and innovative packages you have written
around it.  I wish I could have waited till then, but I have a job to do.
Hopefully I will have deeper pockets to buy a second phone next year.

All the best, and sayonara, arrivederci, hasta la vista.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

[ReMoko] hexadecimal keys

[Pieter Colpaert]

Hi,
I've been looking into the Remoko project (and I like it very much,
thanks Valerio) But it doesn't seem to support buttons like 'play' or
'previous'. Gnome uses 0xa2 to play/pause, 0xa4 to stop, etc... I tried
putting those codes manually into the config file, but didn't work. Any
idea how to use these keys in Remoko?

Pieter


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)

[Jacob Peterson]

There has been some discussion on the recently about the Glamo and OpenGL
where Wolfgang called for serious developers to get in touch with him and he
would see what could be done about getting access to the NDA'ed Glamo
documents [1].  A couple of developers responded saying they were
interested.  I would like to see how many people are interested and willing
to commit to working on and OpenGL driver in this thread.  If there is
enough interest I will start a project one projects.openmoko.org and then we
can work with Openmoko on the legal aspects of the NDA.

So please, if you are interested and motivated lets discuss it here, then we
can work on getting the rest in motion.

Thanks,
Jacob
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [Om2008.9] How to power off Wifi?

[Yorick Moko]

http://tehinterweb.com/freerunner/batmon/batmon.py is also nice

On Sun, Nov 16, 2008 at 1:49 AM, Minh Ha Duong <[EMAIL PROTECTED]> wrote:
> Le samedi 15 novembre 2008, Matthias Apitz a écrit :
>>I don't know if it reduces the drawing of power (btw: what is the
>>easiest method to measure it? pulling out the battery and measure the
>>power consumption via the cable?);
>
>  I would use something like the attached "battery.py" script to measure
> power.
>
> Minh
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
>

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Next community update

[Yorick Moko]

I would really like to see Wolfgangs call to the the community
included; where he states that openmoko is searching for competent
community dev's to start working on the glamo

as stated on 
http://lists.openmoko.org/pipermail/community/2008-November/035768.html
 :

"Having said that, if someone wants to seriously develop for the glamo,
please get in touch with me and we will find a legally correct way to
extend the smedia documentation to you.
In fact we have done that in a few cases before already, but I'm not
sure how much actual codes have come out of that. I think very
little ;-)
So we need some really serious coders that don't mind a tough challenge.

Best Regards,
Wolfgang"


yorick


On Sun, Nov 16, 2008 at 2:21 AM, Minh Ha Duong <[EMAIL PROTECTED]> wrote:
> Hi everybody,
>
>  Here is the draft for the next Community Update:
>  http://wiki.openmoko.org/wiki/Talk:Community_Updates
> To anybody who has started a significant thread or contributed an important
> information in the mailing list: if you want to see that meme amplified, have
> a day.
>
> Yours,
> Minh
> --
> Minh HA DUONG, Chargé de Recherche, CNRS
> CIRED, Centre International de Recherches sur l'Environnement et le
> Développement
> http://minh.haduong.com
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: USB keyboard udev rule

[Pander]

Did anyone discover a way how to detect this? Perhaps after detection
that USB is connected but not charging, try host mode and have a look
what is connect. If it is no laptop/desktop/charger but a keyboard, stay
in this mode, otherwise, go back to client mode. This double check could
be made on very simple data like USB ID.

Alternatively, I'd like to white list the USB IDs (possibly ranges) of
my keyboards and the above described mechanism can detect that the
device can switch to host mode, and when to switch back on unplug.

Developing some rules like this would certainly easy using external
keyboard and promote plug and play.

Robin Paulson wrote:
> 2008/11/11 Alastair Johnson <[EMAIL PROTECTED]>:
>> Pander wrote:
>>> Does anyone have a udev rule for USB keyboard that does the following.
>>> When no external USB devices are connected and a keyboard is plugged in,
>>> USB can switch to host mode and switch back when USB keyboard is
>>> unplugged. As far as I'm concerned, this would be a very welcome feature.
>> AFAIK we don't have a means of autodetecting whether we should be host
>> or device, and if we aren't in host mode we can't detect the keyboard
>> insertion. There may be a way of doing this using the ID pin but I don't
>> know how standard it would be.
> 
> would there be any adverse consequences to the neo always assuming
> it's in host mode (and thus supplying power also), unless a voltage is
> detected? i.e. as soon as any power disappears, it automatically
> switches back to device again?
> 
> from what i can tell from previous discussions, being provided with
> power while supplying it, doesn't damage the neo, as it automatically
> turns off the power when this happens
> 
> i'm not thinking just about keyboards here, but more about 'faking' a
> usb otg port, or at least something similar
> 
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: The forbidden topic: Glamo OpenGL

[Michael Sheldon]

Tim Schmidt wrote:
> On Fri, Nov 14, 2008 at 5:11 AM, Wolfgang Spraul <[EMAIL PROTECTED]> wrote:
>> Having said that, if someone wants to seriously develop for the glamo,
>> please get in touch with me and we will find a legally correct way to
>> extend the smedia documentation to you.
>> In fact we have done that in a few cases before already, but I'm not
>> sure how much actual codes have come out of that. I think very
>> little ;-)
>> So we need some really serious coders that don't mind a tough challenge.
> 
> I am not a skilled developer, but I would be more than happy to
> organize, and participate in a traditional clean room
> re-implementation of the documentation.
> 
> As a GTA02 owner, as a founding member of the Open Graphics Project,
> as a Director of the Open Hardware Foundation, I believe I have the
> resources to accomplish such a task.
> 
> I'd love to try.
> 
> Can we make it happen?
> 
> --tim

I'd certainly be interested in attempting to add OpenGL support to the 
glamo driver if documentation were to become available, but I'm hesitant 
to put myself forward for anything that would require Openmoko Inc. to 
go out of their way by jumping through administrative loop holes to give 
access to the NDA'd documentation, as I'm unlikely to actually succeed 
(I have some experience of driver development, and experience of OpenGL 
from a high level point of view, but no actual experience of graphics 
driver development).

So I think a freely available clean room rewrite of the documentation 
would be very helpful, as there may well be others in a similar 
position, people willing to take a look at the problem, but not 
confident enough to cause OpenMoko Inc. extra hassle/work for what may 
result in nothing.

Cheers,
  Mike.


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Flashing Neo

[mallikarjun arjun]

On Sun, Nov 16, 2008 at 1:37 AM, Stefan Monnier <[EMAIL PROTECTED]>wrote:

> >  Is there a problem if i flash my neo too many times? because i have done
> > around 20 times in a week time..
>
> Be careful: at this rhythm, your flash will only last ... another 1000
> weeks (or maybe 1 if you're lucky).
>
>
>Stefan
>
initially i am in testing phase so my phase will drastically reduce. Thanks
for info.

>
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: The forbidden topic: Glamo OpenGL

[Michael Sheldon]

Tim Schmidt wrote:
> On Fri, Nov 14, 2008 at 5:11 AM, Wolfgang Spraul <[EMAIL PROTECTED]> wrote:
>> Having said that, if someone wants to seriously develop for the glamo,
>> please get in touch with me and we will find a legally correct way to
>> extend the smedia documentation to you.
>> In fact we have done that in a few cases before already, but I'm not
>> sure how much actual codes have come out of that. I think very
>> little ;-)
>> So we need some really serious coders that don't mind a tough challenge.
> 
> I am not a skilled developer, but I would be more than happy to
> organize, and participate in a traditional clean room
> re-implementation of the documentation.
> 
> As a GTA02 owner, as a founding member of the Open Graphics Project,
> as a Director of the Open Hardware Foundation, I believe I have the
> resources to accomplish such a task.
> 
> I'd love to try.
> 
> Can we make it happen?
> 
> --tim

I'd certainly be interested in attempting to add OpenGL support to the 
glamo driver if documentation were to become available, but I'm hesitant 
to put myself forward for anything that would require Openmoko Inc. to 
go out of their way by jumping through administrative loop holes to give 
access to the NDA'd documentation, as I'm unlikely to actually succeed 
(I have some experience of driver development, and experience of OpenGL 
from a high level point of view, but no actual experience of graphics 
driver development).

So I think a freely available clean room rewrite of the documentation 
would be very helpful, as there may well be others in a similar 
position, people willing to take a look at the problem, but not 
confident enough to cause OpenMoko Inc. extra hassle/work for what may 
result in nothing.

Cheers,
  Mike.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: The forbidden topic: Glamo OpenGL

[Jacob Peterson]

I just wanted to update.  I am trying to locate all the information I can
relating to the Glamo, including projects using the hardware acceleration
features of it on this wiki page [1].  I would like to use that page as a
starting point to help organize an effort to get something underway with
regard to the Glamo chip.  There is not much there at the moment since
information is quite hard to come by, but if anyone has further details or
updates please put them on the wiki page.

Thanks,
Jacob

[1] http://wiki.openmoko.org/wiki/Smedia_Glamo_3362

On Sat, Nov 15, 2008 at 1:13 AM, Michael Sheldon <[EMAIL PROTECTED]> wrote:

> Tim Schmidt wrote:
> > On Fri, Nov 14, 2008 at 5:11 AM, Wolfgang Spraul <[EMAIL PROTECTED]>
> wrote:
> >> Having said that, if someone wants to seriously develop for the glamo,
> >> please get in touch with me and we will find a legally correct way to
> >> extend the smedia documentation to you.
> >> In fact we have done that in a few cases before already, but I'm not
> >> sure how much actual codes have come out of that. I think very
> >> little ;-)
> >> So we need some really serious coders that don't mind a tough challenge.
> >
> > I am not a skilled developer, but I would be more than happy to
> > organize, and participate in a traditional clean room
> > re-implementation of the documentation.
> >
> > As a GTA02 owner, as a founding member of the Open Graphics Project,
> > as a Director of the Open Hardware Foundation, I believe I have the
> > resources to accomplish such a task.
> >
> > I'd love to try.
> >
> > Can we make it happen?
> >
> > --tim
>
>
> I'd certainly be interested in attempting to add OpenGL support to the
> glamo driver if documentation were to become available, but I'm hesitant
> to put myself forward for anything that would require Openmoko Inc. to
> go out of their way by jumping through administrative loop holes to give
> access to the NDA'd documentation, as I'm unlikely to actually succeed
> (I have some experience of driver development, and experience of OpenGL
> from a high level point of view, but no actual experience of graphics
> driver development).
>
> So I think a freely available clean room rewrite of the documentation
> would be very helpful, as there may well be others in a similar
> position, people willing to take a look at the problem, but not
> confident enough to cause OpenMoko Inc. extra hassle/work for what may
> result in nothing.
>
> Cheers,
>  Mike.
>
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: The forbidden topic: Glamo OpenGL

[Michael Sheldon]

Tim Schmidt wrote:
> On Fri, Nov 14, 2008 at 5:11 AM, Wolfgang Spraul <[EMAIL PROTECTED]> wrote:
> I am not a skilled developer, but I would be more than happy to
> organize, and participate in a traditional clean room
> re-implementation of the documentation.
> 
> As a GTA02 owner, as a founding member of the Open Graphics Project,
> as a Director of the Open Hardware Foundation, I believe I have the
> resources to accomplish such a task.
> 
> I'd love to try.
> 
> Can we make it happen?
> 
> --tim

I'd certainly be interested in attempting to add OpenGL support to the 
glamo driver if documentation were to become available, but I'm hesitant 
to put myself forward for anything that would require Openmoko Inc. to 
go out of their way by jumping through administrative loop holes to give 
access to the NDA'd documentation, as I'm unlikely to actually succeed 
(I have some experience of driver development, and experience of OpenGL 
from a high level point of view, but no actual experience of graphics 
driver development).

So I think a freely available clean room rewrite of the documentation 
would be very helpful, as there may well be others in a similar 
position, people willing to take a look at the problem, but not 
confident enough to cause OpenMoko Inc. extra hassle/work for what may 
result in nothing.

Cheers,
  Mike.


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: The forbidden topic: Glamo OpenGL

[Michael Sheldon]

Tim Schmidt wrote:
> On Fri, Nov 14, 2008 at 5:11 AM, Wolfgang Spraul <[EMAIL PROTECTED]> wrote:
>> Having said that, if someone wants to seriously develop for the glamo,
>> please get in touch with me and we will find a legally correct way to
>> extend the smedia documentation to you.
>> In fact we have done that in a few cases before already, but I'm not
>> sure how much actual codes have come out of that. I think very
>> little ;-)
>> So we need some really serious coders that don't mind a tough challenge.
> 
> I am not a skilled developer, but I would be more than happy to
> organize, and participate in a traditional clean room
> re-implementation of the documentation.
> 
> As a GTA02 owner, as a founding member of the Open Graphics Project,
> as a Director of the Open Hardware Foundation, I believe I have the
> resources to accomplish such a task.
> 
> I'd love to try.
> 
> Can we make it happen?
> 
> --tim


I'd certainly be interested in attempting to add OpenGL support to the 
glamo driver if documentation were to become available, but I'm hesitant 
to put myself forward for anything that would require Openmoko Inc. to 
go out of their way by jumping through administrative loop holes to give 
access to the NDA'd documentation, as I'm unlikely to actually succeed 
(I have some experience of driver development, and experience of OpenGL 
from a high level point of view, but no actual experience of graphics 
driver development).

So I think a freely available clean room rewrite of the documentation 
would be very helpful, as there may well be others in a similar 
position, people willing to take a look at the problem, but not 
confident enough to cause OpenMoko Inc. extra hassle/work for what may 
result in nothing.

Cheers,
  Mike.


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community