Re: qtmoko - updated and new packages.
On Tuesday 08 June 2010 22:54:51 Alex Samorukov wrote: > 1) Added PDF support to eyepiece viewer. I tested it with ~5 different > PDF files and it works fine. > 2) Added qdictopia dictionary. This program allow to work with stardict > dictionary files. Project is originally based on sources from [1], but > includes a lot of changes, better support in output, ARM related fixes, > Unicode support, etc. There is also package with updated QtMaze with better graphics and much more responsive accelerometers from Anton. Very nice, try it. Btw QtMoko is now probably best distro for translating ;-) We have: 1/ google translator (online) 2/ qdictopia (offline bilingual) 3/ qgcide (offline monolingual explanatory dictionary) > Also i updated screenshots section [2] of the qtmoko wiki to add this > (and not only) screenshots. > > [1] http://code.google.com/p/qdictopia/ > [2] http://qtmoko.org/wiki/Screenshots And some more from my page: http://activationrecord.net/radekp/qtmoko/screenshots/eyepiece.png http://activationrecord.net/radekp/qtmoko/screenshots/qdictopia.png http://activationrecord.net/radekp/qtmoko/screenshots/qdictopia2.png Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [wikireader] Project Gutenberg (again)
On Tuesday, June 8, 2010, Tom Bachmann wrote: >> This has nothing to do with the data structures. We cache the fonts >> into the SDRAM to speed up the entire system. Without this, WikiReader >> is too painfully slow (reading from the SD card caps out at around >> 125kb/s.) Currently we use 32MB of SDRAM. This means we can hold a few >> font styles but we need to move to smaller size SDRAM for future >> productions for cost reasons. So we have to be super careful with how >> we handle fonts. It's quite a complex problem for us. Especially as we >> add more and more language support. >> > > I see. That's the kind of deep problem I'd rather leave to you experts. > I'll just wait and see if you cook something up. Till then I can live > without boldface. Sure. We'll add it to our todo list. Please keep us posted as to your progress. This is super exciting work you're doing! Sean -- -Sean ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [wikireader] Project Gutenberg (again)
> This has nothing to do with the data structures. We cache the fonts > into the SDRAM to speed up the entire system. Without this, WikiReader > is too painfully slow (reading from the SD card caps out at around > 125kb/s.) Currently we use 32MB of SDRAM. This means we can hold a few > font styles but we need to move to smaller size SDRAM for future > productions for cost reasons. So we have to be super careful with how > we handle fonts. It's quite a complex problem for us. Especially as we > add more and more language support. > I see. That's the kind of deep problem I'd rather leave to you experts. I'll just wait and see if you cook something up. Till then I can live without boldface. Regards, Tom ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [wikireader] Project Gutenberg (again)
Hi Tom On Tue, Jun 8, 2010 at 7:20 AM, Tom Bachmann wrote: > >> 1) Is there a "deep" reason why boldface fonts are not implemented? I > >> figure they are not really relevant for wikis, but would be nice for > >> some of the books. Unless there is something that complicates the matter > >> I'm not seeing, I think I will add them (should be straightforward to > >> mimic the behaviour of italic fonts?). > > > > They are implemented. We just didn't include them to save space. (Font > > sets are super huge when you include all the unicode characters!) > > > > If you look at the function "handle_data" within > > http://github.com/wikireader/wikireader/blob/master/host-tools/offline-renderer/ArticleRenderer.py > > you'll see what I mean. > > > > Hm. I thought I had convinced myself that the real problem was that only > two bits are used to encode the font id, and they are already used up > (default, italic, title, subtitle, and "supplements" [large files with > all characters I suppose] for default, title, subtitle). So adding > boldface fonts to the wiki-app *does* seem to involve some non-trivial > work. (I guess the advantage of splitting the fonts like this is that > the small subset can be kept in memory all the time? The size of the > fontfiles themselves is on the order of megabites so shouldn't matter, > should it?) This has nothing to do with the data structures. We cache the fonts into the SDRAM to speed up the entire system. Without this, WikiReader is too painfully slow (reading from the SD card caps out at around 125kb/s.) Currently we use 32MB of SDRAM. This means we can hold a few font styles but we need to move to smaller size SDRAM for future productions for cost reasons. So we have to be super careful with how we handle fonts. It's quite a complex problem for us. Especially as we add more and more language support. Sean ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
qtmoko - updated and new packages.
Hi, Radek Polak updated package repository, so i decided to announce some latest changes. 1) Added PDF support to eyepiece viewer. I tested it with ~5 different PDF files and it works fine. 2) Added qdictopia dictionary. This program allow to work with stardict dictionary files. Project is originally based on sources from [1], but includes a lot of changes, better support in output, ARM related fixes, Unicode support, etc. Also i updated screenshots section [2] of the qtmoko wiki to add this (and not only) screenshots. [1] http://code.google.com/p/qdictopia/ [2] http://qtmoko.org/wiki/Screenshots ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v24
On Tue, Jun 8, 2010 at 17:47, Alex Samorukov wrote: > Best way to request features in opensource project is to do them :) Cool :) I would like to know how to add some function to the dial button, like redial ;) ps. I am a newbie with Qt development tks Levy ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v24
Best way to request features in opensource project is to do them :) About requested features - from my personal point there are too much things to do before touching this. On 06/08/2010 10:21 PM, Aditya Gandhi wrote: > Hi , > I want to request some features for the next version. Related to IM, > contacts management > First selection and deletion of multiple contacts / send multiple > contacts etc. > next is > Integration of google contacts in contacts, selectable contacts sync > from google > > Hope to see it in some release ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v24
Hi , I want to request some features for the next version. Related to IM, contacts management First selection and deletion of multiple contacts / send multiple contacts etc. next is Integration of google contacts in contacts, selectable contacts sync from google Hope to see it in some release ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Neo 1973 - new battery?
Hi, On Mon, Jun 7, 2010 at 9:36 PM, Torfinn Ingolfsen wrote: > Where can I find a new battery for my Neo 1973? > It is better if it is cheap, and it must charge in the phone. > Hmm, is this store any good? http://www.batteryupgrade.com/shopBrowser.php?shopGroupId=97110036#/shopGroupId/97110036 Anybody have experience with them? -- Regards, Torfinn ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on LinuxTag, Berlin
Christoph, will you be there in person? Would love to say "hi". Cheers, :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v24
Thank you very much dear ^^ -- Gand' On Tue, Jun 8, 2010 at 10:07 AM, Radek Polak wrote: > On Tuesday 08 June 2010 09:04:49 Gand' wrote: > > > Unfortunatly, i tweaked my alsamixer config, and i'm afraid i did it > pretty > > wrong ... > > is it possible to reset all those settings ? > > Either extract /usr/share/openmoko/scenarios from release tarbal or they > are > also in my git [1] > > Regards > > Radek > > [1] > > http://github.com/radekp/qtmoko/tree/master/devices/neo/alsa_scenarios/gta02_2.6.29/ > > > ___ > 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: iPhone 4G display for Openmoko?
On Tue, 8 Jun 2010 07:17:55 -0700 jeremy jozwik said: > On Tue, Jun 8, 2010 at 7:11 AM, Martix wrote: > > I think that AMOLED display is better upgrade for our FRs and small > > form factors AMOLEDs aren't much expensive. AMOLED displays have > > similar data interfaces as TFT LCDs, but perhaps we'll need to modify > > power supply. > > now this is all interesting to me, as my wife put a nice nick in my > freerunners screen. > im going to need to swap it out at some point. so i would really like > to know about any movement in this area. all pointless as the maximum resolution glamo can drive is 640x480 (or 480x640). you'll never be able to go above that as long as you have a freerunner. (and note that that is even far beyond what glamo is designed to handle properly. its a qvga gpu. not vga). -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [wikireader] Project Gutenberg (again)
Sean, thanks for your quick reply. >> 1) Is there a "deep" reason why boldface fonts are not implemented? I >> figure they are not really relevant for wikis, but would be nice for >> some of the books. Unless there is something that complicates the matter >> I'm not seeing, I think I will add them (should be straightforward to >> mimic the behaviour of italic fonts?). > > They are implemented. We just didn't include them to save space. (Font > sets are super huge when you include all the unicode characters!) > > If you look at the function "handle_data" within > http://github.com/wikireader/wikireader/blob/master/host-tools/offline-renderer/ArticleRenderer.py > you'll see what I mean. > Hm. I thought I had convinced myself that the real problem was that only two bits are used to encode the font id, and they are already used up (default, italic, title, subtitle, and "supplements" [large files with all characters I suppose] for default, title, subtitle). So adding boldface fonts to the wiki-app *does* seem to involve some non-trivial work. (I guess the advantage of splitting the fonts like this is that the small subset can be kept in memory all the time? The size of the fontfiles themselves is on the order of megabites so shouldn't matter, should it?) > Sure we can do this. No problem! The font is getting more and more > complex since we actually hand make many of the characters now. > That would be really awesome. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: iPhone 4G display for Openmoko?
On Tue, Jun 8, 2010 at 7:11 AM, Martix wrote: > I think that AMOLED display is better upgrade for our FRs and small > form factors AMOLEDs aren't much expensive. AMOLED displays have > similar data interfaces as TFT LCDs, but perhaps we'll need to modify > power supply. now this is all interesting to me, as my wife put a nice nick in my freerunners screen. im going to need to swap it out at some point. so i would really like to know about any movement in this area. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: iPhone 4G display for Openmoko?
I think that AMOLED display is better upgrade for our FRs and small form factors AMOLEDs aren't much expensive. AMOLED displays have similar data interfaces as TFT LCDs, but perhaps we'll need to modify power supply. Regards, Martix 2010/6/8 Thomas Gstädtner : > On Tue, Jun 8, 2010 at 07:54, Dr. H. Nikolaus Schaller > wrote: >> Hi all, >> with the new iPhone it is for the first time better in display >> resolution (640x960 on 3''5 = 326 dpi) than the Freerunner (640x480 on >> 2''8 = 283 dpi) with higher dots per inch. >> >> Does anyone know where to get such a display? Who is making them? > > They say it's an IPS display. Because they are not that common, it's > likely that it's a custom made from Boe Hydis (www.hydis.com). They > list only a small number of available displays, but some vendors have > other panels from them. > > ___ > 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
qi-bootmenu-0.1 problem with menu
Hi, i use latest qi-bootmenu v0.1 for my GTA02 but i have a strange problem. When i powerup my Freerunner and than press AUX to start the bootmenu it always shows the big openmoko logo and starts the bootmenu. But it doesn't always show the possible bootable partitions. I tried it 15 times and in 7 cases it shows all three bootable partitions on my sd-card. In the other 8 cases it only shows poweroff in the bootmenu. And the cases when it worked and when not seemed randomly distributed. Is this a bug or do i have to do something else to get it working all the time? I have three bootable partitions with ext3 on each of them on my sd-card (shr-u, debian, gamerunner). Ciao, Rainer ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Idea for an optimized Emulator
Dont know if its realy qt moko related but hey the emulator can maybe used in qt moko too :). Hi guys, I'm trying to port a snes emulator to the pandora. The problem is that around 60% of the cpu time is taken at 30 FPS by sending the data to the glamo. There is an optimizing idea from a very clever guy who has coded and optimized some emulators for arm devices. The basic idea is to split the bus between glamo and cpu so that the cpu has some work todo while the bus is blocked by the glamo. Like: cpu gets a short time to get data from the RAM into his cache. glamo takes the bus for a short time an gets data cpu cant access the bus and works with the data in his cache. cpu takes the bus back glamo works with the data in his cache [...] Would this be possible? Can you do it without knowing assembler and from a normal C programm? Or do you have to hack the kernel for it? Here is the chatlog: (01:10:28) emulator developer: Anyway, DMA occurs on the SoC itself, so it's possible to perform it from and to anything on the bus, presumably. (01:10:36) emulator developer: It was already shown to work with the Glamo. (01:10:47) emulator developer: Albeit at much lower bandwidth than expected. (01:11:03) emulator developer: The problem is, if you try to DMA one large chunk at a time the DMA ends up stealing the bus for that entire duration of time. (01:11:04) me: but the cpu can work during the DMA operation or? (01:11:36) emulator developer: As soon as the CPU ends up requiring the bus due to a write buffer writeback or cache miss/uncached access it'll end up being stalled until the DMA finishes. (01:12:18) emulator developer: But since the DMA can be set up to step in small chunks it's possible to make it not stall the bus for long, meaning you let the CPU access the bus without a lot of wait and then the CPU can go on doing other things. Since the CPU doesn't need the bus 100% of the time it can still get work done. (01:12:59) me: as long as there is some work todo inside the cache or? (01:13:22) emulator developer: There's always work to do inside the cache. (01:14:24) me: ok but when the glamo uses the whole bus. the cpu can finish its work inside the his cache and then wait until the bus is free or? Or did I misunderstood you? (01:15:29) emulator developer: The Glamo won't use the whole bus if the DMA is staged like I described. (01:15:39) emulator developer: It'll give other things a chance to use it. (01:16:12) me: trying to understand what you described (01:17:37) me: do you send only a piece of the frame at one time to the glamo so the bus isnt used 100% by the glamo? (01:17:58) emulator developer: A timer is set up to automatically do that. (01:18:34) me: hmmm ok (01:19:05) me: and then the cpu has his cache and keep working, and the glamo gets his data and when it's there then he swaps the buffers. (01:19:17) me: ok if i understand it right, it sounds like a realy good idea :) (01:20:04) emulator developer: Someone else mentioned it once. But it hasn't been done, sooo.. (01:20:23) me: so it would be kernel hacking... (01:20:34) me: or can we do it from a normal programm? (01:22:04) emulator developer: I don't know. (01:22:11) me: hmm ok (01:22:25) me: but your idea seems to be realy promising (01:23:32) me: are you sure it would work this way? if it would be possible it would realy help other game too :) (01:24:57) emulator developer: No, am not sure. (01:25:07) emulator developer: And I'm not going to develop on a Freerunner, so count that out ;p (01:25:18) me: *g* (01:25:27) me: i never expected you would develop something for me (01:25:49) me: im sorry that it sounded like i was searching for a nice guy to exploit so he is writing something i want for me (01:25:57) me: in the first post of the board (01:27:28) me: i learned much. i know now that the glamo bandwith is the problem, that the cpu is blocked when the glamo is getting normal data. and the you can bypass the problem if you use DMA and take care that the cpu and the glamo share the bus in a way that both have enough data in their cache to work (01:29:32) emulator developer: But it's a compromise. (01:29:44) emulator developer: It's not like you'd ever be able to do 60fps or anything. (01:29:49) me: thats fine (01:36:09) emulator developer: You'd be frame skipping. (01:36:19) me: thats ok (01:39:21) me: what you would think can be reached? (01:39:51) emulator developer: Dunno. (01:40:19) emulator developer: BTW, there's no OGL ES on Freerunner. (01:40:31) emulator developer: The Glamo has hardware capability for it but no drivers. And the company went under. (01:40:37) me: a (01:40:40) me: damn NDA (01:40:41) emulator developer: But never publicly released a datasheet. (01:41:02) me: ok it can play mpeg4 movies (01:41:04) me: thats cool (01:41:14) me: but the way it was placed on the freerunner realy sux (01:41:46) emulator developer: Yeah i
Re: QtMoko v24
On Tuesday 08 June 2010 09:04:49 Gand' wrote: > Unfortunatly, i tweaked my alsamixer config, and i'm afraid i did it pretty > wrong ... > is it possible to reset all those settings ? Either extract /usr/share/openmoko/scenarios from release tarbal or they are also in my git [1] Regards Radek [1] http://github.com/radekp/qtmoko/tree/master/devices/neo/alsa_scenarios/gta02_2.6.29/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: iPhone 4G display for Openmoko?
On Tue, Jun 8, 2010 at 07:54, Dr. H. Nikolaus Schaller wrote: > Hi all, > with the new iPhone it is for the first time better in display > resolution (640x960 on 3''5 = 326 dpi) than the Freerunner (640x480 on > 2''8 = 283 dpi) with higher dots per inch. > > Does anyone know where to get such a display? Who is making them? They say it's an IPS display. Because they are not that common, it's likely that it's a custom made from Boe Hydis (www.hydis.com). They list only a small number of available displays, but some vendors have other panels from them. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v24
Thank you ! Unfortunatly, i tweaked my alsamixer config, and i'm afraid i did it pretty wrong ... is it possible to reset all those settings ? -- Gand' On Fri, Jun 4, 2010 at 7:42 PM, Alex Samorukov wrote: > On 06/04/2010 10:39 AM, Russell Hay wrote: > > Hey Alex, > > > > can you share your settings? > I think it was taken from this page: > > http://wiki.openmoko.org/wiki/Neo_Freerunner_audio_subsystem > > Also, you can call to some number an play with alsamixer (thrue ssh) to > find optimal values. > > > ___ > 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
