Re: Multiple Distro's..
Neil Jerram neiljer...@googlemail.com writes: 2009/10/24 Aditya Gandhi aditya...@gmail.com: Hi guys, I'm expecting my Free Runner in a day or two I wish to know as to how many distributions can I Run side by side , It is very easy to run two: one on the internal flash and one of the first partition of the SD card, with Qi as the NOR bootloader. Then pressing the power button alone will boot the SD distribution, and pressing AUX+power will allow you to boot the NAND distribution. 1. Qi can't be installed to NOR. 2. Booting from NOR shouldn't be adviced because it initializes some devices in a wrong way which may result in at least increased power consumption. Likely gsm or something else won't work. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Tuxbrain first anniversary
Dear all, Is for me a pleasure and proud to announce this week Tuxbrain the company that has born thanks to the inspiration of Openmoko is now one year old :) a good moment to thanks all that make us enjoy this first year of live, those who has make us learn, and of course to all that had buy something there :) To celebrate it we have down the price of the Frerrunner A6+[1] My only wish when I blow the candle is to enjoy next year as much as this one. A big Thank you and and a bigger hug to you all [1]http://www.tuxbrain.net/en/content/tuxbrain-first-anniversary David Reyes Samblas Martinez http://www.tuxbrain.com Open ultraportable embedded solutions Openmoko, Openpandora, Arduino 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: Centralization of graphical awesomeness
On Mon, 26 Oct 2009 13:57:27 +0300 Evgeniy Karyakin anthropophag...@gmail.com said: 2009/10/26 Carsten Haitzler ras...@rasterman.com: you want speed? you will need to give up something. if you still want it to look nice, then drop pixels. its the simplest and easiest solution. its the right resolution for that cpu anyway. the glamo will still hurt you, but not as much. I'm sure everybody who has any professional connections with Freerunner+Glamo development already took all possible measures to solve this problem. But what concrete steps were taken to ease Glamo bottleneck? If its throughput is so narrow, can we lower amount of none. it's a hardware issue. you simply cant read or write to video ram faster than that. andy tried timing stuff all that happened was instability from memory. glamo is most likely also the cause for the cpu runnig at 400 not 500mhz. the extra load on the memory bus (because glamo is hooked there externally providing another addressable chip) probably caused the instability. remove it and there is a big change the cpu could run at 500mhz instead of 400. it's rated to do 500. (yes power consumption would go up - but it'd only be up while its on. when suspended it wont matter). data flowing through it? There's one neighbor unanswered thread with a render on the device - and this will then limit what you can render. evas can't be fully accelerated by the glamo. it has too many opretations. a bit like asking why quake4 is slow on a a voodoo2. it does much mroe than the old gfx chip ever was designed to do and you will hit software fallbacks. evas has multiple engnines. software (which is what is used - the 16bit renderer as opposed to the full 32bit one). it has xrender - if xrender were fully accelerated this should be better, but glamo cannot fully accelerate all the ops evas uses, so... it will rely on software fallbacks. thus slow down. my bet is you'll end up same speed as the pure software engine, or worse. aftera bunch of hard work you'll have gone nowhere. evas also has a gl and gles2 engine - but thats no use on glamo. it's gles1.1 and very limited (from memory texture size is 256x256 which is pretty useless for 2d as most data you deal with breaks these bounds). question on how to start the kernel with qvga resolution. Aside of no need to do that - just configure x for qgva. :) this, what can be reduced, for example amount of available colours (256 or even 16)? And if this [too] low throughput only of video memory channel? 256 won't help. it increases complexity and really reduces display quality through the floor. the best best is qvga 16bpp. its simple. it doesn't require any hard work. it is actually the most common resolution for most phones and devices out there so the software is more portable if you work on that (and then higher). but... in the past everyone has moaned and complained and refused to use it, and insisted on their vga resolution... and then complained about speed. if people don't believe me that the gta02 is just plain a bad bit of hardware and you have few choices here's some examples. here'es an ooold efl demo app i did: http://www.rasterman.com/files/eem.avi and here it is on a 206mhz ipaq 3660 with 64m ram and 16m flash, qvga(240x320). it's from like 2001/2002 (from memory). its ancient. and watch it run evas: http://www.rasterman.com/files/eem-live.avi here is something i videoed today. it's an samsung s3c6410 at 667 mhz, 128m ram, and 800x480 (higher res than gta02): http://www.rasterman.com/files/ello-elementary-smartq5.mp4 everywhere i look... theres much better hardware. if you look at performance vs age of hardware (when it was released) gta02 is almost at the bottom of the pile. :( you simply have a bad piece of hardware if you want graphics performance. as soon as you acknowledge that and either downgrade the device resolution for example to bring it in line with its performance, or just use different hardware, the better life will be :) -- - 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: Tuxbrain first anniversary
David Reyes Samblas Martinez escribió: Dear all, Is for me a pleasure and proud to announce this week Tuxbrain the company that has born thanks to the inspiration of Openmoko is now one year old :) a good moment to thanks all that make us enjoy this first year of live, those who has make us learn, and of course to all that had buy something there :) To celebrate it we have down the price of the Frerrunner A6+[1] My only wish when I blow the candle is to enjoy next year as much as this one. A big Thank you and and a bigger hug to you all [1]http://www.tuxbrain.net/en/content/tuxbrain-first-anniversary Felicidades compañero!!! Reciban un gran abrazo! ¡que sean muchos más! Kosa - Un mundo mejor es posible - ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
On Mon, 2009-10-26 at 12:40 +0100, Marcel wrote: Am Montag, den 26.10.2009, 02:07 +0100 schrieb Łukasz Pankowski: Hi I have just released ffalarms 0.3, it adds recurring alarms, please test it before depending on it. For me the most missing feature now is being able to edit the alarms and postponing in the acknowledge window. Ideas and comments are welcome. Notes: - add support for recurring alarms, attaching messages to alarms, and choosing alarm date from a calendar - add configuration option for alarm volume, alarm_script and alsa_state Download: http://projects.openmoko.org/frs/?group_id=260release_id=580 (I also provide libical, in case it is not in your distro) Yay! I use ffalarms mostly more than once a day and it's just great to have it. Thanks for your work! :) Although I know you're not too fond of it - what about making it possible to simply turn an alarm off without that puzzle? It's quite annoying me from time to time, especially when I'm just finishing it when its regenerating and I need to hear that alarm once again... -- Marcel Can I add to that request? - Ive just upgraded to ver2 and forgot I had knobbled the puzzel on the old version ... so once .3 hits the shr feeds I will have to spend more time decompiling, figuring out how it works, kill the puzzel then compile it back up again - painful way to fix what is to me a major usability problem (I cant see the numbers without glasses, and of course I am not wearing glasses when the alarm goes off in the morning :) Perhaps, make it a configuration option would make good sense then you can continue torturing those poor souls who like it :) Its quite a good, reliable program, far better than the basic elementary alarm and I use it most days more than once. Good work. BillK ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Downgrading to QVGA is something that should have been done a long time ago. There's no point in trying to force a badly designed system. How do we do it? Which files must be changed? Citando Carsten Haitzler ras...@rasterman.com: On Mon, 26 Oct 2009 13:57:27 +0300 Evgeniy Karyakin anthropophag...@gmail.com said: 2009/10/26 Carsten Haitzler ras...@rasterman.com: you want speed? you will need to give up something. if you still want it to look nice, then drop pixels. its the simplest and easiest solution. its the right resolution for that cpu anyway. the glamo will still hurt you, but not as much. I'm sure everybody who has any professional connections with Freerunner+Glamo development already took all possible measures to solve this problem. But what concrete steps were taken to ease Glamo bottleneck? If its throughput is so narrow, can we lower amount of none. it's a hardware issue. you simply cant read or write to video ram faster than that. andy tried timing stuff all that happened was instability from memory. glamo is most likely also the cause for the cpu runnig at 400 not 500mhz. the extra load on the memory bus (because glamo is hooked there externally providing another addressable chip) probably caused the instability. remove it and there is a big change the cpu could run at 500mhz instead of 400. it's rated to do 500. (yes power consumption would go up - but it'd only be up while its on. when suspended it wont matter). data flowing through it? There's one neighbor unanswered thread with a render on the device - and this will then limit what you can render. evas can't be fully accelerated by the glamo. it has too many opretations. a bit like asking why quake4 is slow on a a voodoo2. it does much mroe than the old gfx chip ever was designed to do and you will hit software fallbacks. evas has multiple engnines. software (which is what is used - the 16bit renderer as opposed to the full 32bit one). it has xrender - if xrender were fully accelerated this should be better, but glamo cannot fully accelerate all the ops evas uses, so... it will rely on software fallbacks. thus slow down. my bet is you'll end up same speed as the pure software engine, or worse. aftera bunch of hard work you'll have gone nowhere. evas also has a gl and gles2 engine - but thats no use on glamo. it's gles1.1 and very limited (from memory texture size is 256x256 which is pretty useless for 2d as most data you deal with breaks these bounds). question on how to start the kernel with qvga resolution. Aside of no need to do that - just configure x for qgva. :) this, what can be reduced, for example amount of available colours (256 or even 16)? And if this [too] low throughput only of video memory channel? 256 won't help. it increases complexity and really reduces display quality through the floor. the best best is qvga 16bpp. its simple. it doesn't require any hard work. it is actually the most common resolution for most phones and devices out there so the software is more portable if you work on that (and then higher). but... in the past everyone has moaned and complained and refused to use it, and insisted on their vga resolution... and then complained about speed. if people don't believe me that the gta02 is just plain a bad bit of hardware and you have few choices here's some examples. here'es an ooold efl demo app i did: http://www.rasterman.com/files/eem.avi and here it is on a 206mhz ipaq 3660 with 64m ram and 16m flash, qvga(240x320). it's from like 2001/2002 (from memory). its ancient. and watch it run evas: http://www.rasterman.com/files/eem-live.avi here is something i videoed today. it's an samsung s3c6410 at 667 mhz, 128m ram, and 800x480 (higher res than gta02): http://www.rasterman.com/files/ello-elementary-smartq5.mp4 everywhere i look... theres much better hardware. if you look at performance vs age of hardware (when it was released) gta02 is almost at the bottom of the pile. :( you simply have a bad piece of hardware if you want graphics performance. as soon as you acknowledge that and either downgrade the device resolution for example to bring it in line with its performance, or just use different hardware, the better life will be :) -- - 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 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Tuxbrain first anniversary
David, same as the others, congratulations! I think we will hear a lot more from tuxbrain in coming years... :-) Wolfgang On Mon, Oct 26, 2009 at 12:26:52PM +0100, David Reyes Samblas Martinez wrote: Dear all, Is for me a pleasure and proud to announce this week Tuxbrain the company that has born thanks to the inspiration of Openmoko is now one year old :) a good moment to thanks all that make us enjoy this first year of live, those who has make us learn, and of course to all that had buy something there :) To celebrate it we have down the price of the Frerrunner A6+[1] My only wish when I blow the candle is to enjoy next year as much as this one. A big Thank you and and a bigger hug to you all [1]http://www.tuxbrain.net/en/content/tuxbrain-first-anniversary David Reyes Samblas Martinez http://www.tuxbrain.com Open ultraportable embedded solutions Openmoko, Openpandora, Arduino 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 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] Accelerometers
Al Johnson wrote: On Sunday 25 October 2009, Ivo van den Maagdenberg wrote: 2009/10/25 Frederik Sdun frederik.s...@googlemail.com * Iain B. Findleton ifindle...@videotron.ca [25.10.2009 13:19]: Where is the device control for the accelerometers on SHR? Was /sys/bus/platform/devices/ls302dl.1/2 or some such on the OM distros. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community here's an overview of the sysfs paths: http://wiki.openmoko.org/wiki/GTA02_sysfs#Accelerometers No luck. The paths specified on the page you refer to do not exits on the SHR release. r...@om-gta02 ~ $ ls -a /sys/devices/platform/ .physmap-flash.0 s3c2440-sdi s3c-ohci .. powers3c2440-uart.0 soc-audio gta02-led.0 s3c2410-iis s3c2440-uart.1 uevent gta02-pm-wlan.0 s3c2410-wdt s3c2440-uart.2 neo1973-memconfig.0 s3c2440-i2c s3c2440-usbgadget neo1973-version.0s3c2440-nand s3c24xx_pwm.0 http://wiki.openmoko.org/wiki/Accelerometer_data_retrieval#The_.2Fsys_inter facedoes neither point to the right direction in the SHR case. Any other suggestions how to manipulate the accelerometers? This is a case of a wiki page in need of an update because it only makes sense if you already know what it means ;-) Note the first line on the page: NOTE: These only apply to Linux kernel 2.6.24, 2.6.28 has different paths (see below) The #Accelerometers link you were given points to the paths for 2.6.24 which have explanations, but aren't used by any current distro. Below that is a section that says what each path from 2.6.24 changed to in 2.6.28 and later, and are used by all current distros. Scroll to the very end of the page and you'll find the answer you were looking for. Well, unfortunately, the information found where you indicate it to be does not in fact point to the required lis302dl control entries. Is it possible that the appropriate module needs to be loaded? Anyboy out there do any work on accelerometers using SHR? ___ 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: Centralization of graphical awesomeness
On Mon, 26 Oct 2009 12:23:51 + Vasco Névoa vasco.ne...@sapo.pt said: Downgrading to QVGA is something that should have been done a long time ago. There's no point in trying to force a badly designed system. How do we do it? Which files must be changed? last i checked... 1. xmd-line option to xglamo (kdrive) server to select it, 2. xrandr to runtime select it. note that toushcreen driver didn't account for res change so ts coords were still assuming 480x640 - this is a small fix needed for it to be totally usable. not sure if this was ever fixed, but if it hasn't been - this is a good indicator of how no one has bothered with qvga. thus the complaints. try it. you'll find it significantly faster. see videos below - 206mhz ipaq3660.. smooth. Citando Carsten Haitzler ras...@rasterman.com: On Mon, 26 Oct 2009 13:57:27 +0300 Evgeniy Karyakin anthropophag...@gmail.com said: 2009/10/26 Carsten Haitzler ras...@rasterman.com: you want speed? you will need to give up something. if you still want it to look nice, then drop pixels. its the simplest and easiest solution. its the right resolution for that cpu anyway. the glamo will still hurt you, but not as much. I'm sure everybody who has any professional connections with Freerunner+Glamo development already took all possible measures to solve this problem. But what concrete steps were taken to ease Glamo bottleneck? If its throughput is so narrow, can we lower amount of none. it's a hardware issue. you simply cant read or write to video ram faster than that. andy tried timing stuff all that happened was instability from memory. glamo is most likely also the cause for the cpu runnig at 400 not 500mhz. the extra load on the memory bus (because glamo is hooked there externally providing another addressable chip) probably caused the instability. remove it and there is a big change the cpu could run at 500mhz instead of 400. it's rated to do 500. (yes power consumption would go up - but it'd only be up while its on. when suspended it wont matter). data flowing through it? There's one neighbor unanswered thread with a render on the device - and this will then limit what you can render. evas can't be fully accelerated by the glamo. it has too many opretations. a bit like asking why quake4 is slow on a a voodoo2. it does much mroe than the old gfx chip ever was designed to do and you will hit software fallbacks. evas has multiple engnines. software (which is what is used - the 16bit renderer as opposed to the full 32bit one). it has xrender - if xrender were fully accelerated this should be better, but glamo cannot fully accelerate all the ops evas uses, so... it will rely on software fallbacks. thus slow down. my bet is you'll end up same speed as the pure software engine, or worse. aftera bunch of hard work you'll have gone nowhere. evas also has a gl and gles2 engine - but thats no use on glamo. it's gles1.1 and very limited (from memory texture size is 256x256 which is pretty useless for 2d as most data you deal with breaks these bounds). question on how to start the kernel with qvga resolution. Aside of no need to do that - just configure x for qgva. :) this, what can be reduced, for example amount of available colours (256 or even 16)? And if this [too] low throughput only of video memory channel? 256 won't help. it increases complexity and really reduces display quality through the floor. the best best is qvga 16bpp. its simple. it doesn't require any hard work. it is actually the most common resolution for most phones and devices out there so the software is more portable if you work on that (and then higher). but... in the past everyone has moaned and complained and refused to use it, and insisted on their vga resolution... and then complained about speed. if people don't believe me that the gta02 is just plain a bad bit of hardware and you have few choices here's some examples. here'es an ooold efl demo app i did: http://www.rasterman.com/files/eem.avi and here it is on a 206mhz ipaq 3660 with 64m ram and 16m flash, qvga(240x320). it's from like 2001/2002 (from memory). its ancient. and watch it run evas: http://www.rasterman.com/files/eem-live.avi here is something i videoed today. it's an samsung s3c6410 at 667 mhz, 128m ram, and 800x480 (higher res than gta02): http://www.rasterman.com/files/ello-elementary-smartq5.mp4 everywhere i look... theres much better hardware. if you look at performance vs age of hardware (when it was released) gta02 is almost at the bottom of the pile. :( you simply have a bad piece of hardware if you want graphics performance. as soon as you acknowledge that and either downgrade the device resolution for example to bring it in line with its performance, or just use different hardware, the better life will be
Re: Centralization of graphical awesomeness
Am Dienstag, den 27.10.2009, 00:11 +1100 schrieb Carsten Haitzler: On Mon, 26 Oct 2009 12:23:51 + Vasco Névoa vasco.ne...@sapo.pt said: Downgrading to QVGA is something that should have been done a long time ago. There's no point in trying to force a badly designed system. How do we do it? Which files must be changed? last i checked... 1. xmd-line option to xglamo (kdrive) server to select it, 2. xrandr to runtime select it. note that toushcreen driver didn't account for res change so ts coords were still assuming 480x640 - this is a small fix needed for it to be totally usable. not sure if this was ever fixed, but if it hasn't been - this is a good indicator of how no one has bothered with qvga. thus the complaints. try it. you'll find it significantly faster. see videos below - 206mhz ipaq3660.. smooth. I tried to got to qvga for graphics performance testing about a week ago. This is needed (tested on SHR's 2.6.29-rc3): echo qvga-normal /sys/bus/spi/devices/spi2.0/state xrandr -s 240x320 To return to vga: echo normal /sys/bus/spi/devices/spi2.0/state xrandr -s 480x640 Problems: - SHR's pin entry dialogue and shr-today have a too large font so they're hard to read, but still (kinda) usable, didn't try other apps http://scap.linuxtogo.org/files/3a88e6beb3253362d14384ec3f3a3dfe.png (yes, that's the whole screen) - graphics in general are far too light, most colors become whiteish - colored stripes horizontally over the whole display, but are invisible on screenshots (naturally) - the same as above, but photographed: http://d-a300.selfip.net/files/shr-today-qvga.jpg If our software would run well in that resolution and if the display would make it (better than now), I would clearly prefer qvga for performance. I was about to write a little game, but that's impossible with that horrible vga rendering performance. -- Marcel ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] Accelerometers
Al Johnson wrote: On Sunday 25 October 2009, Ivo van den Maagdenberg wrote: 2009/10/25 Frederik Sdun frederik.s...@googlemail.com * Iain B. Findleton ifindle...@videotron.ca [25.10.2009 13:19]: Where is the device control for the accelerometers on SHR? Was /sys/bus/platform/devices/ls302dl.1/2 or some such on the OM distros. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community here's an overview of the sysfs paths: http://wiki.openmoko.org/wiki/GTA02_sysfs#Accelerometers No luck. The paths specified on the page you refer to do not exits on the SHR release. r...@om-gta02 ~ $ ls -a /sys/devices/platform/ .physmap-flash.0 s3c2440-sdi s3c-ohci .. powers3c2440-uart.0 soc-audio gta02-led.0 s3c2410-iis s3c2440-uart.1 uevent gta02-pm-wlan.0 s3c2410-wdt s3c2440-uart.2 neo1973-memconfig.0 s3c2440-i2c s3c2440-usbgadget neo1973-version.0s3c2440-nand s3c24xx_pwm.0 http://wiki.openmoko.org/wiki/Accelerometer_data_retrieval#The_.2Fsys_inter facedoes neither point to the right direction in the SHR case. Any other suggestions how to manipulate the accelerometers? This is a case of a wiki page in need of an update because it only makes sense if you already know what it means ;-) Note the first line on the page: NOTE: These only apply to Linux kernel 2.6.24, 2.6.28 has different paths (see below) The #Accelerometers link you were given points to the paths for 2.6.24 which have explanations, but aren't used by any current distro. Below that is a section that says what each path from 2.6.24 changed to in 2.6.28 and later, and are used by all current distros. Scroll to the very end of the page and you'll find the answer you were looking for. Okay, in what I can only assume is an effort to make finding the lis302dl (Accelerometer) control interface easier, the path on the SHR distro I have installed is: /sys/class/i2c-adapter/i2c-0/0-0073/spi_s3c24xx_gpio.0/spi3.0 /sys/class/i2c-adapter/i2c-0/0-0073/spi_s3c24xx_gpio.0/spi3.1 where the .0 and .1 directories refer to the respective accelerometer devices. An alternative path is: /sys/bus/spi/drivers/lis302dl/spi3.0 /sys/bus/spi/drivers/lis302dl/spi3.1 I don't know who has permission to modify the wiki page, but someone who can do so may wish to add this information on the #Accelerometers page. Here is the output of `cat /etc/shr-version` on my machine: Tag Name: mv-packages-to-recipes-pre VERSION: 02fe96061411de095776edd314d9ae551e1b2f22 Branch: shr/import Build Host: opmbuild Time Stamp: Sun, 06 Sep 2009 16:34:21 +0200 ___ 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: Centralization of graphical awesomeness
On Mon, 26 Oct 2009 14:53:50 +0100 Marcel tan...@googlemail.com said: Am Dienstag, den 27.10.2009, 00:11 +1100 schrieb Carsten Haitzler: On Mon, 26 Oct 2009 12:23:51 + Vasco Névoa vasco.ne...@sapo.pt said: Downgrading to QVGA is something that should have been done a long time ago. There's no point in trying to force a badly designed system. How do we do it? Which files must be changed? last i checked... 1. xmd-line option to xglamo (kdrive) server to select it, 2. xrandr to runtime select it. note that toushcreen driver didn't account for res change so ts coords were still assuming 480x640 - this is a small fix needed for it to be totally usable. not sure if this was ever fixed, but if it hasn't been - this is a good indicator of how no one has bothered with qvga. thus the complaints. try it. you'll find it significantly faster. see videos below - 206mhz ipaq3660.. smooth. I tried to got to qvga for graphics performance testing about a week ago. This is needed (tested on SHR's 2.6.29-rc3): echo qvga-normal /sys/bus/spi/devices/spi2.0/state xrandr -s 240x320 To return to vga: echo normal /sys/bus/spi/devices/spi2.0/state xrandr -s 480x640 Problems: - SHR's pin entry dialogue and shr-today have a too large font so they're hard to read, but still (kinda) usable, didn't try other apps http://scap.linuxtogo.org/files/3a88e6beb3253362d14384ec3f3a3dfe.png (yes, that's the whole screen) - graphics in general are far too light, most colors become whiteish - colored stripes horizontally over the whole display, but are invisible on screenshots (naturally) - the same as above, but photographed: http://d-a300.selfip.net/files/shr-today-qvga.jpg If our software would run well in that resolution and if the display would make it (better than now), I would clearly prefer qvga for performance. I was about to write a little game, but that's impossible with that horrible vga rendering performance. did dpi get adjusted too? still 285dpi? check e's scaling settings. it can adapt to dpi if it is set up to do so. it also has a manual scale switch to set it to whatever u want. whatever e sets, elementary inherits too, unless the theme has been done in such a way not to allow scaling (the default does). custom written edje files with font may also not scale for the same reason a different elm theme may not. if things are done right it should just magically work on qvga and look wonderful. as for display artifacts - maybe its a refresh issue or a screen timing issue. not sure. i remember those screen artifacts long ago (like before freerunner was even released). looks like nothing has been fixed since :) -- - 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: ffalarms 0.3 -- recurring alarms
On 26 Oct 2009, at 08:47, Christ van Willegen wrote: ... I've noticed that when the alarm sounds, the FR turns off after some time. I've never needed to depend on the alarm, but it's not nice when you alarm clock itself falls asleep ;-) Is that fixable (on SHR-U)? Dear Boss, This is why I'm late for work. Clearly this morning's tardiness is upstream's fault. Please file a bug with them. I am marking your complaint about my late arrival in the office as CAN'T FIX. Stroller. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
carriers evolving in the U.S.
Yes, but will any of this benefit Freerunner users? http://market-ticker.org/archives/1542-Mobile-Phone-Wars!.html ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Am Dienstag, den 27.10.2009, 01:02 +1100 schrieb Carsten Haitzler: On Mon, 26 Oct 2009 14:53:50 +0100 Marcel tan...@googlemail.com said: Am Dienstag, den 27.10.2009, 00:11 +1100 schrieb Carsten Haitzler: On Mon, 26 Oct 2009 12:23:51 + Vasco Névoa vasco.ne...@sapo.pt said: Downgrading to QVGA is something that should have been done a long time ago. There's no point in trying to force a badly designed system. How do we do it? Which files must be changed? last i checked... 1. xmd-line option to xglamo (kdrive) server to select it, 2. xrandr to runtime select it. note that toushcreen driver didn't account for res change so ts coords were still assuming 480x640 - this is a small fix needed for it to be totally usable. not sure if this was ever fixed, but if it hasn't been - this is a good indicator of how no one has bothered with qvga. thus the complaints. try it. you'll find it significantly faster. see videos below - 206mhz ipaq3660.. smooth. I tried to got to qvga for graphics performance testing about a week ago. This is needed (tested on SHR's 2.6.29-rc3): echo qvga-normal /sys/bus/spi/devices/spi2.0/state xrandr -s 240x320 To return to vga: echo normal /sys/bus/spi/devices/spi2.0/state xrandr -s 480x640 Problems: - SHR's pin entry dialogue and shr-today have a too large font so they're hard to read, but still (kinda) usable, didn't try other apps http://scap.linuxtogo.org/files/3a88e6beb3253362d14384ec3f3a3dfe.png (yes, that's the whole screen) - graphics in general are far too light, most colors become whiteish - colored stripes horizontally over the whole display, but are invisible on screenshots (naturally) - the same as above, but photographed: http://d-a300.selfip.net/files/shr-today-qvga.jpg If our software would run well in that resolution and if the display would make it (better than now), I would clearly prefer qvga for performance. I was about to write a little game, but that's impossible with that horrible vga rendering performance. did dpi get adjusted too? still 285dpi? check e's scaling settings. it can adapt to dpi if it is set up to do so. it also has a manual scale switch to set it to whatever u want. whatever e sets, elementary inherits too, unless the theme has been done in such a way not to allow scaling (the default does). custom written edje files with font may also not scale for the same reason a different elm theme may not. if things are done right it should just magically work on qvga and look wonderful. as for display artifacts - maybe its a refresh issue or a screen timing issue. not sure. i remember those screen artifacts long ago (like before freerunner was even released). looks like nothing has been fixed since :) A killall -HUP enlightenment at least fixed scaling for pure E stuff. shr-today also looks okay, but the flaunch bar is too large. Haven't tested anything else since the touchable area is reduced to about the upper left half of the screen, so it's unusable. And still these timing-things... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
2009/10/25 Łukasz Pankowski lukp...@o2.pl: Hi I have just released ffalarms 0.3, it adds recurring alarms, please test it before depending on it. For me the most missing feature now is being able to edit the alarms and postponing in the acknowledge window. Ideas and comments are welcome. ive just thought of something. instead of using the enlighten fullscreen mode. which kills the UI if the keyboard is set to none. is there any way you could borrow the render-above-all bit of code from literki? if you run literki you can position the keyboard above the menu bar, thus emulating the fullscreen mode. would make for a much more stable package while we wait for a working enlightenment. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
E17 default scaling factor
Moin, I played around with E's scaling too much, can someone tell me the default dpi set in E's scaling settings? Setting 285dpi gives a far too small gui... -- Marcel ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: E17 default scaling factor
On Mon, Oct 26, 2009 at 7:57 AM, Marcel tan...@googlemail.com wrote: Moin, I played around with E's scaling too much, can someone tell me the default dpi set in E's scaling settings? Setting 285dpi gives a far too small gui... might not help but i know its less then 177dpi [what i run] did you do this from the gui options or via a command? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: E17 default scaling factor
Am Montag 26 Oktober 2009 16:08:26 schrieb jeremy jozwik: On Mon, Oct 26, 2009 at 7:57 AM, Marcel tan...@googlemail.com wrote: Moin, I played around with E's scaling too much, can someone tell me the default dpi set in E's scaling settings? Setting 285dpi gives a far too small gui... might not help but i know its less then 177dpi [what i run] did you do this from the gui options or via a command? The slider in the E wrench is set to 140dpi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] qmplayer (was [QtExtended] Leonardo's keyboard)
giacomo giotti mariani wrote: -is it possible, using Qmplayer in normal mode (i.e. non in full screen), to have the video centered instead of in the up-left corner? If you figure out parameter for mplayer to do this, then i can implement this in qmplayer. Radek Hello, after some time, I figured out that the required parameter are in the form: -geometry xoffset%:yoffset% with 0%:0% the upper corner on the left. Cheers -- /_\ The ASCII Per comunicare in modo riservato: \_/ Ribbon Campaign gpg --keyserver pool.sks-keyservers.net \ X Against HTML--recv-keys 20611EAD /_\ Email! -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: E17 default scaling factor
Am Montag, den 26.10.2009, 16:19 +0100 schrieb Thomas Zimmermann: Am Montag 26 Oktober 2009 16:08:26 schrieb jeremy jozwik: On Mon, Oct 26, 2009 at 7:57 AM, Marcel tan...@googlemail.com wrote: Moin, I played around with E's scaling too much, can someone tell me the default dpi set in E's scaling settings? Setting 285dpi gives a far too small gui... might not help but i know its less then 177dpi [what i run] did you do this from the gui options or via a command? The slider in the E wrench is set to 140dpi The 4th column of icons fits from 141dpi on. Thanks! -- Marcel ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Vasco Névoa wrote: Downgrading to QVGA is something that should have been done a long time ago. There's no point in trying to force a badly designed system. How do we do it? Which files must be changed? Citando Carsten Haitzler ras...@rasterman.com: On Mon, 26 Oct 2009 13:57:27 +0300 Evgeniy Karyakin anthropophag...@gmail.com said: 2009/10/26 Carsten Haitzler ras...@rasterman.com: you want speed? you will need to give up something. if you still want it to look nice, then drop pixels. its the simplest and easiest solution. its the right resolution for that cpu anyway. the glamo will still hurt you, but not as much. I'm sure everybody who has any professional connections with Freerunner+Glamo development already took all possible measures to solve this problem. But what concrete steps were taken to ease Glamo bottleneck? If its throughput is so narrow, can we lower amount of none. it's a hardware issue. you simply cant read or write to video ram faster than that. andy tried timing stuff all that happened was instability from memory. glamo is most likely also the cause for the cpu runnig at 400 not 500mhz. the extra load on the memory bus (because glamo is hooked there externally providing another addressable chip) probably caused the instability. remove it and there is a big change the cpu could run at 500mhz instead of 400. it's rated to do 500. (yes power consumption would go up - but it'd only be up while its on. when suspended it wont matter). data flowing through it? There's one neighbor unanswered thread with a render on the device - and this will then limit what you can render. evas can't be fully accelerated by the glamo. it has too many opretations. a bit like asking why quake4 is slow on a a voodoo2. it does much mroe than the old gfx chip ever was designed to do and you will hit software fallbacks. evas has multiple engnines. software (which is what is used - the 16bit renderer as opposed to the full 32bit one). it has xrender - if xrender were fully accelerated this should be better, but glamo cannot fully accelerate all the ops evas uses, so... it will rely on software fallbacks. thus slow down. my bet is you'll end up same speed as the pure software engine, or worse. aftera bunch of hard work you'll have gone nowhere. evas also has a gl and gles2 engine - but thats no use on glamo. it's gles1.1 and very limited (from memory texture size is 256x256 which is pretty useless for 2d as most data you deal with breaks these bounds). question on how to start the kernel with qvga resolution. Aside of no need to do that - just configure x for qgva. :) this, what can be reduced, for example amount of available colours (256 or even 16)? And if this [too] low throughput only of video memory channel? 256 won't help. it increases complexity and really reduces display quality through the floor. the best best is qvga 16bpp. its simple. it doesn't require any hard work. it is actually the most common resolution for most phones and devices out there so the software is more portable if you work on that (and then higher). but... in the past everyone has moaned and complained and refused to use it, and insisted on their vga resolution... and then complained about speed. if people don't believe me that the gta02 is just plain a bad bit of hardware and you have few choices here's some examples. here'es an ooold efl demo app i did: http://www.rasterman.com/files/eem.avi and here it is on a 206mhz ipaq 3660 with 64m ram and 16m flash, qvga(240x320). it's from like 2001/2002 (from memory). its ancient. and watch it run evas: http://www.rasterman.com/files/eem-live.avi here is something i videoed today. it's an samsung s3c6410 at 667 mhz, 128m ram, and 800x480 (higher res than gta02): http://www.rasterman.com/files/ello-elementary-smartq5.mp4 everywhere i look... theres much better hardware. if you look at performance vs age of hardware (when it was released) gta02 is almost at the bottom of the pile. :( you simply have a bad piece of hardware if you want graphics performance. as soon as you acknowledge that and either downgrade the device resolution for example to bring it in line with its performance, or just use different hardware, the better life will be :) I agree with you Vasco, (about switching to QVGA) for the most part, but a long time ago when Carsten asked this question, much of the community responded that they wanted to keep the high res screen. Things like viewing webpages at 640x480 instead of qvga, viewing maps, etc. were cited as useful and important. Anyway, I agree we should make QVGA work well, and I would use it for most apps. We should also keep in mind ways to allow use of the high res screen -- maybe picking certain apps (like browsers) that could switch to VGA automatically, and making sure the transition between resolutions is a smooth, fast, and automatic
Re: Multiple Distro's..
2009/10/26 Paul Fertser fercer...@gmail.com: Neil Jerram neiljer...@googlemail.com writes: It is very easy to run two: one on the internal flash and one of the first partition of the SD card, with Qi as the NOR bootloader. Then pressing the power button alone will boot the SD distribution, and pressing AUX+power will allow you to boot the NAND distribution. 1. Qi can't be installed to NOR. Yeah, sorry, I meant NAND there. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Anyway, I agree we should make QVGA work well, and I would use it for most apps. We should also keep in mind ways to allow use of the high res screen -- maybe picking certain apps (like browsers) that could switch to VGA automatically, and making sure the transition between resolutions is a smooth, fast, and automatic (where desired). Here's an idea I'm not sure I've heard before and I think it should be pointed out. When there was discussion whether to use VGA or move over to QVGA I was for the higher resolution, because viewing maps, terminal, pdfs and browsing at higher resolution was more important for me then speed. If however we could have everything at QVGA by default and change smoothly to VGA when required we could have all of the good and none of the bad. Sounds very good to me. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
Christ van Willegen cvwille...@gmail.com writes: Dzen dobry Łukasz, I've noticed that when the alarm sounds, the FR turns off after some time. I've never needed to depend on the alarm, but it's not nice when you alarm clock itself falls asleep ;-) Is that fixable (on SHR-U)? Maybe you could resource-lock the CPU for that. Dzień dobry Christ That is strange, ffalarms (since 0.2.3) does request CPU resource, that is before starting the alarm you should observe CPU is not ,,enabled'' (unless other program requested it): $ mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage org.freesmartphone.Usage.GetResourceState CPU 2/dev/null False If you start an alarm, for example with: $ ffalarms -s now you should observe that ffalarms requested CPU resource $ mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage org.freesmartphone.Usage.GetResourceState CPU 2/dev/null True and so the system should not suspend. Does it give false for you? Łukasz Christ van Willegen ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
Al Johnson openm...@mazikeen.demon.co.uk writes: On Monday 26 October 2009, Christ van Willegen wrote: Dzen dobry Łukasz, I've noticed that when the alarm sounds, the FR turns off after some time. I've never needed to depend on the alarm, but it's not nice when you alarm clock itself falls asleep ;-) Is that fixable (on SHR-U)? Maybe you could resource-lock the CPU for that. I would prefer it to go to sleep again and try later. I don't want my alarm clock to run its battery flat because I slept through it, or my phone too run flat because I forgot to cancel an alarm. It should not suspend until it plays the alarm to the end, that is and should be the proper behavior. (You can configure the number of repetitions if you think it plays to long: in default configuration it is around 5 minutes). On the other hand it is true that if you do not acknowledge the alarm it currently just suspends and does nothing with it. It could retry after let say 10 minutes (which would be configurable) and try it let say five times and only then give up, that is a reasonable feature request. I will add it to my TODO list. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Where do I discuss these Ideas??
Aditya Gandhi schrieb: Hi guiys I'm back, I have made a Board with which connects to my pc via a USB which wirelessly controls a robot (Simple left ,right ,forward and reverse using tank mechanism for turning no steering for my robot) It uses a firmware to emulate a true usb device and the computer detects it as a custom usb class device for which only libusb is needed to work. Actually the whole Idea is not mine, took a circuit and firmware available and made it wireless. It also has a qt front-end on the pc to control the robot. The Board is based on ATmega8 , ht12e/ht12d (encoder Decoder), L298 motor driver and a 434 MHz ASK RFmodule. The BOM is under 17$ approx. Can you show some fotos ? What role does moko play in it ? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
Jeffrey Ratcliffe jeffrey.ratcli...@gmail.com writes: On Mon, Oct 26, 2009 at 02:07:32AM +0100, Łukasz Pankowski wrote: - add support for recurring alarms, attaching messages to alarms, and choosing alarm date from a calendar - add configuration option for alarm volume, alarm_script and alsa_state Brilliant - I can almost throw my old phone away now. I'm just missing one last feature - I would love an option to vibrate instead of ring - ringing wakes the rest of my family, whilst vibrate just wakes me. :-) I may add vibration support in the next version. For now you can do that by setting fancy alarm player in ~/.ffalarmsrc: [alarm] volume=-1 player=sh -c 'for x in `seq 1 10`; do kill -CHLD $PPID || exit; mdbus -s org.freesmartphone.odeviced /org/freesmartphone/Device/LED/neo1973_vibrator org.freesmartphone.Device.LED.BlinkSeconds 2 100 100; sleep 10; done' the kill command is to test the parent process is still running as killing the this sh process with sig TERM for some reason does not work (may be you now a better way to do that?) for explanation of volume=-1 see [1] One way to support it would be to make ffalarms aware of phone profiles, so that if the profile is Silent or Vibrate than it Vibrates instead of playing the alarm (and may be start playing after a minute). [1] http://ffalarms.projects.openmoko.org/#configuration Regards Jeff ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
lukp...@o2.pl (Łukasz Pankowski) writes: Jeffrey Ratcliffe jeffrey.ratcli...@gmail.com writes: On Mon, Oct 26, 2009 at 02:07:32AM +0100, Łukasz Pankowski wrote: - add support for recurring alarms, attaching messages to alarms, and choosing alarm date from a calendar - add configuration option for alarm volume, alarm_script and alsa_state Brilliant - I can almost throw my old phone away now. I'm just missing one last feature - I would love an option to vibrate instead of ring - ringing wakes the rest of my family, whilst vibrate just wakes me. :-) I may add vibration support in the next version. For now you can do that by setting fancy alarm player in ~/.ffalarmsrc: [alarm] volume=-1 player=sh -c 'for x in `seq 1 10`; do kill -CHLD $PPID || exit; mdbus -s org.freesmartphone.odeviced /org/freesmartphone/Device/LED/neo1973_vibrator org.freesmartphone.Device.LED.BlinkSeconds 2 100 100; sleep 10; done' Of course you can do it simpler using repeat instead of shell for loop, than this kill-hack is not needed: [alarm] repeat=10 player=sh -c 'mdbus -s org.freesmartphone.odeviced /org/freesmartphone/Device/LED/neo1973_vibrator org.freesmartphone.Device.LED.BlinkSeconds 2 100 100; sleep 10' volume=-1 the kill command is to test the parent process is still running as killing the this sh process with sig TERM for some reason does not work (may be you now a better way to do that?) for explanation of volume=-1 see [1] One way to support it would be to make ffalarms aware of phone profiles, so that if the profile is Silent or Vibrate than it Vibrates instead of playing the alarm (and may be start playing after a minute). [1] http://ffalarms.projects.openmoko.org/#configuration Regards Jeff ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Dear Carsten, E is nice thing, but it look like highly unoptimized. Yes, freerunner device is slow, but it is embedded device, and it's impossible to continue kicking glamo which is already dead, as only reason of slowness. People with GTA01 have no glamo and that? Is it better? As far as I know - not. http://www.rasterman.com/files/ello-elementary-smartq5.mp4 Thank you for videos, but on high-resolution one we can see exactly same slowness as on FreeRunner - exactly! See how top bar slides out on close of clock and button test - exacly as on my FreeRunner. Look how slow scroll is, again as on FreeRunner! That is that 7mb? Bandwidth we can use to update glamo contents? We can count that 7mb if 10 fully updated frames for 640x480 at 16bit? This looks much more that enough. Also, I installed Qtv14 (thanks to Radek for that distribution), and that I see? I is fast enought, scrolls fast, react fast, and so on. So, E and E's programs just need optimizations. Openembedded in all sucks, as it brings no benefit (same glibc and kernel) with bunch of drawbacks - no easy way to compile for it, so (for me) it's uneasy to figure out that's going on with E. No oprofile where. I wish E to be faster! Gennady. В Пнд, 26/10/2009 в 22:51 +1100, Carsten Haitzler пишет: On Mon, 26 Oct 2009 13:57:27 +0300 Evgeniy Karyakin anthropophag...@gmail.com said: 2009/10/26 Carsten Haitzler ras...@rasterman.com: you want speed? you will need to give up something. if you still want it to look nice, then drop pixels. its the simplest and easiest solution. its the right resolution for that cpu anyway. the glamo will still hurt you, but not as much. I'm sure everybody who has any professional connections with Freerunner+Glamo development already took all possible measures to solve this problem. But what concrete steps were taken to ease Glamo bottleneck? If its throughput is so narrow, can we lower amount of none. it's a hardware issue. you simply cant read or write to video ram faster than that. andy tried timing stuff all that happened was instability from memory. glamo is most likely also the cause for the cpu runnig at 400 not 500mhz. the extra load on the memory bus (because glamo is hooked there externally providing another addressable chip) probably caused the instability. remove it and there is a big change the cpu could run at 500mhz instead of 400. it's rated to do 500. (yes power consumption would go up - but it'd only be up while its on. when suspended it wont matter). data flowing through it? There's one neighbor unanswered thread with a render on the device - and this will then limit what you can render. evas can't be fully accelerated by the glamo. it has too many opretations. a bit like asking why quake4 is slow on a a voodoo2. it does much mroe than the old gfx chip ever was designed to do and you will hit software fallbacks. evas has multiple engnines. software (which is what is used - the 16bit renderer as opposed to the full 32bit one). it has xrender - if xrender were fully accelerated this should be better, but glamo cannot fully accelerate all the ops evas uses, so... it will rely on software fallbacks. thus slow down. my bet is you'll end up same speed as the pure software engine, or worse. aftera bunch of hard work you'll have gone nowhere. evas also has a gl and gles2 engine - but thats no use on glamo. it's gles1.1 and very limited (from memory texture size is 256x256 which is pretty useless for 2d as most data you deal with breaks these bounds). question on how to start the kernel with qvga resolution. Aside of no need to do that - just configure x for qgva. :) this, what can be reduced, for example amount of available colours (256 or even 16)? And if this [too] low throughput only of video memory channel? 256 won't help. it increases complexity and really reduces display quality through the floor. the best best is qvga 16bpp. its simple. it doesn't require any hard work. it is actually the most common resolution for most phones and devices out there so the software is more portable if you work on that (and then higher). but... in the past everyone has moaned and complained and refused to use it, and insisted on their vga resolution... and then complained about speed. if people don't believe me that the gta02 is just plain a bad bit of hardware and you have few choices here's some examples. here'es an ooold efl demo app i did: http://www.rasterman.com/files/eem.avi and here it is on a 206mhz ipaq 3660 with 64m ram and 16m flash, qvga(240x320). it's from like 2001/2002 (from memory). its ancient. and watch it run evas: http://www.rasterman.com/files/eem-live.avi here is something i videoed today. it's an samsung s3c6410 at 667 mhz, 128m ram, and 800x480 (higher res than gta02): http://www.rasterman.com/files/ello-elementary-smartq5.mp4 everywhere i look... theres much better
Re: Centralization of graphical awesomeness
Would this only work with SHR/QtMoko, etc, or would this also work on Android? I guess my question is, can this be solved from the kernel, or is it done through the distribution itself? -Tonym Yogiz wrote: Anyway, I agree we should make QVGA work well, and I would use it for most apps. We should also keep in mind ways to allow use of the high res screen -- maybe picking certain apps (like browsers) that could switch to VGA automatically, and making sure the transition between resolutions is a smooth, fast, and automatic (where desired). Here's an idea I'm not sure I've heard before and I think it should be pointed out. When there was discussion whether to use VGA or move over to QVGA I was for the higher resolution, because viewing maps, terminal, pdfs and browsing at higher resolution was more important for me then speed. If however we could have everything at QVGA by default and change smoothly to VGA when required we could have all of the good and none of the bad. Sounds very good to me. ___ 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: Where do I discuss these Ideas??
As of now moko doesn't play anyrole in it... But I have made a hardware which I wish to connect to make and develop further I wish to attach sensors to FR maybe a webcam along with my robot controller , and first task is to just avoid obstacles . One more Idea I wish to implement is to get data from the accelerometers of the FR and guess the movement of a person and the robot to follow it. The link to the pics is: http://www.flickr.com/photos/29046...@n03/sets/72157622544758011/ On the robot there are two board one which is the L298 board to control the motor, it is a simple board with l298, 16 diodes, one 5v regulator and capacitors. The other board is the 434Mhz receiver along with ht12d decoder, it controls the input to the robot, basically there is brain required here, a simple circuit with no microcontroller. The board which is on the ground is the board with atmega8, and a rf transmitter of ask type 434 Mhz. with a ht12e encoder to encode the data from pins. Which again is fairly simple. It uses libusb to connect to application on any platform (unix, linux, windows etc.) basic design from http://andreas.goelzer.de/usbmot Now that I'm done with this I'll start working with freerunner when I get the device tomorrow hopefully, the courier guys suck in india. On Tue, Oct 27, 2009 at 12:45 AM, Matthias Huber matthias.hu...@wollishausen.de wrote: Aditya Gandhi schrieb: Hi guiys I'm back, I have made a Board with which connects to my pc via a USB which wirelessly controls a robot (Simple left ,right ,forward and reverse using tank mechanism for turning no steering for my robot) It uses a firmware to emulate a true usb device and the computer detects it as a custom usb class device for which only libusb is needed to work. Actually the whole Idea is not mine, took a circuit and firmware available and made it wireless. It also has a qt front-end on the pc to control the robot. The Board is based on ATmega8 , ht12e/ht12d (encoder Decoder), L298 motor driver and a 434 MHz ASK RFmodule. The BOM is under 17$ approx. Can you show some fotos ? What role does moko play in it ? ___ 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: Where do I discuss these Ideas??
http://www.flickr.com/photos/29046...@n03/sets/72157622544758011/show/ On Tue, Oct 27, 2009 at 1:56 AM, Aditya Gandhi aditya...@gmail.com wrote: As of now moko doesn't play anyrole in it... But I have made a hardware which I wish to connect to make and develop further I wish to attach sensors to FR maybe a webcam along with my robot controller , and first task is to just avoid obstacles . One more Idea I wish to implement is to get data from the accelerometers of the FR and guess the movement of a person and the robot to follow it. The link to the pics is: http://www.flickr.com/photos/29046...@n03/sets/72157622544758011/ On the robot there are two board one which is the L298 board to control the motor, it is a simple board with l298, 16 diodes, one 5v regulator and capacitors. The other board is the 434Mhz receiver along with ht12d decoder, it controls the input to the robot, basically there is brain required here, a simple circuit with no microcontroller. The board which is on the ground is the board with atmega8, and a rf transmitter of ask type 434 Mhz. with a ht12e encoder to encode the data from pins. Which again is fairly simple. It uses libusb to connect to application on any platform (unix, linux, windows etc.) basic design from http://andreas.goelzer.de/usbmot Now that I'm done with this I'll start working with freerunner when I get the device tomorrow hopefully, the courier guys suck in india. On Tue, Oct 27, 2009 at 12:45 AM, Matthias Huber matthias.hu...@wollishausen.de wrote: Aditya Gandhi schrieb: Hi guiys I'm back, I have made a Board with which connects to my pc via a USB which wirelessly controls a robot (Simple left ,right ,forward and reverse using tank mechanism for turning no steering for my robot) It uses a firmware to emulate a true usb device and the computer detects it as a custom usb class device for which only libusb is needed to work. Actually the whole Idea is not mine, took a circuit and firmware available and made it wireless. It also has a qt front-end on the pc to control the robot. The Board is based on ATmega8 , ht12e/ht12d (encoder Decoder), L298 motor driver and a 434 MHz ASK RFmodule. The BOM is under 17$ approx. Can you show some fotos ? What role does moko play in it ? ___ 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: Centralization of graphical awesomeness
On Mon, Oct 26, 2009 at 11:16:45PM +0300, Gennady Kupava wrote: http://www.rasterman.com/files/ello-elementary-smartq5.mp4 Thank you for videos, but on high-resolution one we can see exactly same slowness as on FreeRunner - exactly! See how top bar slides out on close of clock and button test - exacly as on my FreeRunner. Look how slow scroll is, again as on FreeRunner! I thought it was pretty snappy in comparison with my FreeRunner. But then... I'm with 16bit software engine, a light theme... so maybe I've even a bit less peeved at the performance than you are... Regardless, it's a lot better than in the FreeRunner! Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
HTC Hero source code?
HTC recently released the kernel source code to the Hero. Would this be of any use to use? Would it be possible to get the HTC Sense OS on the Freerunner? Or, worst case scenario, we could at least get some information on how HTC modified Android to learn from. http://developer.htc.com/ Let me know of you think of what we could do with this. I'm not advanced enough to make the first step, sorry. -Tonym ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Gennady Kupava g...@bsdmn.com wrote: [...] Yes, freerunner device is slow, but it is embedded device, and it's impossible to continue kicking glamo which is already dead, as only reason of slowness. People with GTA01 have no glamo and that? Is it better? As far as I know - not. Actually, yes the GTA01 is very noticeably faster in graphics. I've got both, and I've run 'em side-by-side. The glamo actually is a graphics DEcellerator. That's why GTA02-core is kicking it out. Ken Young ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Am Montag, den 26.10.2009, 20:33 + schrieb Rui Miguel Silva Seabra: On Mon, Oct 26, 2009 at 11:16:45PM +0300, Gennady Kupava wrote: http://www.rasterman.com/files/ello-elementary-smartq5.mp4 Thank you for videos, but on high-resolution one we can see exactly same slowness as on FreeRunner - exactly! See how top bar slides out on close of clock and button test - exacly as on my FreeRunner. Look how slow scroll is, again as on FreeRunner! I thought it was pretty snappy in comparison with my FreeRunner. But then... I'm with 16bit software engine, a light theme... so maybe I've even a bit less peeved at the performance than you are... Regardless, it's a lot better than in the FreeRunner! Indeed - the top bar struggles a bit when the button demo with clouds runs in the background which seems quite logical to me, the other times its so smth. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: HTC Hero source code?
On Mon, Oct 26, 2009 at 04:41:06PM -0400, Tony McKeehan wrote: HTC recently released the kernel source code to the Hero. Would this be of any use to use? Would it be possible to get the HTC Sense OS on the Freerunner? Or, worst case scenario, we could at least get some information on how HTC modified Android to learn from. http://developer.htc.com/ Let me know of you think of what we could do with this. I'm not advanced enough to make the first step, sorry. Are the drivers there, or is the release a sham? Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: HTC Hero source code?
From what I can tell, there are a lot of drivers in the source. I ls'd the source and here's what I got. $ ls kernel_hero/drivers/ accessibility connector gpu macintosh nubus rtc thermal acpi cpufreq hid Makefile of s390 uio amba cpuidle hwmon mca oprofile sbus usb ata crypto i2c md parisc scsi video atm dca ide media parport serial virtio auxdisplay dio ieee1394 memstick pci sh w1 base dma infiniband message pcmcia sn watchdog block edac input mfd pnp spi xen bluetooth eisa isdn misc power ssb zorro cdrom firewire Kconfig mmc ps3 switch char firmware leds mtd rapidio tc clocksource gpio lguest net regulator telephony This what you're talking about? -Tonym Rui Miguel Silva Seabra wrote: On Mon, Oct 26, 2009 at 04:41:06PM -0400, Tony McKeehan wrote: HTC recently released the kernel source code to the Hero. Would this be of any use to use? Would it be possible to get the HTC Sense OS on the Freerunner? Or, worst case scenario, we could at least get some information on how HTC modified Android to learn from. http://developer.htc.com/ Let me know of you think of what we could do with this. I'm not advanced enough to make the first step, sorry. Are the drivers there, or is the release a sham? Rui ___ 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: ffalarms 0.3 -- recurring alarms
Marcel tan...@googlemail.com writes: Am Montag, den 26.10.2009, 02:07 +0100 schrieb Łukasz Pankowski: Hi I have just released ffalarms 0.3, it adds recurring alarms, please test it before depending on it. For me the most missing feature now is being able to edit the alarms and postponing in the acknowledge window. Ideas and comments are welcome. Notes: - add support for recurring alarms, attaching messages to alarms, and choosing alarm date from a calendar - add configuration option for alarm volume, alarm_script and alsa_state Download: http://projects.openmoko.org/frs/?group_id=260release_id=580 (I also provide libical, in case it is not in your distro) Yay! I use ffalarms mostly more than once a day and it's just great to have it. Thanks for your work! :) Although I know you're not too fond of it - what about making it possible to simply turn an alarm off without that puzzle? It's quite annoying me from time to time, especially when I'm just finishing it when its regenerating and I need to hear that alarm once again... Yes I am quite attached to the puzzle it is there since the beginning :). BUT: it is there for the particular purpose to avoid accidental turning off of the alarm. And now Elementary [1] comes with the widget that plays that rule well enough -- slider -- without the annoyance of the puzzle (yes, I say it too). v0.3 adds the acknowledge window that displays after the puzzle, and consider merging the two into one acknowledge window with two sliders: * first one to turn off the alarm sound (when it is loud you want to turn of this first and not read the message), then * the second to acknowledge you read the alarm message (this will appear if you slide the first one). What do you think of such interface? [1] ffalarms was up to 0.2.2 an Edje interface because this way it was running well on 2008.12, which was much used at the beginning of 2009. Łukasz -- Marcel ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
Am Montag, den 26.10.2009, 22:15 +0100 schrieb Łukasz Pankowski: Marcel tan...@googlemail.com writes: Am Montag, den 26.10.2009, 02:07 +0100 schrieb Łukasz Pankowski: Hi I have just released ffalarms 0.3, it adds recurring alarms, please test it before depending on it. For me the most missing feature now is being able to edit the alarms and postponing in the acknowledge window. Ideas and comments are welcome. Notes: - add support for recurring alarms, attaching messages to alarms, and choosing alarm date from a calendar - add configuration option for alarm volume, alarm_script and alsa_state Download: http://projects.openmoko.org/frs/?group_id=260release_id=580 (I also provide libical, in case it is not in your distro) Yay! I use ffalarms mostly more than once a day and it's just great to have it. Thanks for your work! :) Although I know you're not too fond of it - what about making it possible to simply turn an alarm off without that puzzle? It's quite annoying me from time to time, especially when I'm just finishing it when its regenerating and I need to hear that alarm once again... Yes I am quite attached to the puzzle it is there since the beginning :). BUT: it is there for the particular purpose to avoid accidental turning off of the alarm. And now Elementary [1] comes with the widget that plays that rule well enough -- slider -- without the annoyance of the puzzle (yes, I say it too). v0.3 adds the acknowledge window that displays after the puzzle, and consider merging the two into one acknowledge window with two sliders: * first one to turn off the alarm sound (when it is loud you want to turn of this first and not read the message), then * the second to acknowledge you read the alarm message (this will appear if you slide the first one). What do you think of such interface? The slider is a good idea, already works fine in shr-today. (Which didn't survive my scaling experiments very well...) I'm not sure if two windows for turning off the alarm and then acknowledging the alarm messages are nessecary. Couldn't we have one slider in the upper third of a window to turn off the alarm (maybe even red?! I fear that might be hardwired to the theme...), the alarm message in the middle and the acknowledgement switch for that on the bottom. So one could if there's no mesage or its trivial just slide the lower slider and both the message window and the alarm disappear/stop without having to slide twice. What about that? :) -- Marcel ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
FOSDEM2010
Dear list, Saturday 6 and Sunday 7 February 2010 there is another FOSDEM. We (openmoko-community) haven't been to FOSDEM lately (correct me if I'm wrong) and that got to change. What about having our own devroom and give a sign to the world this community has not died since all what happened lately. So my question is: Who would like to come and represent openmoko? Any thoughts on FOSDEM? Pieter ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
Marcel tan...@googlemail.com writes:
Am Montag, den 26.10.2009, 22:15 +0100 schrieb Łukasz Pankowski:
Marcel tan...@googlemail.com writes:
Am Montag, den 26.10.2009, 02:07 +0100 schrieb Łukasz Pankowski:
Hi
I have just released ffalarms 0.3, it adds recurring alarms, please test
it before depending on it.
For me the most missing feature now is being able to edit the alarms and
postponing in the acknowledge window. Ideas and comments are welcome.
Notes:
- add support for recurring alarms, attaching messages to alarms, and
choosing alarm date from a calendar
- add configuration option for alarm volume, alarm_script and alsa_state
Download:
http://projects.openmoko.org/frs/?group_id=260release_id=580
(I also provide libical, in case it is not in your distro)
Yay! I use ffalarms mostly more than once a day and it's just great to
have it. Thanks for your work! :)
Although I know you're not too fond of it - what about making it
possible to simply turn an alarm off without that puzzle? It's quite
annoying me from time to time, especially when I'm just finishing it
when its regenerating and I need to hear that alarm once again...
Yes I am quite attached to the puzzle it is there since the beginning
:). BUT: it is there for the particular purpose to avoid accidental
turning off of the alarm. And now Elementary [1] comes with the widget
that plays that rule well enough -- slider -- without the annoyance of
the puzzle (yes, I say it too).
v0.3 adds the acknowledge window that displays after the puzzle, and
consider merging the two into one acknowledge window with two sliders:
* first one to turn off the alarm sound (when it is loud you want to
turn of this first and not read the message), then
* the second to acknowledge you read the alarm message (this will appear
if you slide the first one).
What do you think of such interface?
The slider is a good idea, already works fine in shr-today. (Which
didn't survive my scaling experiments very well...)
I'm not sure if two windows for turning off the alarm and then
acknowledging the alarm messages are nessecary. Couldn't we have one
slider in the upper third of a window to turn off the alarm (maybe even
red?! I fear that might be hardwired to the theme...), the alarm message
in the middle and the acknowledgement switch for that on the bottom. So
one could if there's no mesage or its trivial just slide the lower
slider and both the message window and the alarm disappear/stop without
having to slide twice. What about that? :)
I was saying about one window:
||
| Message|
||
||
| [Turn off slider] |
| [ACK slider] (*) |
||
| {Close button} (*) |
||
||
where (*) are hidden until you slide the turn off slider.
The other idea which might be better is to use single slider which you
slide right to turn off the alarm and slide back to ACK it.
|--|
| Message |
| |
| |
| [Turn off= / = ACK slider] |
| {Close button} (*) |
| |
|--|
I think it is even simpler and not that annoying, what do you think?
(I hope you like it).
In your idea I would be afraid I can use the wrong slider (may be would
require the ACK slider to be normal size (to make the difference
obvious) which would be less finger friendly), but would have to test it
on myself see if it is a real or imaginary problem.
--
Marcel
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: FOSDEM2010
Hi ! I think I can be there and help for anythink and, why not, present Qalee. David, do you want to move there ? Christophe 2009/10/26 Pieter Colpaert freep...@gmail.com Dear list, Saturday 6 and Sunday 7 February 2010 there is another FOSDEM. We (openmoko-community) haven't been to FOSDEM lately (correct me if I'm wrong) and that got to change. What about having our own devroom and give a sign to the world this community has not died since all what happened lately. So my question is: Who would like to come and represent openmoko? Any thoughts on FOSDEM? Pieter ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- -- Openmoko phone gui : http://www.qalee.org ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
Am Montag, den 26.10.2009, 23:09 +0100 schrieb Łukasz Pankowski:
Marcel tan...@googlemail.com writes:
Am Montag, den 26.10.2009, 22:15 +0100 schrieb Łukasz Pankowski:
Marcel tan...@googlemail.com writes:
Am Montag, den 26.10.2009, 02:07 +0100 schrieb Łukasz Pankowski:
Hi
I have just released ffalarms 0.3, it adds recurring alarms, please test
it before depending on it.
For me the most missing feature now is being able to edit the alarms and
postponing in the acknowledge window. Ideas and comments are welcome.
Notes:
- add support for recurring alarms, attaching messages to alarms, and
choosing alarm date from a calendar
- add configuration option for alarm volume, alarm_script and alsa_state
Download:
http://projects.openmoko.org/frs/?group_id=260release_id=580
(I also provide libical, in case it is not in your distro)
Yay! I use ffalarms mostly more than once a day and it's just great to
have it. Thanks for your work! :)
Although I know you're not too fond of it - what about making it
possible to simply turn an alarm off without that puzzle? It's quite
annoying me from time to time, especially when I'm just finishing it
when its regenerating and I need to hear that alarm once again...
Yes I am quite attached to the puzzle it is there since the beginning
:). BUT: it is there for the particular purpose to avoid accidental
turning off of the alarm. And now Elementary [1] comes with the widget
that plays that rule well enough -- slider -- without the annoyance of
the puzzle (yes, I say it too).
v0.3 adds the acknowledge window that displays after the puzzle, and
consider merging the two into one acknowledge window with two sliders:
* first one to turn off the alarm sound (when it is loud you want to
turn of this first and not read the message), then
* the second to acknowledge you read the alarm message (this will appear
if you slide the first one).
What do you think of such interface?
The slider is a good idea, already works fine in shr-today. (Which
didn't survive my scaling experiments very well...)
I'm not sure if two windows for turning off the alarm and then
acknowledging the alarm messages are nessecary. Couldn't we have one
slider in the upper third of a window to turn off the alarm (maybe even
red?! I fear that might be hardwired to the theme...), the alarm message
in the middle and the acknowledgement switch for that on the bottom. So
one could if there's no mesage or its trivial just slide the lower
slider and both the message window and the alarm disappear/stop without
having to slide twice. What about that? :)
I was saying about one window:
||
| Message|
||
||
| [Turn off slider] |
| [ACK slider] (*) |
||
| {Close button} (*) |
||
||
where (*) are hidden until you slide the turn off slider.
The other idea which might be better is to use single slider which you
slide right to turn off the alarm and slide back to ACK it.
|--|
| Message |
| |
| |
| [Turn off= / = ACK slider] |
| {Close button} (*) |
| |
|--|
I think it is even simpler and not that annoying, what do you think?
(I hope you like it).
In your idea I would be afraid I can use the wrong slider (may be would
require the ACK slider to be normal size (to make the difference
obvious) which would be less finger friendly), but would have to test it
on myself see if it is a real or imaginary problem.
First approach: I'd have placed one slider at the top and one at the
bottom of the window, with the alarm message (in case such exists) in
between them. Isn't that enough to differentiate them?
Would the second approach require one to drop the slider once to make
E recognize that it has been slided? Or could one slide it right and
back in one movement? I guess the former is the case... I'd still prefer
some approach that allows getting rid of the window with just one
movement/click. And what I see right now: Do you plan to make another
button to close the window visible after sliding ACK? That seems too
complicated to me.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: HTC Hero source code?
No... the drivers necessary to run the devices on the HTC Hero... On Mon, Oct 26, 2009 at 05:03:58PM -0400, Tony McKeehan wrote: From what I can tell, there are a lot of drivers in the source. I ls'd the source and here's what I got. $ ls kernel_hero/drivers/ accessibility connector gpu macintosh nubus rtc thermal acpi cpufreq hid Makefile of s390 uio amba cpuidle hwmon mca oprofile sbus usb ata crypto i2c md parisc scsi video atm dca ide media parport serial virtio auxdisplay dio ieee1394 memstick pci sh w1 base dma infiniband message pcmcia sn watchdog block edac input mfd pnp spi xen bluetooth eisa isdn misc power ssb zorro cdrom firewire Kconfig mmc ps3 switch char firmware leds mtd rapidio tc clocksource gpio lguest net regulator telephony This what you're talking about? -Tonym Rui Miguel Silva Seabra wrote: On Mon, Oct 26, 2009 at 04:41:06PM -0400, Tony McKeehan wrote: HTC recently released the kernel source code to the Hero. Would this be of any use to use? Would it be possible to get the HTC Sense OS on the Freerunner? Or, worst case scenario, we could at least get some information on how HTC modified Android to learn from. http://developer.htc.com/ Let me know of you think of what we could do with this. I'm not advanced enough to make the first step, sorry. Are the drivers there, or is the release a sham? Rui ___ 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 -- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
Marcel tan...@googlemail.com writes:
Am Montag, den 26.10.2009, 23:09 +0100 schrieb Łukasz Pankowski:
Marcel tan...@googlemail.com writes:
Am Montag, den 26.10.2009, 22:15 +0100 schrieb Łukasz Pankowski:
Marcel tan...@googlemail.com writes:
Am Montag, den 26.10.2009, 02:07 +0100 schrieb Łukasz Pankowski:
Hi
I have just released ffalarms 0.3, it adds recurring alarms, please
test
it before depending on it.
For me the most missing feature now is being able to edit the alarms
and
postponing in the acknowledge window. Ideas and comments are welcome.
Notes:
- add support for recurring alarms, attaching messages to alarms, and
choosing alarm date from a calendar
- add configuration option for alarm volume, alarm_script and
alsa_state
Download:
http://projects.openmoko.org/frs/?group_id=260release_id=580
(I also provide libical, in case it is not in your distro)
Yay! I use ffalarms mostly more than once a day and it's just great to
have it. Thanks for your work! :)
Although I know you're not too fond of it - what about making it
possible to simply turn an alarm off without that puzzle? It's quite
annoying me from time to time, especially when I'm just finishing it
when its regenerating and I need to hear that alarm once again...
Yes I am quite attached to the puzzle it is there since the beginning
:). BUT: it is there for the particular purpose to avoid accidental
turning off of the alarm. And now Elementary [1] comes with the widget
that plays that rule well enough -- slider -- without the annoyance of
the puzzle (yes, I say it too).
v0.3 adds the acknowledge window that displays after the puzzle, and
consider merging the two into one acknowledge window with two sliders:
* first one to turn off the alarm sound (when it is loud you want to
turn of this first and not read the message), then
* the second to acknowledge you read the alarm message (this will appear
if you slide the first one).
What do you think of such interface?
The slider is a good idea, already works fine in shr-today. (Which
didn't survive my scaling experiments very well...)
I'm not sure if two windows for turning off the alarm and then
acknowledging the alarm messages are nessecary. Couldn't we have one
slider in the upper third of a window to turn off the alarm (maybe even
red?! I fear that might be hardwired to the theme...), the alarm message
in the middle and the acknowledgement switch for that on the bottom. So
one could if there's no mesage or its trivial just slide the lower
slider and both the message window and the alarm disappear/stop without
having to slide twice. What about that? :)
I was saying about one window:
||
| Message|
||
||
| [Turn off slider] |
| [ACK slider] (*) |
||
| {Close button} (*) |
||
||
where (*) are hidden until you slide the turn off slider.
The other idea which might be better is to use single slider which you
slide right to turn off the alarm and slide back to ACK it.
|--|
| Message |
| |
| |
| [Turn off= / = ACK slider] |
| {Close button} (*) |
| |
|--|
I think it is even simpler and not that annoying, what do you think?
(I hope you like it).
In your idea I would be afraid I can use the wrong slider (may be would
require the ACK slider to be normal size (to make the difference
obvious) which would be less finger friendly), but would have to test it
on myself see if it is a real or imaginary problem.
First approach: I'd have placed one slider at the top and one at the
bottom of the window, with the alarm message (in case such exists) in
between them. Isn't that enough to differentiate them?
Would the second approach require one to drop the slider once to make
E recognize that it has been slided? Or could one slide it right and
back in one movement? I guess the former is the case... I'd still prefer
some approach that allows getting rid of the window with just one
movement/click. And what I see right now: Do you plan to make another
button to close the window visible after sliding ACK? That seems too
complicated to me.
Yes, it would require to drop the slider, (2) below is simpler.
1) Your interface is with two sliders and no buttons.
That may be a good aproach, I will have to think of that later and may
be test it on myself. The problem is that now if you acknowledge the
alarm there is no way back to read the alarm info -- it is deleted
(unless recurring). That is why I want to make it two step
(slider/button), so I may do the following:
2) Another posibility is:
One
Re: Centralization of graphical awesomeness
Marcel tan...@googlemail.com writes: I tried to got to qvga for graphics performance testing about a week ago. This is needed (tested on SHR's 2.6.29-rc3): echo qvga-normal /sys/bus/spi/devices/spi2.0/state xrandr -s 240x320 To return to vga: echo normal /sys/bus/spi/devices/spi2.0/state xrandr -s 480x640 Manually altering state is needed because you're using deprecated Xglamo. - graphics in general are far too light, most colors become whiteish - colored stripes horizontally over the whole display, but are invisible on screenshots (naturally) - the same as above, but photographed: http://d-a300.selfip.net/files/shr-today-qvga.jpg Known problem, try these timings for fbset: mode 240x320 geometry 240 420 240 320 16 timings 10 8 88 2 2 8 2 rgba 5/11,6/5,5/0,0/0 endmode -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
On Mon, 2009-10-26 at 22:48 +0100, Łukasz Pankowski wrote:
William Kenworthy bi...@iinet.net.au writes:
Can I add to that request? - Ive just upgraded to ver2 and forgot I had
knobbled the puzzel on the old version ... so once .3 hits the shr feeds
I will have to spend more time decompiling, figuring out how it works,
kill the puzzel then compile it back up again - painful way to fix what
is to me a major usability problem (I cant see the numbers without
glasses, and of course I am not wearing glasses when the alarm goes off
in the morning :)
Perhaps, make it a configuration option would make good sense then you
can continue torturing those poor souls who like it :)
:))
Its quite a good, reliable program, far better than the basic elementary
alarm and I use it most days more than once. Good work.
Thanks. Would turning off the alarm with a slider (please read my reply
to Marcel for details) be fine for you?
I have done the one line hack for you (as I know the code :)) -- it
makes every of four buttons immediately solve the puzzle. Attached
ffalarms.edj, put it as /usr/share/ffalarms/ffalarms.edj in your neo and
it should work with ffalarms 0.2.4 and ffalarms 0.3 (not much tested :)).
The change was:
Index: ffalarms.edc
===
--- ffalarms.edc (revision 60)
+++ ffalarms.edc (working copy)
@@ -523,7 +523,7 @@
script {
new s[2];
getsarg(1, s, 2);
-clicked(atoi(s));
+emit(solved, );
}
}
}
Hi Lucasz, thanks for that - pretty similar to what I have done.
I have a particular HATRED of sliders - particularly the way shr uses
them - they take several swipes before they work and require careful
placement of the finger to grab them and move. To me a slider is for
analog values - buttons are for on/off.
I realise you are worried about the alarm being accidentally
acknowledged - never found that to be a problem because I usually use
something like shr-today so the alarm comes up with the screen protected
(and shr today already uses a slider - gr - so then there are
serial, multiple sliders to deal with - :) Even when I
dont use the today screen, there doesnt seem to be any problem when
carrying the phone in a pocket. Looks to me like a problem that doesn't
need solving. Note that the alarms on the other phones I have at home
dont have such devices so I question whether they are necessary at all.
This why a disable/enable in the settings file might be the easiest
way to deal with this.
One thing I have noticed with 0.2 is that the alarm isn't very loud and
the FR seems to go to sleep before the alarm gets loud enough to hear -
its inaudible except when there is nearly no environment noise. 0.1
seems to get a lot louder, and faster. Something to think of for your
todo list is checking the profile setting before sounding the alarm - an
alarm going off in a meeting is just as disruptive as a phone ring.
0.3 is coming to shr-u soon so I'll see if that's any better in the
sleep department then.
Billk
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Mon, 26 Oct 2009 20:33:12 + Rui Miguel Silva Seabra r...@1407.org said: On Mon, Oct 26, 2009 at 11:16:45PM +0300, Gennady Kupava wrote: http://www.rasterman.com/files/ello-elementary-smartq5.mp4 Thank you for videos, but on high-resolution one we can see exactly same slowness as on FreeRunner - exactly! See how top bar slides out on close of clock and button test - exacly as on my FreeRunner. Look how slow scroll is, again as on FreeRunner! I thought it was pretty snappy in comparison with my FreeRunner. But then... I'm with 16bit software engine, a light theme... so maybe I've even a bit less peeved at the performance than you are... just what i was saying! :) Regardless, it's a lot better than in the FreeRunner! indeed. considering its got even more pixels to draw. and thats the 32bit engine there. not the 16bit one. thus you take a hit for the quality (which is far beyond qt's quality which is much like the 16bit engine where it does everything in 16bpp). -- - 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: Centralization of graphical awesomeness
On Mon, 26 Oct 2009 16:23:54 -0400 Tony McKeehan mck...@rpi.edu said: Would this only work with SHR/QtMoko, etc, or would this also work on Android? I guess my question is, can this be solved from the kernel, or is it done through the distribution itself? you won't get smooth unless you run at vga all the time. you could fake resolution changes in the xserver by using the glamos' scale blit to pixel-double from a shadow fb to the real one. this may have performance impacts - beware. as not glamo has to spin actually updating everything on the screen by doubling its dimensions and copying it. but this is about the only way you'll get smooth. as for some apps can use vga is already possible - xrandr. uc an request a resoltuion change (and/or rotate) vis this x extension protocol. as long as the xserver offers the desired resolutions and implements them correctly. -Tonym Yogiz wrote: Anyway, I agree we should make QVGA work well, and I would use it for most apps. We should also keep in mind ways to allow use of the high res screen -- maybe picking certain apps (like browsers) that could switch to VGA automatically, and making sure the transition between resolutions is a smooth, fast, and automatic (where desired). Here's an idea I'm not sure I've heard before and I think it should be pointed out. When there was discussion whether to use VGA or move over to QVGA I was for the higher resolution, because viewing maps, terminal, pdfs and browsing at higher resolution was more important for me then speed. If however we could have everything at QVGA by default and change smoothly to VGA when required we could have all of the good and none of the bad. Sounds very good to me. ___ 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 -- - 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: Centralization of graphical awesomeness
On Mon, 26 Oct 2009 21:43:47 +0100 Marcel tan...@googlemail.com said: Am Montag, den 26.10.2009, 20:33 + schrieb Rui Miguel Silva Seabra: On Mon, Oct 26, 2009 at 11:16:45PM +0300, Gennady Kupava wrote: http://www.rasterman.com/files/ello-elementary-smartq5.mp4 Thank you for videos, but on high-resolution one we can see exactly same slowness as on FreeRunner - exactly! See how top bar slides out on close of clock and button test - exacly as on my FreeRunner. Look how slow scroll is, again as on FreeRunner! I thought it was pretty snappy in comparison with my FreeRunner. But then... I'm with 16bit software engine, a light theme... so maybe I've even a bit less peeved at the performance than you are... Regardless, it's a lot better than in the FreeRunner! Indeed - the top bar struggles a bit when the button demo with clouds runs in the background which seems quite logical to me, the other times its so smth. indeed. u have 2 processes competing for cpu, competing for io and memory bandwidth, competing for access to the xserver (a 3rd process) which is also competing for cpu. e is very agressive at reducing its memory footrpint. evas and edje for example have caches to cache previously used data (fonts, images, caches scaled versions of images, edje groups and file content indexes etc.). it's a caching bonanza in there. the result its.. memory footprint will expand as the caches fill. e - every N seconds (see config dialogs for what it is set to there, but let's say 60 seconds) will flush caches. that means empty them out to make room for other apps if they need the memory. the linxu kernel hasno way to do caching like it does in the fs caches for userspace. ie please use all unused memory for caching and if any of it is needed, just throw that memory out. that doesn't exist outside of the kernels buffer/file cache, so you need to limit your caches yourself and reduce them whenever possible in case someone else may need the memory. when you see hiccups like that, it's probably because caches got flushed and things are having to be repopulated from disk, decoded and scaled etc. again. if you think e is so bad... look at android. everyone seems to think its the bees knees. go use 1 or 2 big apps for a while, then go 'home'. and wait 30sec or so for everything to appear. home app has unloaded most of its data or just some of it and you can wait many many many seconds for it to load it all back up and re-init the home screen etc. this is a faster device than the freerunner. it takes 16 seconds to come back to working during which it halts, pauses and otherwise isnt usable until its loaded everything. look at: http://www.youtube.com/watch?v=STE_bznazPU this is a similar effect you are seeing in e - but it's only nuking its caches not everything. it's a bit rich to complain about something other apps/gui's do too and yet not complain about them too. the downside of not doing it is.. bigger memory footprint, or smaller caches. (p.s. not directed at you marcel, more just to the thread in general). fyi... e brings bonuses you don't even know you have. here is a memory footprint comparison (no apps running) of mer's default gtk+matchbox+ etc. tools desktop to e17 - they are about functionally equivalent. e is missing wifi management, and mer is missing a bunch of config and things e has. mer: @ 5:27AM ~ free -m total used free sharedbuffers cached Mem: 110107 2 0 5 45 -/+ buffers/cache: 57 52 e17: @ 9:45AM ~ free -m total used free sharedbuffers cached Mem: 110 73 37 0 4 38 -/+ buffers/cache: 30 80 of we shut down x to see what the footprint is just before x starts: @ 4:32PM /usr/share/icons free -m total used free sharedbuffers cached Mem: 110 62 48 0 7 40 -/+ buffers/cache: 14 95 so do the math. that's 16m footprint with wallpaper, icons, gfx and more, vs 43m of memory footprint. e is agressive at saving on memory. you pay a small price for that - these blips when it has to re-fetch and populate caches. -- - 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: Centralization of graphical awesomeness
On Mon, 26 Oct 2009 23:16:45 +0300 Gennady Kupava g...@bsdmn.com said: Dear Carsten, E is nice thing, but it look like highly unoptimized. i beg to differ. it's more optimised than pretty much anything out there. read what i wrote. watch some videos. try run something COMPARABLE. Yes, freerunner device is slow, but it is embedded device, and it's impossible to continue kicking glamo which is already dead, as only reason of slowness. People with GTA01 have no glamo and that? Is it better? As far as I know - not. look at my videos. i have done efl on older slower embedded devices. ipaq. 206mhz arm. 64m ram. qvga. efl was much faster. i have it on a host of devices. the freerunner is by far the worst device given its age. even if it came out in 2001 or so when the ipaq did - unlesss it was qvga, it'd have also performed more poorly than the ipaq. http://www.rasterman.com/files/ello-elementary-smartq5.mp4 Thank you for videos, but on high-resolution one we can see exactly same slowness as on FreeRunner - exactly! See how top bar slides out on close of clock and button test - exacly as on my FreeRunner. Look how slow scroll is, again as on FreeRunner! that's because you have 2 processes competing for the cpu to render. it's not slow. it is not consistent because of 1. having to compete for cpu and IO. nothnig to do with optimisation. That is that 7mb? Bandwidth we can use to update glamo contents? We can count that 7mb if 10 fully updated frames for 640x480 at 16bit? This looks much more that enough. for every second spent uploading contents to glamo, you CANNOT spend it calculating a new fram. that's the problem. you lose a lot of cpu as a result. ok. let's say.. 10 frames can be updated. you have 0 cpu time left to generate those frames! if it was local memory you've be able to copy 10 frames AND still have probably 2/3 of cpu time left to generate them. Also, I installed Qtv14 (thanks to Radek for that distribution), and that I see? I is fast enought, scrolls fast, react fast, and so on. So, scrolling is different in qt. it is a simple blit. in efl it's a redraw. efl is very much like GL. you get a lot of power and abilities with it, but you do pay a price for it. unlike qt, efl's scrollers have smoothly scaled item contents, backgrounds, translucency and everything. if you make the theme SIMPLER with just solid rectangles, like qt - efl will begin to be closer to the same speed. all that pretty stuff comes at a cost. and people want their pretty. tone down the theme to bare rectangles and text and it'll be faster. comparing qt and efl is apples vs oranges. efl simply does a hell of a lot more in the graphics department. and people are using that hell of a lot more E and E's programs just need optimizations. Openembedded in all sucks, as it brings no benefit (same glibc and kernel) with bunch of drawbacks - no easy way to compile for it, so (for me) it's uneasy to figure out that's going on with E. No oprofile where. you have no idea how many optimisations they have. saying they need them is like saying linux needs virtual memory! it just needs it!. it HAS it. in spades. read the code. you wont find routines for rendering faster in most of the world. (when it comes to software). the other engines can full offload to a subsystem (gl, xrender, etc. etc.) *IF* it is there. WHAT e is doing is different to qt because thats how it is being used. if you reduce what its doing to be the same as qt, you will find the speed becomes similar. the reason qt looks faster is that it is simply doing less. I wish E to be faster! Gennady. В Пнд, 26/10/2009 в 22:51 +1100, Carsten Haitzler пишет: On Mon, 26 Oct 2009 13:57:27 +0300 Evgeniy Karyakin anthropophag...@gmail.com said: 2009/10/26 Carsten Haitzler ras...@rasterman.com: you want speed? you will need to give up something. if you still want it to look nice, then drop pixels. its the simplest and easiest solution. its the right resolution for that cpu anyway. the glamo will still hurt you, but not as much. I'm sure everybody who has any professional connections with Freerunner+Glamo development already took all possible measures to solve this problem. But what concrete steps were taken to ease Glamo bottleneck? If its throughput is so narrow, can we lower amount of none. it's a hardware issue. you simply cant read or write to video ram faster than that. andy tried timing stuff all that happened was instability from memory. glamo is most likely also the cause for the cpu runnig at 400 not 500mhz. the extra load on the memory bus (because glamo is hooked there externally providing another addressable chip) probably caused the instability. remove it and there is a big change the cpu could run at 500mhz instead of 400. it's rated to do 500. (yes power consumption would go up - but it'd only be up while its on. when suspended it wont matter). data flowing through
Re: Centralization of graphical awesomeness
On Mon, 26 Oct 2009 16:42:24 -0400 (EDT) Ken Young r...@cfa.harvard.edu said: Gennady Kupava g...@bsdmn.com wrote: [...] Yes, freerunner device is slow, but it is embedded device, and it's impossible to continue kicking glamo which is already dead, as only reason of slowness. People with GTA01 have no glamo and that? Is it better? As far as I know - not. Actually, yes the GTA01 is very noticeably faster in graphics. I've got both, and I've run 'em side-by-side. The glamo actually is a graphics DEcellerator. That's why GTA02-core is kicking it out. Ken Young nice work. and gta01 is at a wonderful 266mhz vs 400 on the gta02. if u think you could have gotten 500mhz out of gta02 without glamo (most likely). -- - 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: E17 default scaling factor
On Mon, 26 Oct 2009 17:18:38 +0100 Marcel tan...@googlemail.com said: Am Montag, den 26.10.2009, 16:19 +0100 schrieb Thomas Zimmermann: Am Montag 26 Oktober 2009 16:08:26 schrieb jeremy jozwik: On Mon, Oct 26, 2009 at 7:57 AM, Marcel tan...@googlemail.com wrote: Moin, I played around with E's scaling too much, can someone tell me the default dpi set in E's scaling settings? Setting 285dpi gives a far too small gui... might not help but i know its less then 177dpi [what i run] did you do this from the gui options or via a command? The slider in the E wrench is set to 140dpi The 4th column of icons fits from 141dpi on. Thanks! 142dpi is the Design default. tho i think that may actually be technically incorrect, but it works well on gta02 it's not setting dpi. .its setting the dpi the theme was DESIGNED for. it's reverse. imho it makes more sense. you cant SET the dpi of your screen. it's fixed. (well until screens become rubber stretchie things), but what does matter is the dpi something was designed to look right at. -- - 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: mplayer - rtsp - youtube
undrwater wrote: A key-word browser would be great. I think many of the browsers available should be able to know what to do if we browse to this location? Some months ago I've started a project with the telefoninux community called eTube [1]... I added the basic features (etube-test.c), but I didn't finish it due to the lack of time, but if there's some interest over it I could prioritize it and continue my work... If you also look around in the archives, I've sent here some tips for watching Youtube videos in the Freerunner... [1] http://dev.3v1n0.net/gitweb/?p=etube.git;a=summary ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: mplayer - rtsp - youtube
|...but if there's some interest |over it I could prioritize it and continue my work... | Consider interest announced! :) |If you also look around in the archives, I've sent here some tips for |watching Youtube videos in the Freerunner... | Thanks! [Russell Dwiggins] ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
-[ Tue, Oct 27, 2009 at 11:52:04AM +1100, Carsten Haitzler ] E is nice thing, but it look like highly unoptimized. i beg to differ. it's more optimised than pretty much anything out there. scrolling is different in qt. it is a simple blit. in efl it's a redraw. efl is very much like GL. you get a lot of power and abilities with it, but you do pay a price for it. unlike qt, efl's scrollers have smoothly scaled item contents, backgrounds, translucency and everything. So, probably unoptimized is not the right term. Maybe it's just _inapropriate_ to do these things on such a device, and that E, because it does so many things, is not such a good choice however optimized it may be ? Or maybe people really want it that way, unusable but good looking ? Personnaly I'm using H1 partly because it feels faster (not that this gnome desktop is particularly fast either, but at least the device do not enter sleep mode while an app is redrawing). ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Tue, 27 Oct 2009 06:31:26 +0100 ri...@happyleptic.org said: -[ Tue, Oct 27, 2009 at 11:52:04AM +1100, Carsten Haitzler ] E is nice thing, but it look like highly unoptimized. i beg to differ. it's more optimised than pretty much anything out there. scrolling is different in qt. it is a simple blit. in efl it's a redraw. efl is very much like GL. you get a lot of power and abilities with it, but you do pay a price for it. unlike qt, efl's scrollers have smoothly scaled item contents, backgrounds, translucency and everything. So, probably unoptimized is not the right term. Maybe it's just _inapropriate_ to do these things on such a device, and that E, because it does so many things, is not such a good choice however optimized it may be ? Or maybe people really want it that way, unusable but good looking ? well as i said. it works fine and fluidly on many other devices. you are free to ditch efl and use gtk or qt if you want. it's your choice. of course if you are not developing apps... it's kind of not your choice :) but.. if i were smart.. i'd not develop apps for the freerunner. it's a dead product. it has no more being produced. it has no evolution path. there won't be a gtao3, 04, 05 etc. everyone quit or was fired/let go from om that worked on phones.. or worked on pretty much anything. your future is other devices.. and these don't suck with EFL. i'd not compromise the future if i were smart. the point even before gta02 was out that.. it was not an end, but a start of something. you don't build your world around your first bit of hardware. if that was the case why are you not complaining that linux sucks on an 8086 on your desktop? because hardware moved on. most games i know of are written to work on the highest end graphics cards at the time. why? by the time the game is out and is selling - everyone has finally upgraded to those cards. they were top end 3 years ago when game design started. now they are low to middle end. gta02 is a a middle end device that came out 4-5 years after its components were middle end - except the LCD. you have a 4-5 year old set of components driving a high end screen. you will pay a cost. the developers are smart if they look forward to where hardware will be in N years and make sure they are on the right path for that. if it works now with some tuning and simplification of things like themes - then great. their code, apis and logic dont need a rewrite every few years. Personnaly I'm using H1 partly because it feels faster (not that this gnome desktop is particularly fast either, but at least the device do not enter sleep mode while an app is redrawing). well efl doesnt draw that slowly... so you're talking of something else :) -- - 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
