Re: [maemo-developers] initfs image
Tiago Batista napsal(a): How do I rebuild a binary initfs image? I found documentation about modifying the kernel, the rootfs Basically it is same as rootfs, both are jffs2 images. Search list archives for initfs http://www.gossamer-threads.com/lists/maemo/developers/ Check also this http://fanoush.webpark.cz/maemo/#initfs Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
backlight Re: [maemo-developers] How to access to Battery,Wifi and System parameters ?
[EMAIL PROTECTED] wrote: - System parameters : panel backlight level. backlight level is property of kernel driver and can be set/get via /sys/devices/platform/omapfb/panel/backlight_level file (value 0-127). However it is also managed by dsme daemon which resets it regulary according to gconf value /system/osso/dsm/display/display_brightness so you can set/get it via # gconftool -g /system/osso/dsm/display/display_brightness # gconftool -s /system/osso/dsm/display/display_brightness -t int 1 which is what the statusbar applet does. Value 1 means kernel value 3. Sadly you cannot go lower without hacking dsme or kernel, see also https://maemo.org/bugzilla/show_bug.cgi?id=375 Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] spam at maemo wiki
Ferenc Szekely wrote: Disabling anonymous edits would be temporary only, since it is against the idea of the wikis. I don't mind fixing the frontpage few times until proper solution is implemented (challenge/response looks ideal). I would disable anonymous logins only when situation gets worse. Personally if site (blog, wiki, forum) wants registration from me for posting casual comments/hints/suggestions/corrrections I think twice and then just forget it. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Scratchbox is not an emulator
Eero Tamminen wrote: - Qemu is far away from being able to emulate the whole ARM device (currently it emulates just most of the user-space stuff and calls the host kernel for rest) Not that far. I think at least one system emulation of ARM board is supported in 0.8.x version and there is even almost complete Palm T-E (OMAP 310) emulation http://lists.gnu.org/archive/html/qemu-devel/2006-03/msg00125.html http://lists.gnu.org/archive/html/qemu-devel/2006-08/msg00058.html http://zabor.org/balrog/palmte/ True that it is far from having N770 emulated (DSP would be probably hard as well as other N770 specific chips) but also far from the user-space stuff you mentioned. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Nokia 770 sources...
Alessandro Ikeuchi wrote: I am worried about a bad product policy and because I am directly harmed by it. You're mostly harmed just by your incompetence. In 90% of stuff you posted the problem was on your side. And I am here as customer, not as community member. Then you are at the wrong place. This is not customer support. when people criticize my work here as analyst I improve it and respect my client, no matter how angry he is. Because customer pays you. This is a community list. You are not paying community members to listen to your rants. Please behave yourself or get lost. Tell me how to write unicode chars (because is certainly changed) would be the most correct way to silence me. No, you got it wrong. In fact, banning you completely from the list would be the most correct way. We are just wasting our time with you. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Modified initfs with onscreen boot menu
Jason Mills wrote: You -could- install the modified "bootprompt" initfs to the 770's flash -once-, and then ship releases of Sardine in such a manner that all you'd need to do is `dd` the various stages to high(er) numbered partitions on the card. Well, we have apt-get and instructions how to upgrade to Sardine from developer rootfs or regular IT2006 cloned to card so IMO this is not strictly needed. If my math is right, you'd need an RS-MMC/MMCmobile card of at least 256 MB. Street cost of these is negligible compared to the cost of the 770. JFFS2 filesystem in flash is compressed. You need at least twice the space on MMC to be comfortable. I made this mistake and now have 128 partition on card almost full just by cloning clean IT2006 system. That would give you: xxx12 MB (256,000,000 Bytes vs. 256 MB "loss") P0 -DOS Partition Table Descriptior P1p* 48 MB "Memory Card" fs P2p 4 MB (Sardine initfs + scratch) P3p 128 MB rootfs+userfs P4E -DOS Extended Partition Table Descriptor P5e64 MB swapfs 256 MB FAT as first partition for both swap and testing IT2006 functionality (usb storage, file manager) is another option to make rootfs bigger, 128 is too small. Also initfs is curently in flash and it is not very useful to move it to card. It would need kernel and boot parameter modifications to boot initfs directly from card which is not trivial and would make the kernel bigger (ext2 and 3 are now modules). If this could be done it would be also good to have separate kernel on card (which is even harder). BTW, since someone mentioned my initfs modification in http://maemo.org/maemowiki/SardineDistro I've added incomplete and unfinished guide to http://maemo.org/maemowiki/HowTo_BootRootFSFromMMC as alternative 2 so people will not flash developer rootfs needlessly. I plan to finish it when I have more time. Feel free to fix or expand it meanwhile. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Modified initfs with onscreen boot menu
Marius Vollmer wrote: Excellent! I am using it right now, and will write up some instructions for how to put Sardine on the MMC. Great. I was thinking about telling Carlos to put it on http://repository.maemo.org/sardine/getting_started.html (which is not in a wiki) near the "Backup your data!" part but then I though about modifying this http://maemo.org/maemowiki/HowTo_BootRootFSFromMMC first so he can just put link to wiki. But so far I had no time to write better docs or learn how to write longer piece of formatted text in wiki style. Would be nice if you could write those instructions. Hopefully, we can just distribute a modified initfs so that people can just flash it. Or even make it an official feature of our default initfs. Would you be willing to license your code with the GPL? Yes, would be nice to have it in official initfs. The code is small and will fit even in current almost full initfs without removing anything. No problem with licencing :-) Also, I already have a small UI improvement suggestion: what about always showing the boot menu, not only when you hit the MENU key? I tend to miss the window where the key needs to be pressed all the time. Maybe the menu could be shown when the root device is "ask"? Yes, good idea. I missed the right time few times too :-) Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] How do I hildonise an SDL app?
Martin wrote: The app goes straight into SDL_Init; it does not use GTK (or anything else). As a result, I get "untitled" as a title in the window bar, and if the window is minimised there is no way to get it back. Both issues are solvable in pure SDL. Window title can be set by SDL_WM_SetCaption, icon in task navigator by setting SDL_VIDEO_X11_WMCLASS environment variable. See http://maemo.org/maemowiki/GameDevelopment for details. Best is to use wrapper shell script as described. I know that I have some packaging work to do in any case, like .desktop and .service files, and they may get the application listed in the application manager You don't need .service file for SDL app, just .desktop as described in wiki Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Future features for Maemo Desktop (Task Navigator, Home, Status bar)?
Hello Karoliina, I would also like the icons in statusbar not to be hardcoded and limited in number. Would be nice to have priorities and sort them and/or allow to rearange or hide them like the task navigator now allows with application menu (Task navigator applet in Control panel). If there are more status bar applets that available space I would sugest to have some light clickable arrows on left or right side and temporarily pop-up next icons down or to the left over window name. Or maybe scroll them in place? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Reflashing initfs directly on the device
Hello, just to let you know that is is possible to reflash initfs partition directly from the device. N770 initfs specific script and binaries of flash_eraseall, nandwrite and mkfs.jffs2 from mtd-utils-1.0 and are here http://fanoush.webpark.cz/maemo/#initfs so you can recreate modified initfs directly from existing data on the device. I reflashed it at least three times and it simply worked. Working steps are: 1. remount initfs read only just to be safe (to stop jffs2 garbage collecting kernel thread) 2. erase the flash (flash_eraseall /dev/mtd3) 3. flash jffs2 image (nandwrite -a -p /dev/mtd3 initfs.jffs2) 4. reboot (dsme daemon runs from mtd3 partition so it may crash if it tries to read something from mtd3 device - did not happen to me) Happy bricking :) Frantisek P.S. You should still recover your device over USB with normal flasher if something goes wrong. Do not erase or write anything to mtd1 partition and do not use -f -j nandwrite options and you should be safe (I hope :-) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] initfs with onscreen boot menu updated
Hello, I have updated initfs hack with onscreen boot menu http://fanoush.webpark.cz/maemo/#initfs Now I think it is pretty usable. changes: - allow also modules and fsoptions per each custom menu item - moved custom items from linuxrc to bootmenu.sh to minimize linuxrc modifications - default root device (set via flasher or cal-tool -R) is preselected in menu - custom menu items can now boot correctly without showing menu when set as default root device - added noatime to mmc, partition 2 item (menu id is mmc2 now) - holding ESC on boot skips executing bootmenu.sh (and boots from flash if default root device is custom and unknown to linuxrc), useful only if modified bootmenu.sh does not boot - show 'booting from xxx ...' when booting without using menu (if bootmenu.sh is not skipped) - evkey.c included Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Re: 770 stopped booting
Fionn Behrens wrote: Unfortunately it doesnt seem to be so easy. Because once you hook the unit up to the PSU it also boots into some kind of charging display. With my unit, this fails, too. At least in IT2006 it looks like when the boot reason is 'charger' it boots into rootfs so the X server and all the stuff is preloaded and later 'poweron' is quick. The difference between charger wakeup and power button seems to be somewhere near the end of boot sequence before the desktop shows. So if rootfs is corrupted it reboots even when connecting charger. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] 770 stopped booting
Hi, you may try my initfs hack with onscreen boot menu (IT2006 only) http://fanoush.webpark.cz/maemo/#initfs which allows you to boot from mmc card with ext2 partition. With working device booted from mmc you can see what is wrong and try to mount root partition in internal flash and backup. If you don't have backup on mmc now you may try to extract root jffs2 image from fiasco .bin image via flasher and then extract it on linux box to RS-MMC card (to second partition if you use my hack, first is regular FAT) and boot clean system temporarily. Well in fact you don't need my initfs hack at all if you make one big (ext2 or 3?) partition on the card and set root device to 'mmc' via flasher. Due to jffs2 compression you need at least 128MB partition on RS-MMC card for root filesystem to fit. One question, if R&D is enabled on your device, do you see the green text with kernel version and other stuff before it hangs? If not, there may be problem with initfs or bootloader so mmc boot won't work too. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Dropbear SSH server limits?
Ian Malcom wrote: On the 4'th session, I get an error message saying that the server failed to allocate a pty. http://www.gossamer-threads.com/lists/maemo/developers/5027?search_string=pty%20limit;#5027 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] HOWTO almost brick your device and get tons of bad blocks in flash (and recover)
Hello, this is not howto that should be followed but a (bit long) warning. I tried to find a way of reflashing initfs partition from device itself. In theory it should be possible via mtd-tools if done correctly. I underestimated a bit how dangerous this stuff is so I went ahead. First I reflashed initfs via 'nandwrite /dev/mtd3 initfs.jffs' but the device did not boot so I reflashed with flasher and it worked again. Then I tried nandwrite flag -j which, according to some information on the net, should be used to flash jffs2 partition. It was wrong. Really wrong. It did not boot too so I reflashed initfs again with flasher and it worked again. After boot I noticed in dmesg output that flashing with nandwrite or something else I did before marked all flashed blocks bad - initfs image had 1.5MB so it means 1.5MB of bad blocks in initfs partition! And initfs partition is in normal situation 2MB long! Since I didn't know what exactly made those bad blocks and was a bit slow in thinking I actually repeated my steps again and managed to make 3MB of bad blocks in total :-) Only then I searched linux-mtd list and found that 1. I should have used 'flash_eraseall' first before writing with nandwrite [1] 2. -j flag to nandwrite should not be used to flash jffs filesystems and will probably be removed [2] Luckily Nokia flasher or bootloader (and also linux kernel) can recover from this situation. It simply skips bad blocks and enlarges initfs partition so next good blocks are used. This is really great solution, thank you Nokia people for making my device still booting even when trying so hard to kill it :-) As a side effect this initfs partition enlargement also moves begining of root partition which makes the device unbootable (the root jffs2 filesystem is missing the beginning). Luckily there is the boot menu and I have mmc card with root filesystem copy booting so I actually didn't notice anything at first :-) Only later I have found that the partition sizes changed - see my request for help [3] for full details. By searching mtd-linux mailing list further and examining kernel and mtd-utils source I found that there is no easy way to get my 'bad' blocks back. Both sources contain bad block checks and kernel prevents erasing bad blocks. I had to comment out these checks and in the end it worked! With custom kernel and flash_eraseall the result is that bad blocks are gone again :-) But my initfs partition still stays enlarged. [4.416931] 5 cmdlinepart partitions found on MTD device omap-nand [4.417053] Creating 5 MTD partitions on "omap-nand": [4.417175] 0x-0x0002 : "bootloader" [4.418853] 0x0002-0x0008 : "config" [4.420318] 0x0008-0x0028 : "kernel" [4.421813] 0x0028-0x0078 : "initfs" [4.423248] 0x0078-0x0800 : "root" Filesystem 1k-blocks Used Available Use% Mounted on /dev/mtdblock35120 1924 3196 38% /mnt/initfs Actually I like this layout. There is more space for modules and other uclibc stuff for further experiments. But still - is there some way of reverting back to 2MB big initfs? Maybe reflashing whole fiasco image at once? Anyway, it looks like I was really extremely lucky that after all things I did I still have my precious N770 working. I still didn't succeed in reflashing from the device but I hope it is just matter of using flash_eraseall and then writing with nandwrite. But it will take few days until I refill my bucket of courage and go ahead and try again :-) Frantisek 1 http://lists.infradead.org/pipermail/linux-mtd/2005-March/012045.html 2 http://lists.infradead.org/pipermail/linux-mtd/2006-August/016256.html 3 http://lists.infradead.org/pipermail/linux-mtd/2006-August/016287.html ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Modified initfs with onscreen boot menu
Frantisek Dufka wrote: I still don't have mmc card with working system. When copied original system from flash to second partition /dev/mmcblk0p2 (ext2) it reboots after while without even showing progressbar. Got it :) The trick it to _not_ to rsync via 'rsync -avHx / /opt' when mmc is mounted to /opt but remount rootfs to different directory (like /floppy) and rsync this. It makes difference with /dev directory. rsync -x skips mounted filesystems which is OK but leaves directory empty which is not OK if directory is not empty and there is something hidden behind mount point. So the rsync -avHx suggested by me on this list works for initfs but doesn't work for rootfs. You need to do extra step of mounting /dev/mtdblock4 again to different directory and rsync that to have complete image. Nokia770-26:~# mount -t jffs2 /dev/mtdblock4 /floppy -o rw,rpsize=1024,rpuid=0,rpuid=3 Nokia770-26:~# mount /dev/mmcblk0p2 /opt/ Nokia770-26:~# rsync -avH --delete /floppy/ /opt/ So now I have exact copy of my IT2006 rootfs on MMC card, partition 2 and it boots fine from menu :-) Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Modified initfs with onscreen boot menu
Hello, I managed to make initfs with boot menu (as mentioned here http://maemo.org/pipermail/maemo-developers/2006-July/004653.html ) sort of working. You can get it here http://fanoush.webpark.cz/maemo/#initfs see README inside. Basically it is original initfs with testserver removed, modified linuxrc, additional bootmenu.sh script and one uclibc executable evkey to get key state and key up and down codes. To use binary diff you need original initfs.jffs2 and xdelta (1.1.3 included in debian) or you can recreate initfs yourself via mkfs.jffs2 and included files. linuxrc modification is relatively minimal, menu is in extra script bootmenu.sh. You can easily add your own options to it. I still don't have mmc card with working system. When copied original system from flash to second partition /dev/mmcblk0p2 (ext2) it reboots after while without even showing progressbar. I tried to fix rootfs in /etc/fstab but it wasn't enough. What else might be hardwired to flash (/dev/mtdblock4)? If anyone manages to have working copy of IT2006 on mmc card let me know :) BTW there is still problem with limited number of writes to free space. Looks like suggested eraseblock of 128KB is too big for initfs with ~128KB free space :-) I tried to make the eraseblock 16kb via -e 16 but it didn't help. In addition to errors in dmesg log, number of writes is still limited. It the 128kb block hardwired in kernel? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] libxv status?
Daniel Stone wrote: It means that the video hardware does not support RGB565 (everything on the device, basically) and YUV together. You can't have part of the screen being RGB and part being YUV; the problem is a couple of layers below the X server. Oh, thanks. Now I understand. From the product brief http://www.erd.epson.com/vdc/html/contents/S1D13742.htm and from kernel sources I wrongly guessed that the conversion is done on the fly (per each update) when moving data from main memory to videoram. But as it is simple DMA it looks like nonsense. Yet it is interesting that the chip must do same operation when moving data on the fly from its internal video memory (if setup as YUV) to LCD hardware in RGB. Why this is possible and the first one not? But anyway we could still hack it and change the format at least at fullscreen for video playback. This should be possible with some dirty tricks, correct? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] libxv status?
Daniel Stone wrote: On Wed, Jul 26, 2006 at 09:34:03AM +0200, ext Frantisek Dufka wrote: Do you say that DSP has such driver duplicated in DSP code and accesses this chip directly? or does the DSP do colorspace conversion in its code and the features of HWA747 chip and ioctls with OMAPFB_COLOR_YUV420 is actually not used (maybe because there is some problem with it)? I thought DSP only decodes video to shared framebuffer in main memory and the actual transfer to epson chip is done by omapfb driver i.e. by ARM CPU from gstreamer or directly from mediaserver code. Correct. Sorry, but is is still not clear to me which parts you quoted are correct. So currently DSP code decodes mp4 into RGB and then lets the framebuffer code blit it to the epson chip in RGB? And ioctls with OMAPFB_COLOR_YUV420 is not used due to not solved problems with multiple surfaces? Am I wrong with this? If not, is it possible to add YUV surfaces to xserver (via Xv or Nokia Xsp extensions) so it could be used from X11 code in Mplayer or (nonpartched or patched) SDL ? Not at the moment: you need multiple planes, so you can also set up a separate YUV surface, you can't just blit in with a different format. And why this is a problem? Yes I understand you need extra memory (surface) allocated for YUV operations. Why it is a problem to have 800x600 in RGB and additional 320x240 in YUV both managed by xserver? Isn't this generic thing already solved in xserver and used on other plaforms? Sorry for being too ignorant about X internals :-) Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] libxv status?
Daniel Stone wrote: On Wed, Jul 26, 2006 at 09:07:57AM +0300, ext Siarhei Siamashka wrote: Does Nokia 770 hardware really support YUV colorspace? My understanding is that the only support we have right now is through the DSP. Hello Daniel, could we clarify this a bit? As far as I understand it the omapfb framebuffer driver (drivers/video/omap/hwa742.c) has access to the Epson 742 chip and according to kernel source supports YUV->RGB color conversion when transferring data from main memory to internal video ram via OMAPFB_UPDATE_WINDOW ioctl defined in include/asm-arm/arch-omap/omapfb.h. There is color format parameter in this ioctl and one of the defined ones is OMAPFB_COLOR_YUV420 Do you say that DSP has such driver duplicated in DSP code and accesses this chip directly? or does the DSP do colorspace conversion in its code and the features of HWA747 chip and ioctls with OMAPFB_COLOR_YUV420 is actually not used (maybe because there is some problem with it)? I thought DSP only decodes video to shared framebuffer in main memory and the actual transfer to epson chip is done by omapfb driver i.e. by ARM CPU from gstreamer or directly from mediaserver code. Am I wrong with this? If not, is it possible to add YUV surfaces to xserver (via Xv or Nokia Xsp extensions) so it could be used from X11 code in Mplayer or (nonpartched or patched) SDL ? I have actually asked similar question but so far got no answer. http://www.gossamer-threads.com/lists/maemo/developers/10223#10223 Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] where can I find the kernel source of 770 ?
falls huang wrote: Hello! I have searched http://repository.maemo.org/pool , but I couldn't find 770's kerenl source . Where can I find it ? Thanks in advance ! For IT2006 http://repository.maemo.org/pool/maemo2.0/non-free/k/ For IT2005 http://repository.maemo.org/pool/maemo1.1/free/k/kernel-source-2.6.12.3/ I wonder what makes the IT2006 sources non-free. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Xserver and Re-flashing error
Hello, thanks for scratchbox/debian compiling guide. I was also interested in recompiling Xserver as Dan but so far I only did 'apt-get source xserver-kdrive' and was examining kdrive sources. As you two are maintainers of this package what are chances that some advanced features will make it into n770 version of kdrive? First is hardware accelerated rotation mentioned last year in blog of one of you (I am left handed). And second one is Xvideo extension or any other way of writing YUV420 bitmap directly to framebuffer? I tried to find in kdrive (and in Xsp extension) sources how video player might do it (avoid colorspace conversion) but so far found no such code. Frantisek Riku Voipio wrote: Dan Brinks wrote: Hello- I've been trying to see if I could modify the X server running on the N770. So firstly I extracted the rootfs from the OS2006 .bin file. I then downloaded the xserver-kdrive .deb file from the repository and extracted it to my rootfs, packaged it all up and flashed my device with it. This worked fine. I then downloaded the source of xserver-kdrive, also from the repository. After expending some effort, I was able to get that to compile. I had to download a couple extensions from other places -- xproto, resourceext, damageext, xdmcp, compositeext; I also had to add one struct definition in spext.h (from the xsp folder in the tar'd xserver-kdrive source). However, it did eventually compile. I then replaced the Xomap executable file in the rootfs with the new one which I had just compiled and flashed the device. The canonical way to compile kdrive (or any other component for 770) inside scratchbox: apt-get source xserver-kdrive fakeroot apt-get build-dep xserver-kdrive [1] cd xserver-kdrive-version dpkg-buildpackage -rfakeroot After this you have a nice .deb you can install with "dpkg -i" on the device. Any other way you might lack some of dependencies and/or have incorrect configure flags. > Now, when my device boots, there is no longer the blue progress bar along the bottom. It merely shows the "Nokia" screen for a second or two and then shows the handshaking screen. As such, I can no longer flash my device with anything at all. Any thoughts? Are you following instructions here? http://www.maemo.org/maemowiki/HOWTO_FlashLatestNokiaImageWithLinux [1] Now that I test it "libxproto-composite libxproto-damage libxproto-colorkey libxproto-resource libxres-dev libxkbfile-dev libxdmcp-dev" packages are missing from maemo.org repository. However these are all opensource and available from other sources (with different names, I think). ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] VMware image for development environment
Andrew Barr wrote: On Wednesday 19 July 2006 18:49, Jason Mills wrote: Unless there are strenuous objections, I'd be happy to build out the Browser Appliance VM with relevant Nokia 770 / Scratchbox tools as a starting point. -JMills (builder of BAVM 1.0.0) I've got one up and (almost) running that is based on Debian sarge and the Maemo 2.0 SDK. Scratchbox is installing now, as I type th is. It is, however, based on QEMU and not VMware. It shouldn't be too hard to convert it if you want VMware, though. I've got similar one but this time it is for colinux :) VMware is more heavy but has slight advantage in MS Windows that you can actually flash with linux flasher from vmware. It is slow and sometimes fails but mostly it works. As for feedback and suggestions I would suggest to actually have two disk images - one normal debian/ubuntu with useful tools installed (mtd-utils, ..) and second one mounted to /scratchbox specific to maemo release. This one will change when moving to newer scratchbox/maemo and you can keep several such images if you wish but still use same basic system. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Modifying the Root Filesystem
Dan Brinks wrote: When I do this with my (working) filesystem, and then flash the n770 with the new rootfs, I get into an infinite reboot cycle. Any thoughts? Dan Brinks Well, last time I tried this with rootfs it was still with IT2005 and it worked. Then I tried it with initfs (IT2006) and it worked too. I also used slightly more complex procedure which should be equivalent. I din't know amout -x rsync flag so I used extra mount on n770 - 'mount /dev/mtdblock4 /floppy -t jffs2 -o rw,noatime,rpsize=1024,rpuid=0,rpuid=3' and rsynced /floppy instead of / to get rid of mounted filesystems. Apart from incomplete/corrupted flashing or bad network/rsync transfer my only idea is that you may try to clean up var/run before making the rootfs. But this is strange, device boots even with crashes so this shouldn't be a problem. Also the flasher has option to disable life guard so the device does't reset when something goes wrong. Maybe you can also skip the sumtool command, mkfs should be enough too. It should only take longer to mount the filesystem. Also did you login as root to your PC? Maybe this is file permission problem. I'm not sure you can rsync and make the filesystem with correct permissions if you are logged in as ordinary user. I'll try it with IT2006 rootfs soon just to be sure it works. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Modifying the Root Filesystem
Stellars Henson wrote: hi, i've been doing the same. my method is a bit simpler: after providing my nokia with most wanted/recent/favourite applications and utilities 1. i just make # tar -cpf /media/mmc1/backup.tar bin boot dev etc home lib root sbin usr var Alternative is to have dropbear and rsync installed on n770. Then you can just execute on desktop linux following commands (done as root, with rootfs directory created and n770 dns alias): # rsync -e ssh -avHx --delete n770:/ rootfs/ # mkfs.jffs2 -r rootfs -o rootfs.temp -e 128 -l -n # sumtool -i rootfs.temp -o rootfs.jffs2 -e 128KiB -l -n # rm rootfs.temp With quick network this can be faster than writing to mmc and can be also synchronised very quickly later when you do some small change. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] A good debugger infrastructure
Philip Van Hoof wrote: But gdb on the device itself (in an xterm), however does work. Pity it's a little bit difficult because my ui's are always full screen. But I'll manage. You can install dropbear or openssh and debug when logged in over network (wi-fi,bluetooh PAN,usb). Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] initfs hacking questions
Eero Tamminen wrote: IMHO best would be to re-create the initfs partition image and flash it. Then there's no need for JFFS2 garbage collecting. :-) I would like to store last chosed rootfs in some config file there so it would be nice to find out if it works or not. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] initfs hacking questions
Devesh Kothari wrote: Can I distribute hacked initfs? If not, is binary patch OK? I am not a legal expert, but please read the EULA (End user license agreement). I would be pretty surprise if they would let you do so :) Devesh I am not a legal expert too so reading EULA is probably waste of time :-) But anyway I will put instructions how to rebuild it somewhere but release also binary diff and wait for Nokia lawyers to ask me to remove it. IMO binary diff is not considered as breaking "You may not copy, distribute, or make derivative works of the Software". In theory it should contain only my pieces of software. So far I have stripped initfs with one extra uclibc binary to check which key is pressed and shell stript to show onscreen menu. It still boots fine when no key is pressed :) As for the uclibc toolchain it was the one without soft floats. I'm still not sure whether I should store last rootfs setting with cal-tool in config partition or better write it to file in initfs filesystem (mtd3, jffs2) or somewhere else. BTW when editing /linuxrc multiple times it happened to me that I still had 124 blocks free and could remove files but creating/modifying file produced 'no space on device'. Looks like some trouble with jffs2 garbage collecting. This is strange. I wonder whether reboot may fix this? Unfortunately the file I successfully deleted was /linuxrc so I had to reflash. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] initfs hacking questions
Hello, recently I tried to modify initfs to allow dual booting and got some questions: Is there a way to get code of pressed HW key in /linuxrc script? There is command that waits for keypress. There is also something is sysfs for detecting battery door, shell, headphone jack state but nothing simple for keys. Anything I missed or do I need to compile my own executable? Which scratchbox uclibc toolchain should I use? There are two ones here http://scratchbox.org/download/files/sbox-releases/0.9.8/tarball/ sf (softfloats) and non-sf. What exactly is testserver? initfs is full in IT2006 so I need to delete something. I deleted testserver and its shared libraries and device seems to boot. Is this needed for device operation or it is really for factory testing or something like that so it never gets executed automatically on boot. How do I run those test anyway? Can I distribute hacked initfs? If not, is binary patch OK? Which functionality I loose when dsme is not executed from /linuxrc (battery charging?) Is is a good idea to use cal-tool frequently (i.e on each boot) to set various flags (root device,..)? This get stored to flash, how it is with wear leveling of config partition? Thanks for any answers. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] The Sardine is finally on the grill
Smells good, thanks :) One more reason to have rootfs on mmc and dual boot working. Time to hack initfs to boot from second (ext2) partition on my 1gig card. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
python Re: [maemo-developers] Maemo 2.0 final release available
Tommi Komulainen wrote: On Fri, 2006-07-07 at 22:16 -0300, ext Gustavo Sverzut Barbieri wrote: I also know about that... but I want to know from Nokia guys if they expect someday to get it included by default, and if yes, what's the showstopper so far... if it's the size, how many megabytes would be ok? Can't discuss product features, but personally I'd guess when the tradeoffs in writing applications in python are more beneficial than writing them with C/C++. Basically you'd need at least one application written in python shipping with the devices or software updates to warrant including python by default. I haven't been following the python progress too closely, but I believe the current issues are: 1. horrible startup time 2. memory consumption 3. flash consumption? 4. run-time speed? (And I can imagine we could help startup time by sacrificing memory.) As for the horrible startup time even applications written in C start slowly but python is really much worse. Yesterday I tried the runtime in 2.0 repository with simple examples copied from http://www.maemo.org/platform/docs/pymaemo/python_maemo_howto.html and it is not very usable in current state. Those simple hello world apps start approx. 4 seconds for the first time when python is not in file cache and approx. 2 seconds for second time. This is too much to be usable IMHO. There is also other feature/bug in those examples - they need to be killed with ctrl-c, they don't quit properly when closed via X button. Window is closed but application doesn't terminate in shell. Is this bug or some 'python caching for speedup' feature? I wouldn't like python to be cached in memory indefinitely. When timing the example http://www.maemo.org/platform/docs/pymaemo/python_maemo_howto.html#Hildon+Program+Class with gtk.main() commented (so it exits after startup) it takes 5 seconds ~ $ time ./test.py real0m 5.20s user0m 2.60s sys 0m 2.11s when added "import time" and "print time.time()" on the beginning before modules are loaded and in main around hildon usage if __name__ == "__main__": print time.time() app = HelloWorldApp() app.run() print time.time() it prints: ~ $ date +%s ; time ./test.py ; date +%s 1152527542 1152527543.54 1152527546.33 1152527547.27 real0m 4.88s user0m 2.50s sys 0m 2.03s 1152527547 BTW I also played with prelink (available in 2.0 repository). Seems like firmware image is not prelinked but I admit I didn't notice any speedup or memory gain when everything is prelinked. It has probably something to do with the fact that every UI executable is symlinked to osso-launcher so this looks like same trick used in KDE. But at least prelink does not hurt. This is also related to python a bit. When python executable is prelinked, it starts with 0 relocations but when gtk and hildon modules are loaded it finishes with cca. 13853 relocations. This can add few tenths of milisesond to the python hildon apps stratup too. True that with 5 second startup time this is not first thing to optimize. Currently puthon .so module contain weak references so the prelinking is not effective anyway (works but numbers of relocations are almost the same) Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Internet Tablet OS 2006 edition install withoutWindows?
cartuchoGL wrote: Anybody can explain why flasher utility isn't open source? I think flasher utility is a basic tool for n770 platform, and I don't understand it. I suppose it is because the protocol may be used in normal Nokia phones and they wouldn't like you messing with that. Just a guess, though. Probably same with bootloader and config partition format. Or is there other reason? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] IT2006 beta, bluetooth keyboard - automatic IM switch no longer works
OK, reported as bug https://maemo.org/bugzilla/show_bug.cgi?id=663 Still happens in final version, can bring whole system down and makes bluetooth keyboards less usable. 1. execute 'maemo-gtk-im-switch xim' in osso-xterm 2. press home button 3. click into google home applet 4. crash ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] DUMMY connection with script attached?
Hello, is it possible to set some script for dummy IAP to execute that brings up my custom network? Or is there any other custom type for this? Currently I first need to open dummy connection ( http://maemo.org/maemowiki/DummyIAP ) and then run script that configures network (bluetooth PAN). It would be nice to automate this and run my script automatically when such 'dummy' connection is opened from the GUI. If it is not possible it would be a nice feature to add so we can have any custom type of network. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Nokia 770 CPU speed
Chances are high that the setting is same in both kernels Nokia770-22:~# cat /proc/omap_clocks i2c_ick 0 0 i2c_fck 0 0 mpu 25200 0 mmc_ck 4800 0 mmc_ck 4800 0 bclk 1200 0 mclk 4800 0 usb_dc_ck 4800 0 usb_hhc_ck 4800 0 usb_clko 600 0 uart3_ck 4800 1 uart2_ck 1200 0 uart1_ck 4800 0 lcd_ck 12600 1 rhea2_ck 12600 0 rhea1_ck 12600 0 api_ck 12600 1 dma_lcdfree_ck 12600 0 dma_ck 12600 0 tc2_ck 12600 0 tc1_ck 12600 1 l3_ocpi_ck 12600 1 tc_ck 12600 3 dsptim_ck 1200 0 dspxor_ck 1200 0 dspper_ck 3150 0 dspmmu_ck 12600 0 dsp_ck 25200 0 arminth_ck 25200 0 armwdt_ck 857142 1 armtim_ck 1200 1 armxor_ck 1200 2 armper_ck 6300 3 arm_ck 25200 0 ck_dpll1out 25200 0 ck_dpll1 25200 3 ck_ref 1200 4 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Nokia 770 CPU speed
Raju, Vanitha G wrote: Hi Is there a utility to read the processor speed? Or if you have the register details which can be accessed to determine the speed - that would be of help. Hi, at least in kernel 2.6.16-omap1 (IT2006) you can 'cat' file /proc/omap_clocks Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] IT2006 beta, bluetooth keyboard - automatic IM switch no longer works
Hello, when bluetooth keyboard is connected (via kbdd, but it probably doesn't matter), virtual keyboard is no longer disabled like it was automagically done in IT2005. Is this is bug or feature? If it is feature how to switch input method on the fly for already running programs? When I try to execute 'maemo-gtk-im-switch xim' it is disabled but already running osso-xterm crashes when its window is activated. The same (=crash) with opera browser and text field. When executed again and switched IM back 'maemo-gtk-im-switch osso-input-method' osso-xterm doesn't crash but virtual keyboard does not send any keys to its window. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Alsa on IT2006 beta
Steve Landers wrote: Yes - I looked there. Nothing that stands out as being an alsa driver - snd_hwdep and snd_rawmidi being the closest but neither appears to provide the functionality of the inbuilt Alsa drivers in IT2005 nor the Alsa support referred to in the Maemo documentation. And, unfortunately, I cannot find any documentation on how to use these modules. Tha basic support is in kernel Nokia770-22:~# cat /proc/asound/version Advanced Linux Sound Architecture Driver Version 1.0.11rc2 (Wed Jan 04 08:57:20 2006 UTC). and with the rest in modules I think it is the same functionality as it was in IT2005 (i.e almost none). What exactly did work in IT2005 out of box? I thought alsa is not working yet for the internal audio and people should use gstreamer or esd deamon for that as the audio chip is used only by DSP (via gstreamer) directly. Am I wrong? Was there really alsa to DSP audio driver in kernel in IT2005? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Alsa on IT2006 beta
Steve Landers wrote: So, I have a few questions - are the plans for alsa support to be re-added to IT2006? - does anyone have the alsa driver built as a module that can be added to IT2006? some things previously in kernel are modules now, have a look in /mnt/initfs/lib/modules/current there are some sound modules there - can anyone offer insight as to why I can no-longer reflash the n770? flasher-2.0 BTW the mailing list is searchable http://www.gossamer-threads.com/lists/engine?list=maemo see also http://www.gossamer-threads.com/lists/engine?list=maemo&do=search_results&search_forum=all&search_string=unsupported+board&search_type=AND Regards Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Starting 770 in lower runlevel?
Mathias Uebelacker wrote: Hello Everybody, i`ve still Problems with my device. After Problems flashing OS2006 i can`t go back to OS2005, the device boots, shut down, reboots and so on. Is it possible to start the device in a lower runlevel without GUI. I`ve no chance to use xterm and other usefull stuff without a correct booting device. Mathias I'm not sure this is possible but you can set the boot device to mmc via flasher and boot from mmc card with some sort of recovery root fs prepared. It can be even a copy of normal working rootfs from flash with few changes (like /etc/fstab). Then you can mount internal flash partitions and repair it. See http://www.gossamer-threads.com/lists/maemo/users/6041?search_string=boot%20from%20mmc;#6041 If you have linux desktop available you can prepare the card from desktop. There are instruction in the wiki how to extract fiasco image (use flasher) and how to mount jffs2 filesystem. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Workaround to prevent crash when pressing home key in SDL programs (IT2006)?
Tapani Pälli wrote:
You can access display and window from SDL code without SDL sources ...
you have to include
That's great. So the final workaround (works in scummvm port) is like this:
#include
void SDL_X11_SetNetWMWindowTypeNormal(){
SDL_SysWMinfo wminfo;
SDL_VERSION(&wminfo.version);
if (SDL_GetWMInfo(&wminfo)){
Atom atoms[1] = { None };
Atom net_wm_window_type;
net_wm_window_type = XInternAtom (wminfo.info.x11.display,
"_NET_WM_WINDOW_TYPE", False);
atoms[0] = XInternAtom (wminfo.info.x11.display,
"_NET_WM_WINDOW_TYPE_NORMAL",
False);
XChangeProperty ( wminfo.info.x11.display,
wminfo.info.x11.wmwindow,
net_wm_window_type,
XA_ATOM, 32, PropModeReplace,
(unsigned char *)atoms, 1);
}
}
And it can be called after SDL_Init(SDL_INIT_VIDEO) but before
SDL_SetVideoMode. When called later the icon will not show immediatelly
but after minimizing/rearranging windows.
This is of course needed only if you want it working in current beta. It
won't be needed for future versions.
Also you need to add -I /usr/X11R6/include to gcc, SDL_syswm.h needs it.
Frantisek
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Workaround to prevent crash when pressing home key in SDL programs (IT2006)?
Hi,
tried it yesterday just for fun and it works.
code looks like this:
#include
#include "SDL_x11video.h"
#undef WMwindow
extern SDL_VideoDevice *current_video;
void SDL_X11_SetNetWMWindowType(char *windowtypestring){
if (current_video && current_video->name &&
(strcmp(current_video->name,"x11
")==0)){
struct SDL_PrivateVideoData *x11data=(struct
SDL_PrivateVideoData *)current_video->hidden;
Atom atoms[1] = { None };
Atom net_wm_window_type;
net_wm_window_type = XInternAtom (x11data->X11_Display,
"_NET_WM_WINDOW_TYPE", False);
atoms[0] = XInternAtom (x11data->X11_Display,
windowtypestring,
False);
XChangeProperty ( x11data->X11_Display,
x11data->WMwindow,
net_wm_window_type,
XA_ATOM, 32, PropModeReplace,
(unsigned char *)atoms, 1);
}
}
and example
int main(int argc, char *argv[]){
SDL_Event event;
int done=0;
SDL_Init(SDL_INIT_VIDEO);
SDL_SetVideoMode(720, 480, 0, 0);
SDL_WM_SetCaption(argv[0], NULL);
SDL_X11_SetNetWMWindowType("_NET_WM_WINDOW_TYPE_NORMAL");
while (!done){
SDL_PollEvent(&event);
if(event.key.keysym.sym == SDLK_ESCAPE)
done = 1;
SDL_Delay(1);
}
SDL_Quit();
return(0);
}
but you need to have sdl sources (fakeroot apt-get source libsdl1.2) to
get SDL_x11video.h and SDL_sysvideo.h headers and compile it like this
gcc -Os sdltest.c -I /usr/include/SDL -I /usr/X11R6/include -o sdltest -lSDL
Frantisek
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Workaround to prevent crash when pressing home key in SDL programs (IT2006)?
Uwe Koch wrote: In the beta IT2006 this doesn't work (mentioned bug). So is there any chance to deactivate the home key in SDL programs until the bug is fixed in the GA release? Well there seems to be fix in SVN for this http://www.gossamer-threads.com/lists/maemo/commits/8981?do=post_view_threaded so maybe the workaround isn't worth the time but if you really want to implement quick workaround for current beta it would be better to fix this properly i.e set the _NET_WM_WINDOW_TYPE window property to _NET_WM_WINDOW_TYPE_NORMAL which is what the task navigator wants for the icon. X example code to set (different) properties is here http://mail.gnome.org/archives/gnome-devel-list/2002-January/msg00119.html You probably need reference to X display and window but maybe they are in some global variables, see the SDL_x11 driver http://www.libsdl.org/cgi/viewvc.cgi/tags/SDL/release-1.2.10/src/video/x11/SDL_x11wm.c?view=log Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] IT2006 beta - /var/run vs /tmp
Hello, looks like /var/run is no longer mounted/linked to /tmp or other tmpfs filesystem. I'm not sure but think in 2005 both were tmpfs (maybe one was softlink to another). Is there some reason or is it a bug? Both seem to contain temporary stuff but /var/run is now in flash. Nokia770-22:~# l /var/run/ -rw-r--r--1 root root4 Jun 12 22:02 btcond.pid drwxr-xr-x2 messageb messageb0 Jun 12 22:02 dbus -rw-r--r--1 root root4 Jun 12 22:02 dnsmasq.pid -rw-r--r--1 root root4 Jun 12 22:03 dropbear.pid -rw-r--r--1 root root0 Jun 12 22:02 dsp_mem_reserve -rw-r--r--1 root messageb5 Jun 13 20:01 eap.pid -rw-r--r--1 root root4 Jun 12 22:02 icd.pid -rw-r--r--1 root root6 Jun 12 22:01 ifstate srw-rw-rw-1 root root0 Jun 12 22:02 sdp -rw-r--r--1 root root4 Jun 12 22:02 wlancond.pid Nokia770-22:~# Nokia770-22:~# l /tmp/ -r--r--r--1 root root 11 Jun 12 22:02 .X0-lock drwxrwxrwx2 root root 60 Jun 12 22:02 .X11-unix srw-r--r--1 root root0 Jan 1 1970 .bmesrv drwxrwxrwt2 root root 60 Jun 12 22:02 .esd drwxrwxrwx5 root root 100 Jun 12 22:02 .gamewrapper lrwxrwxrwx1 root root6 Jun 12 22:02 .libosso_device_mode_cache-0 -> normal lrwxrwxrwx1 user users 6 Jun 14 07:39 .libosso_device_mode_cache-2 -> normal srwxr-xr-x1 user users 0 Jun 12 22:02 .maemo-launcher -rw-r--r--1 root root 11 Jun 12 22:02 .mmc-volume-label -rw-rw-rw-1 root root4 Jun 13 21:03 .mvi_status_info -rw-rw-rw-1 root root4 Jun 13 21:03 .mvi_volume_info drwxrwxrwx2 root root 40 Jun 12 22:02 af-piddir srw-r--r--1 root root0 Jun 12 22:02 bme-dbus-socket -rw-r--r--1 user users 0 Jun 14 15:43 customurls drwxr-xr-x2 root root 80 Jan 1 1970 dev -rw-r-1 root root4 Jan 1 1970 dsme.pid srw-r--rw-1 root root0 Jan 1 1970 dsmesock drwx--2 messageb messageb 40 Jun 12 22:02 gconfd-messagebus -rw-r--r--1 user users 4 Jun 12 22:02 maemo-launcher.pid drwxr-xr-x5 user users 100 Jun 13 08:02 osso-appl-states -rw-r--r--1 user users 66 Jun 12 22:02 session_bus_address.user srwxrwxrwx1 user users 0 Jun 12 22:02 session_bus_socket -rw-r--r--1 root root0 Jun 12 22:02 skip-fb-progress.tmp srwxr-xr-x1 root root0 Jun 12 22:02 sock_dsp_dld ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] IT2006 image public release will includelibsdl_ttf?
Devesh Kothari wrote: ext Uwe Koch wrote: I saw many sdl libs already in the SDK but not in the Beta release on the 770. Does anybody know if they will be delivered in the public release or shall I deliver them again like in the IT2005 release? check always http://repository.maemo.org/unstable/2.0rc16/package_reference.html Well there is no column for product image, just the rootfs which is something different (developer rootfs?). There is also python listed as being in the rootfs and it is not by default in the beta image. But anyway, it is probably not so important what is in the image because of the network repositories. If something is not by default I suppose the dependencies pull it from the repository (if configured properly) so there is no need to deliver own libs anymore. Question is whether there will be some repository preconfigured in final production image so it works automatically and whether it will be the same as maemo 2.0 used from arm scratchbox target. Even today when I have mistral-beta configured on the beta image I see /home/user # apt-get upgrade Reading package lists... Done Building dependency tree... Done The following packages will be upgraded: certs libcst maemo-launcher osso-sounds-ui 4 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 1428kB of archives. After unpacking 868kB of additional disk space will be used. Do you want to continue [Y/n]? Is the production image compatible with maemo 2.0 so can I upgrade safely now? I.e is the developer rootfs simply a different selection of packages but using same repository as final image? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] osso-xterm
Larry Battraw wrote: Hi Frantisek, the dependencies are shown if you click the details button after a failed install. In this case you need libvte4_0.11.13-3osso1_armel.deb, libvte-common_0.11.13-3osso1_all.deb, and libncurses5_5.4-3_armel.deb. These are also available from the pool, although they are filed by the name of the package (i.e. vte) instead of lib. Thanks a lot, found even better way. Maybe it is well known fact, but it was new to me. The maemo2.0rc16 arm scratchbox repository can be configured on device in Application installer as catalogue Web address: http://repository.maemo.org/ Distribution: maemo2.0rc16 Components: free non-free After package list refresh I can see osso-xterm in the list and install it :-) Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] IT2006 no taskmanager icon for SDL app, worked in IT2005
Eero Tamminen wrote: Hi, Well in older system it was not essential if you kept the name of application same as the name of desktop file or Exec field or whatever. It simply worked without it. Only for Gtk programs. Gtk sets the WM_CLASS automatically to the binary name. For SDL programs the SDL_VIDEO_X11_WMCLASS environment variable was needed also in older releases. I was talking about StartupWMClass field in .desktop file. It was not needed because the default is the binary name which is OK as long as SDL_VIDEO_X11_WMCLASS is set to the same name. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] IT2006 no taskmanager icon for SDL app, worked in IT2005
Frantisek Dufka wrote: Another issue is that the menu item did not appear after package installation but only after device reboot. Am I supposed to refresh the menu in some postinstall script? If yes, how? Workaround for this is to run Control panel->Task navigator->Organize->Done so it seems like bug I will report this menu refresh issue and the missing icon in bugzilla as two items. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] IT2006 no taskmanager icon for SDL app, worked in IT2005
Tommi Komulainen wrote: On Mon, 2006-06-12 at 09:02 +0200, ext Frantisek Dufka wrote: I'm using shell wrapper similar to the one documented here http://maemo.org/maemowiki/GameDevelopment#head-c91f345718121fbd009c639728f9de0104308789 The application starts fine but there is no icon. From that same page, below the example .desktop file: "Notice that StartupWMClass == SDL_VIDEO_X11_WMCLASS, and that Exec points to the script, not binary." The StartupWMClass is essential here. Well in older system it was not essential if you kept the name of application same as the name of desktop file or Exec field or whatever. It simply worked without it. Anyway I added it and it still doesn't work. I also tried with StartupWMClass=SDL_App just in case something went wrong with SDL_VIDEO_X11_WMCLASS setting but it didn't show either. It is a bit hard to check without dropbear or osso-xterm what is wrong on the device. I tried to install osso-xterm from http://repository.maemo.org/pool/maemo2.0rc16/free/o/osso-xterm/ but it probably needs some dependancy. I thought it could work when there is no sandbox anymore, but it seems like packages for scratchbox arm target and devise are still a bit different. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] IT2006 no taskmanager icon for SDL app, worked in IT2005
Hello, were there any changes in handling of taskmanager icons for non-DBUS apps (those without service)? Similar .desktop file worked fine in IT2005: [Desktop Entry] Encoding=UTF-8 Version=1.0 Type=Application Name=ScummVM Exec=/usr/games/scummvm Icon=scummvm X-Icon-path=/usr/share/icons X-Window-Icon=scummvm X-HildonDesk-ShowInToolbar=true X-Osso-Type=application/x-executable I'm using shell wrapper similar to the one documented here http://maemo.org/maemowiki/GameDevelopment#head-c91f345718121fbd009c639728f9de0104308789 The application starts fine but there is no icon. Another issue is that the menu item did not appear after package installation but only after device reboot. Am I supposed to refresh the menu in some postinstall script? If yes, how? Frantisek BTW the new system is really a big improvement, thanks for the hard work :-) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Question(s) about kernel modules
[EMAIL PROTECTED] wrote: I managed to compile those .ko modules with scratchbox 0.9.8.5 & Maemo 1.1, but when I try to load them with "insmod" in 770 (as a root), it says: "insmod: cannot insert 'mymodule.ko': Invalid module format (-1): Exec format error". You probably missed the warning about compiler version in the HOWTO. You need gcc3.4.cs-glibc scratchbox compiler. You may also search the list for further details as this was already discussed few times. http://www.gossamer-threads.com/lists/engine?list=maemo Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] About epson LCD controller
Josep Torra Valles wrote: Hi people, I was locking for info about epson LCD controller and I found this http://www.erd.epson.com/vdc/html/contents/S1D13742.htm Is it the LCD controller used in Nokia 770 ? Wow, very good hit, thanks. Maybe it is our chip. Last nubmers are same (742) and features are exactly as needed. Unfortunately 768KB means only one buffer in full 800x480x16bit. But if pixel doubling or halving means also that it can have memory buffer in 400x240 and upscale to 800x480 for the lcd then there can be 4 frames for fullscreeen low resolution movies so double buffering may be possible. One needs to contact them to have - S1D13742 Technical Documentation Software - CPU Independent Utilities - S1D13742 Evaluation Boards - Royalty Free source level driver code Evaluation package with board and source code may be expensive but I hope they give at least the technical documentation for free. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] hacking the kernel with the help of the serial console
Pierre TARDY wrote: with the help of search engin, you can find references how to enable the serial console, but no infomation on the effective pinouts of the connector near the battery pack. Can someone tell me where I can solder my 2 wires? http://www.gossamer-threads.com/lists/maemo/developers/6981?search_string=pinout;#6981 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] SDL, Re: SDL vertical blank (vbl) sync.
Tapani Pälli wrote: Hmm let's see if we could come up with a nice solution with discussion. Direct access to fb would mean permission problems. But there could be another fb with different permissions (?) ... Maybe at first the tearing should be solved at driver level so that client can request the flush. Yes permissions are the problem. I didn't think about that. But on the other way I don't think user can do more damage with using fb directly over using X with extensions and this is personal device anyway so maybe fb permissions may be relaxed a bit. But maybe not. My reasons to use fb was to be near the hardware so other layers do not interfere too much and it may be also less work to add such functionality. But true there is also a problem with overlapping regions as SDL over fb would overwrite screen. Which is not so bad too, this is how video overlays look on PC in linux and windows too. But maybe X is better after all if proper extensions can be easily added. Bonus would be that they could be used also in non-SDL pure X (or mixed GTK/X) apps. There was some discussion also that windowmanager could handle the global enabling and disabling of scaler, but individual rects sounds very nice indeed. Yes, the kernel seems to work like this and even remembers last mode and does not initialize different mode if last was the same so there should be no extra overhead with this, but I'm not sure how this is usable from userspace. Well anyway the X extension should allow setting it per each update and SDL could use it to implement virtual half resolution modes so there is no need to mess with this in SDL. But maybe it may remain as an option for games with main area that changes often (in low resolution) and nice hight resolution border area around. So both solutions could exist, either SDL could handle virtual resolution by itself or you could use real 800x480 and set pixel doubling mode for the updates. But you probably already know all this, the biggest problem is time and priorities :-) Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] SDL, Re: SDL vertical blank (vbl) sync.
Tapani Pälli wrote: As for the manual vs automatic updates, that brings another question. How often is the screen really updated? I saw in the kernel source there is manual vs automatic update mode but which one is actualy We are updating areas (dirty-rects), it would hog the memorybus if we would be updating whole screen all the time. Yes, I didn't mean whole screen. As for the modes I later found dmesg prints only changes between states 'disabled' and 'manual' so the answer is manual. Do you think blitting is too slow now? I don't think X is there the bottleneck at all, the true bottleneck is the memorybus. No I was not concerned about speed but more about functionality and unneeded layers that may hide some of them. As for the functionality I mean vblank syncing/double buffering to take care of the tearing effect and maybe also direct YUV blits for implementing video player in SDL. As SDL can lie about everything I'm not sure if it supports YUV surfaces in software or uses kernel features. Also as for the pixel doubling, this was told it is basically unstable because you cannot turn it off fast enough or at all if X decides to draw something or your application crashes. http://maemo.org/maemowiki/GameDevelopment#head-6d05e5cc815205f4c0ac4ba09fee0ea5c9d3ff85 By using kernel driver directly from SDL it might be easier as you might set pixel doubling mode per each update rectangle separately (if I understood kernel source correctly, which may not be the case :) so it will not remain turned on. Otherwise there is no need to use it directly if X allows to do all of this properly. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] SDL, Re: SDL vertical blank (vbl) sync.
Eero Tamminen wrote: Hi, Yes. So to draw without tearing effect either X of framebuffer driver should report when to draw (vblank period or which line is currently drawn by hardware) Another possibility is that (SDL) application could ask X server to ask Framebuffer to flush the framebuffer contents to the LCD controller when it's done with a frame. It might even do that directly by calling the fb ioctls (if there would be such ioctl and it would have access rights to do it). AFAIK the framebuffer doesn't have constant update rate to the LCD and it doesn't immediately push every framebuffer update to the LCD controller. It does updates only if the framebuffer contents have been updated (there's an ioctl to tell that) and there's a certain amount of time since last update. So, if application could force the framebuffer flush, it would have time to update the screen before the next (automated or application forced) flushing happens. Yes, that would be enough too. In fact that's what Kuisma Salonen already mentioned yesterday - synchronization in the driver. Now I see it too. As for the manual vs automatic updates, that brings another question. How often is the screen really updated? I saw in the kernel source there is manual vs automatic update mode but which one is actualy enabled? With automatic updates in some intervals it would really not matter how fast you can blit to the SDL surface when the data will not actually make it to the screen. And when talking about SDL, how it is in fact optimized for N770? As there is no source for SDL in the maemo repository, is it a stock SDL over X? Maybe one using directly kernel framebuffer ioctls would be better, at least in full screen. Maybe that is what the video player does. It draws black rectangle via GTK/X and then accesses kernel framebuffer directly (with pixel doubling, and maybe even direct YUV blits). This would explain why it displays black rectangle when you bring up the menu in non-fullscreen mode. Optimizing SDL to use same methods would make it the best way to access the video hardware. And as for the sound, how SDL uses sound hardware? SDL is not mentioned in http://www.maemo.org/platform/docs/multimedia/multimedia_architecture.html Does it go over esound? Is SDL supposed to be first class citizen in Maemo or it is there just for quick game ports but is actually expected to be slower? I'm asking because audio seems to lag a bit (in scummvm) and the same problem is mentioned in port of Flite TTS which solved it by moving from SDL to gstreaemer. Frantisek or the controller has to have two buffers so single or multiple SDL_UpdateRects could be pushed to visible screen in one operation (SDL_Flip) in appropriate moment. Cannot/doesn't SDL do double buffering by itself when asked? (it would be much slower if it's done in the normal RAM where the framebuffer resides, but at least there wouldn't be tearing. :)) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] SDL vertical blank (vbl) sync.
Tapani Pälli wrote: I think there's no guarantee that you will get "HW surface" from SDL, it will silently fallback to SW surface if it cannot have HW one. SDL draws to X, X draws to the framebuffer mapped by kernel which then updates that data to the lcd controller where screen gets finally updated. I would recommend to blit things in memory, then push only needed parts with SDL_UpdateRects trying to avoid fullscreen updates. Yes. So to draw without tearing effect either X of framebuffer driver should report when to draw (vblank period or which line is currently drawn by hardware) or the controller has to have two buffers so single or multiple SDL_UpdateRects could be pushed to visible screen in one operation (SDL_Flip) in appropriate moment. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] SDL vertical blank (vbl) sync.
Visti Andresen wrote: My "flashingTest" reports that: It got a hardware surface (I should be writing directly to "video memory" accordingly to the SDL docs) And the surface is double buffered. The size of the surface is 800x480 16 bit (R5G6B5) So there should be at least 1536000 bytes of video memory I suppose the kernel display driver is open-source? Yes, it is. And I _did_ look at it. And somehow I don't think SDL hardware surface really means memory in Epson HWA742 controller :-) That's why I asked. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] SDL vertical blank (vbl) sync.
Juha Yrjölä wrote: Unfortunately we don't provide user-space with the vsync information (or "Tearing Effect" signal, as it's called in LCD land). If there's large enough need for this, we might consider implementing the support. The tearing effects should be minimal on the 770, however, because of the high (around 55 Hz) refresh rate of the display. Hello, well the effect is visible even when playing the Ice Age Trailer (I suppose it is not already in the movie data). I think such feature is quite useful for games and movie playback. BTW how big is the framebuffer memory? Is there space for 2 frames so double-buffering is possible? Also is there some datasheet for the Epson hwa742 chip? Can you make it public? I tried to google for it (and for lph8923 too) but found nothing useful. Thanks. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] questions smooshed into one email
Christine Liu wrote: hi all - thanks for being so helpful and putting up with my incessant questions. trust me, i do try to rtfm as much as possible before calling for help. :) my question is, are the two lower buttons on the left of the 770 unit (corresponding to 'menu key' and 'home key') mappable? i.e. can i map them to some sort of keystroke input event. the other ones are straightforward (left, right, up, down, return, escape), but i'm wondering if the other ones are destined to be system macros, or can i finagle something else. i tried seeing if they corresponded to K_MENU and K_HOME in pygame.key, but to no avail. These are Fx keys , read the tutorial http://www.maemo.org/platform/docs/tutorials/Maemo_tutorial.html keys are here http://www.maemo.org/platform/docs/tutorials/Maemo_tutorial.html#Hardware-keys BTW, meaningful email subject would be nice too :-) Regards, Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] libstdc++6 problem
Hello, This is probably caused by using wrong compiler in scratchbox. For C++ you should use default debian gcc 3.3 not the 3.4 compiler from codesourcery. 3.3 uses older libstdc++ which _is_ present on the device. If you insist on gcc 3.4 you may try to link libstdc++ statically or you can package libstdc++6 for N770. As for linking c++ runtime statically I tried it with my version of scummvm port and it worked. More details here http://www.internettablettalk.com/forums/showpost.php?p=9629&postcount=8 and here http://www.internettablettalk.com/forums/showpost.php?p=9625&postcount=11 Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers]http://press.nokia.com:80/PR/200605/1051308_5.html
Devesh Kothari wrote: Another reason, is we dont just want to push the Maemo 2.0 till we get the public upgrade IT 2006. Since we know Maemo 2.0 would be binary incompatible, the applications cross compiled on the development environment would not run on the current IT 2005 edition (on device) out there, so developers cant really test it on the device. Can't we have at least developer rootfs for Maemo 2.0? But with working multimedia if posible. Opera etc. isn't needed for testing. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Kernel issues on Nokia 770
Andrey Khurri wrote: Kernel compilation procedure it's not straightforward itself so that would be nice to let those people use our kernel. But as it seems to be the only way is to make 'zImage' available for them. Well, you can give them kernel binary but they currently need to flash it themselves from linux. Advanced windows flasher would be useful for this. Anyone have time to find out parameters of that flasher.dll that comes with windows update wizard? The names of methods are promising [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Also the next OS version may make it easier. There won't be sandbox and root access will be easier so in theory it is possible to make such package. But messing with /dev/mtd2 (kernel partition) may be a bit dangerous from the device itself. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Kernel issues on Nokia 770
Frantisek Dufka wrote: One solution is kexec http://www-128.ibm.com/developerworks/linux/library/l-kexec.html There even seems to be something done for ARM http://lists.osdl.org/pipermail/fastboot/2005-March/001290.html It is probably true that the idea is not very practical for end users on N770 but it may be a bit useful for developers. Please note that you _can_ load different kernel then the one currently present in flash. But you need to use PC and linux flasher - 'flasher -l -b -k zImage'. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Kernel issues on Nokia 770
1) Has anyone ever been making a kernel package for the Nokia 770 which can be installed there with Application Installer rather than deploying 'zImage' of new kernel onto the device? Probably not. It is not straightforward at all, maybe even imposible. You would definitely need root privileges for messing with MTD (flash) partitions. 2) Is it accomplishable at all to have a few kernel images on the Nokia at the same time and choose one using a boot loader as it usually happens with normal Linux mashines? I think it can be done but not easily. The bootloader canot choose between multiple kernels and there is not space dedicated to multiple kernels. One solution is kexec http://www-128.ibm.com/developerworks/linux/library/l-kexec.html BTW, please do not cross post to multiple list, just pick one randomly :-) It is hard to track mutliple replies going to multiple lists. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
CPU video decoding test, Re: [maemo-developers] gstreamer launcher (proper video sink?)
David D. Hagood wrote: In short, clock per clock, I suspect the DSP can do more video work than the ARM can. Now, you *could* make the argument that if the workload of decoding video could somehow be split between the 2 processor cores there might be some benefit - maybe leave the video scaling to the ARM but let the video coding be done by the DSP core. However, the real limiting factor may not even be MIPS, but rather bandwidth Remember what step 0 of optimization is: MEASURE IT FIRST! Until somebody can actually measure where all the time is going, making pronouncements like "It's slow because of X - I just know it" are the root of all evil - you spend a great deal of time tweaking that one thing only to find out that it was only 1% of the time to begin with. Hello again, I tried to compile current CVS version of ffmpeg http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/?cvsroot=FFMpeg to stop producing pure theories and see how video really plays on OMAP 1710 CPU in N770. ffmpeg compiles fine in scratchbox with few configuration tweaks and includes also simple SDL based player called ffplay. There are some optimizations in libavcodec for arm4vl architecture in arm asm. When these are enabled video playback in ffplay is very good. When converting video for Tungsten T2 (OMAP 1510) and TCPMP player I usually use something like this: mencoder.exe %NAME%.avi -audio-preload 0.8 -delay 0.1 -af volnorm -srate 44100 -oac mp3lame -lameopts mode=2:cbr:br=128 -noodml -vf scale=320:240 -sws 9 -ovc lavc -lavcopts vcodec=mpeg4:vhq:vmax_b_frames=0:vbitrate=304 -ffourcc DIVX -o %NAME%_palm.avi Such videos plays adequately in 25fps on T2. In some scenes frames are skipped but generally the playback is good. I used same files on N770 and while they also play acceptably in N770 video player it is a bit worse than on T2 and in more complex scenes the video player hangs randomly. When this happens video is unplayable for some time (10-20 seconds?) until the DSP is automatically restarted. When I tried same videos with ffplay it plays fine when the audio is turned off (ffplay -an video.avi). Looks like the ffmpeg libavcodec mp3 implementation is not optimized for arm (uses floats?). Video plays by default scaled to 640x480 and even in this resolution playback is fluent. CPU utilization is between 50-100% mostly around 75% (just a guess from load plugin applet). When using 320x240 'ffplay -an -x 320 -y 240 video.avi' (which is what the default N770 video player does as it uses HW pixel doubling) it is even better. In this resolution CPU is rarely at 100%, mostly at 50-75%. You can download ffplay binary compiled for N770 from http://fanoush.webpark.cz/maemo/ffplay.gz for a quick test with your videos. If you get access denied paste the url directly into URL bar, webpark.cz free hosting doesn't like direct links to binaries (=foreign HTTP referer field). Or just checkout ffmpeg from CVS and compile yourself. Of course this is just proof of concept as audio is not usable but it proves the CPU is fast enough to decode mp4 video better (=faster, more stable) than current DSP implementation. Further it also proves that the 'bandwidth problem' is not so bad. Even in 640x480 blitting to video memory seems to be good enough. Maybe there is also some room for further optimizations. The ffmpeg code doesn't use edsp instructions available in armv5te (maybe they are not so useful in reality?) and it is also not the fastest implementation even for armv4. The TCPMP player uses different and faster mp4 decoder. It includes optional ffmpeg plugin but only as a slower but more compatible implementation. Also I'm not sure how optimized is SDL code on N770. From the kernel framebuffer source (drivers/video/omap/hwa742.c) it looks like the display supports YUV surfaces directly but maybe ffplay and SDL uses RGB so there is one or two extra YUV<->RGB conversion steps. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] gstreamer launcher (proper video sink?)
Josep Torra Valles wrote: / $ cat /sus/bus/dsptask/devices/dsptask11/devname mp2dec Is it an mpeg2 audio decoder implemented on DSP ? Can you give me info about how I could use it in my project ? Sources of gstreamer plugins which are using the DSP would be extremely useful for this but they are not available. Multimedia may be part of next Maemo release but still it may not include these sources I'm afraid. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] gstreamer launcher (proper video sink?)
[EMAIL PROTECTED] wrote: The OMAP 1510 has a internal Framebuffer - the framebuffer in the N770 is external (I think) and has to be accessed via the 16-bit memory bus. There are internal caches, but program code and the data has also to be transported via the 16-bit memory bus. Maybe that's the bottle neck. The OMAP has also just a 16-bit bus, but has a internal frame buffer, which may be accessed faster without blocking the external 16-bit bus. I think you are mixing words internal and external for the same thing here. If I would stick to the word external then OMAP 1510 on Tungsten T2 has external framebuffer. It is in main SDRAM together with program code and data. You can't fit 320x320x16bit into onchip memory even without double buffering. LCD refreshes are sharing memory bus with everything else needing RAM. That's why Nokia devs needed really external framebuffer because LCD refreshes for 800x480x16bit would take a lot of bandwith. This means memory situation on N770 is even better than on T2. Yet T2 can do better with less caches, older architecture (armv4t without l and e), slower clock and using ARM core only (except the equivalent of N770 pcm dsptask in PalmOS sound driver). On N770 you have to copy data to external framebuffer but you need to do only once for each pixel change so it is still a win. And by the nature of mpeg decompression you should know exactly which pixels need to change so you don't need to copy whole framebuffer each frame. * Video hardware accelerators for DCT, iDCT, pixel interpolation, and motion estimation for video compression Since the DSP has hardware accelerators for (i)DCT etc I really think it should perform faster than the ARM cpu. I would be interested to know what this means. I suppose it is just marketing talk for software implementation running on DSP. There are no public datasheets for 1710 on omap site, only for 5910 so I am not sure about this. When talking about possible bottlenecks and guessing wildly, I would guess the bottleneck is overusing the DSP. When playing compressed audio and video it is constantly switching between multiple dsp tasks to do the job. I would guess the context switches on DSP are very costly when you consider also switching MMU mappings for DSP and communication needed with main CPU. Yet I guess only the mp4 decompression task would need the DSP alone without constant interruptions by other tasks. But these are just guesses. We may know more in the future if Nokia decides to include multimedia into Maemo release. I would be interested in the source of the ARM side of gstreamer plugins that communicate with DSP tasks on N770. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] gstreamer launcher (proper video sink?)
David D. Hagood wrote: Also, many of the operations in video codecs are multiply-and-accumulate operations ( a += b*c ), which DSPs have a single instruction to do. In short, clock per clock, I suspect the DSP can do more video work than the ARM can. Well OMAP 1710 is ARM5-TEJ - the E letter means EDSP extensions so it has MAC operations too. Remember what step 0 of optimization is: MEASURE IT FIRST! Until somebody can actually measure where all the time is going, making pronouncements like "It's slow because of X - I just know it" are the root of all evil - you spend a great deal of time tweaking that one thing only to find out that it was only 1% of the time to begin with. True. Well, as for the measuring, I only know my Tungsten T2 (OMAP 1510,168Mhz) can play 320x240, 25FPS, 300Kbits mp4 videos better than my N770. And TCPMP (palmos video player) uses ARM core only. So I suppose even ARM4 core is good enough. I guess 250Mhz ARM5 together with DSP helping with decoding audio (and maybe some video step - blitting with color space conversion?) could do much better. You can watch /sys/devices/platform/dsp/loadinfo while playing video, the DSP is constantly at 100% when playing video. But I admit these are just my theories. I still had no time to investigate gstreamer framework on N770 in detail. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] gstreamer launcher (proper video sink?)
[EMAIL PROTECTED] wrote: Both of them works! : ) That's cool :) Question: 1)Is it correct for me to use the dspfbsink directly? (Frame buffer) Any pre-processing necessary? I'd guess it isn't, but don't know. You would be missing the new window so it looks like there should be other way. 2)The w.mpg plays correctly on the bundled 770 movie player, but pretty slowly with a lot of frame skips. Is the CPU of Nokia 770 fast enough to handle more advanced codecs, like xvid? All the decoding is done by the DSP. This is IMO bad design choice for (advanced) video. DSP is simply overused and too slow for this. When playing the ice age trailer you can notice with load applet that CPU sits almost idle while DSP is struggling to decode everything. This makes sense for backgroung sound playback, but not for video. You hardly play video on the background :-) It would be interesting to hook in mp4 gstreamer plugin that decodes video by the main CPU. This could result in much higher framerates or better resolution and better utilization of both main CPU and DSP. Or is there some catch why doing it on DSP makes better sense? AFAIK the main ARM CPU should be better suited for the task than the DSP. BTW How much dedicated video memory is there? Can the video driver do double buffering directly in video memory? This would be useful for video playback too. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] New Nokia 770 software image available
Brad Midgley wrote: I noticed the rs-mmc has more connectors than a plain mmc card. In theory, requiring rs-mmc might make it so the nokia doesn't have to run the card in a slower compatibility mode. Well, not exactly. RS-MMC is what is says 'reduced size' MMC. I've got few MMC and RS-MMC cards and they have same number of pins. What you probably mean is the newer MMCplus format with more pins. This format is backward compatible and comes in both normal and reduced size. But I'm afraid N770 device cannot take advantage of such faster cards anyway. If you look into the N770 slot there are simply no contacts for the newer standard. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] 770 display failure workaround
Juha Yrjölä wrote: You're the one with the attitude problem. If we say there is no magic display workaround, there isn't. Everything display-related has already been merged to the public linux-omap kernel tree. Feel free to dig in. Please shut up now. Since I was really impressed by Philippe's posts I just did a quick google search on 'philippe laporte gatespacetelematics.com' and found more posts of similar quality. This reaction is particulary interesting http://permalink.gmane.org/gmane.comp.java.vm.sablevm.devel/1769 so beware before wasting your time. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] hacking the app db on place by combining sdk and product image
Philippe Laporte wrote: Hi, What is the quick and cleanest way to hack the app db on place by combining sdk and product image? Something about this in in the wiki, follow link in http://www.gossamer-threads.com/lists/maemo/developers/4910 As you can see I already asked for this but got no answer. But somehow I expected there won't be any reply because even the changelogs for official firmwares are not available and few people asked for those too. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Measuring power consumption of 770
Heike C. Zimmerer wrote: I don't know of any mobile or laptop which does some real detection. Well it doesn't mater how much it is real (=accurate) but whether there is such circuit which simply stops charging and cuts also the input from battery to not discharge it when you have AC adapter. This is IMHO done in all modern laptops with li-pol batteries to extend life of battery. Otherwice regular charging and discharging near the 100% and 99% level would kill the battery in really short period. There is no such circuit in n770? Even if it were, it wouldn't make much sense to measure at the mains plug if you can do at the battery. ... To put things straight: If you measure "charger plus 770", you measure exactly that, nothing else. All assumptions you draw from it about the Nokia's power consumption alone are worthless without knowing the charger's part. Well I was not thinking about measuring at the mains plug. I was thinking about measuring at the n770 side (5V?) because it is a bit easier then opening the device and messing with battery pins. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Measuring power consumption of 770
Hello Igor, can you comment on idea mentioned in this thread about charging the battery fully and then measuring DC current from charger? Is this nonsense or not? Is the battery used when already charged and device is still connected to the charger? I thought most laptops and PDAs work this way i.e. disconnect battery and use only power from AC adapter. How 770 works? Or is there other issues except those already mentioned? One potential issue is that power saving features may be turned off when charger is connected so the device requirements may be higher than when using battery. Frantisek Igor Stoppa wrote: Hi Dave, On Mon, 2006-03-20 at 11:00 -0700, ext david feldman wrote: Will the 770 run with the recharger (or other external DC power source) attached, with the battery REMOVED? This could be same as the case of an expired battery that will no longer accept a charge. In this case, the only power consumed by the 770 would be by the machine itself, not by the battery recharge, nor assited by battery discharge. Unfortunately I cannot comment on this issue because it has _strong_ liability implications: when dealing with the battery there might be potential safety issues, in case of abuse, overcharging and so on, therefore it's one of the few subjects that cannot be discussed openly. I have not tried this idea, and it could cause unit damage or malfunction, so I do not recommend the procedure - Exactly, that's the point. And that's why there are safety mechanisms that will get in the way when trying to counterfait the battery. The original conversation was about validating power saving algorithms and I was trying to help doing it without safety features becoming an obstacle. The simplest solution is to use an original battery and wire it to the connector pins. igor ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Measuring power consumption of 770
Claudio Scordino wrote: It makes sense but I want to be definitely sure: I need an accurate measure, therefore I need something better than "probably". Well it can be verified that the battery is still full after your measurement by trying to charge it again (i.e. remove and reinsert the cable) and comparing it with the same action done before measurement. True that battery may discharge without using but in relatively short time (hours?,days?) it shouldn't matter. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Measuring power consumption of 770
Claudio Scordino wrote: Does anybody have an idea about how to make the Nokia 770 work without the battery (just with the electric cable) or how to make such a measurement ? When the battery is fully charged you can start measuring current in the cable since the battery is probably not used nor charged. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
dnsmasq Re: [maemo-developers] DNS resolution on n770, how it works?
Sorry, I asked too early. There is dnsmasq running and it is configured to use /var/run/resolv.conf.ppp0 and /var/run/resolv.conf.wlan0 so in theory it should work. But it is a bit strange. It doesn't work. Once I start the pptp tunnel and add internal dns to /var/run/resolv.conf.ppp0 it is messed up and dns resolution stops working. Even if I shutdown pptp, clean up resolv.conf.ppp0 and only wlan0 remains up and /var/run/resolv.conf.wlan0 is correct, it doesn't work anymore. I have to close wlan connection and reconnect to make it working again. Should dnsmasq work with dns servers entered in both /var/run/resolv.conf.ppp0 and /var/run/resolv.conf.wlan0 concurrently? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] DNS resolution on n770, how it works?
Hello, It looks like /etc/resolv.conf contains only localhost, yet when I connect to wlan network DNS works fine. So the information is kept elsewhere (probably some dns server is running on 127.0.0.1?). How exactly it works? I'm asking because I'm trying to use pptp client and when I connect to my vpn (no problem here with modified kernel) DNS stops to work. I'd like to know how to fix the DNS configuration so that both DNS servers are used (public one and the one in vpn network). Also when I close the VPN how to restore previous DNS configuration. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Errors with Tutorial
Check this http://www.gossamer-threads.com/lists/maemo/developers/3409#3409 Roger Books wrote: I have followed the tutorial up to the point where I am building the package. Everything works great to this point. Then I do: [sbox-SDK_PC: ~maemopad] > dpkg-buildpackage -rfakeroot -b dpkg-buildpackage: source package is maemopad dpkg-buildpackage: source version is 1.4 dpkg-buildpackage: source maintainer is Maemo Integration dpkg-buildpackage: host architecture is i386 fakeroot debian/rules clean It then hangs for about a minute (guess not timed) and then prints: libfakeroot: connect: Connection timed out This is a fresh install of Ubuntu in a VM. Developer packages added. Maybe not a symptom but I see no binary for maemopad after the process. Any suggestions would be appreciated. I have several apps I want to write as the don't exist yet. The first is a simple password safe using TEA and CBC. Should be good for getting my feet wet. TIA, Roger Books ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] How large may the kernel-image be?
Clemens Eisserer wrote: Yes of course I did, but this howto doesn't work as all other manuals don't work. It is a wiki, you may fix it instead of whining :-) It start with the install script which does not work You mean it does not work _for you_ not that it does not work. Do you think somebody deliberately put there instructions that do not work for him? Do you think the HOWTO author should care for the very specific system you chosed to install on your computer if he uses another? I ended up downloading the kernel-source package by hand and loading the n770defconf by "make menuconfig" which worked fine :) Yes but maybe you should take the warning in the HOWTO about gcc version seriously :-) As for the compilation by hand (and also outside of scratchbox) yes it would be nice to have it in the HOWTO. I find it easier too. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] intercepting magnet induced sleep mode
You may check this long conversation http://www.gossamer-threads.com/lists/maemo/developers/3910#3910 Looks like turning off WiFi is currently hardcoded but according to David Weinehall it will be redesigned in future to be more flexible. I suppose you can intercept this by checking device mode changes, but I'm not sure. Frantisek Paul wrote: When you close the lid over the 770 and the magnet embedded in the lid hovers near the menu key, the tablet blanks the screen immediately and terminates the network connection. Is there a way to intercept this signal (e.g. via dbus)? Also, is there a way to not get disconnected to the WiFi connection in this mode? For example, I'd like to listen to streamed music but save power by blanking the screen. Thanks! -- Paul ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Launching Qt application in FullScreen mode
Benno Senoner wrote: Hi all, I got Qt working on the Nokia 770 (ran the examples/widgets example), but I would like to start the application in fullscreen mode, without the top and lateral desktop toolbars. This is nothing GTK-specific. You can do it even from SDL-based app on N770. The toolkit should somehow singal to the window manager that it wants to be fullscreen. See this http://doc.trolltech.com/3.3/qwidget.html#setWindowState Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Failure to compile Qt 3.3.5, Infinite loop in qemu-arm, bug in qemu-arm or gcc ?
Benno Senoner wrote: Since Opera is a Qt app and is installed on the Nokia 770 I assume the Opera guys found a way to compile Qt. I guess Opera on N770 does not use QT at all. The rendering core is probably toolkit independent and the menu and other UI is done with GTK. Using QT together with GTK would be a bit wasteful. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] package metadata for firmware images?
Hello, would it be possible to make package metadata available somewhere before they get stripped from final firmware images (for space reasons I suppose)? I've seen wiki page here http://maemo.org/maemowiki/HowTo_InstallAptGet but I suppose the best would be to have original metadata. This would help people to merge developer rootfs with their firmware image to test some things better. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Feedback for Internet Connectivity API update
I think this limitation has something to do with the word 'Internet' in the API name. Because for simplicity there is only one 'Internet' you want to connect to. What I am missing is generic networking or connectivity settings like the 'Network connections' panel in MS Windows. I hoped the connection manager GUI could evolve into something like this but if it is tied to this Internet Connectivity API it will remain quite limited if there is one connection limit and you can only select 'Disconnect' if you are already connected. It would be nice if we could put VPN connection or other types of connections to the same connection manager and just see list of connections under connect and disconnect menu items in the 'globe' applet. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Feedback for Internet Connectivity API update
From the API as presented and from current device behaviour I suspect that is is possible to have only one connection active. I think this is quite big limitation. 1. home wlan adhoc network (laptop) with no internet connectivity + mobile phone - you can access media streamed from laptop and surf via mobile phone, or similar with BT and wlan reversed - bluetooth piconet for games + wlan access to internet 3. VPN scenarios - omitting VPN (like pptp) completely was a bit surprise for me, but this makes it impossible to implement in future. At least in logical way i.e. opening it over existing connection. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] GStreamer and 770
Christian Fredrik Kalager Schaller wrote: Also on the information track, the Tremor plugin in GStreamer 0.10 works fine on the 770. Interesting. So what exactly can I do to let the n770 video and audio player recognize ogg vorbis audio data? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Status of Java on the N770 ??
Hi Fabrice, this was already discussed. There are searchable mailing list archives http://www.gossamer-threads.com/lists/engine?list=maemo You can check it for 'java' before asking further questions. Also generally is not good idea to cross-post to multiple lists. Where should I send my answer? Just pick one list semi-randomly :-) Regards, Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
flashing from windows, flasher source ? Re: [maemo-developers] Flasher Documentation -- In Progress.
Ed Bartosh wrote: On Tue, 2006-01-31 at 00:51 -0700, ext Greg Morgan wrote: Oh is the flasher source available? * It looks like some params have secret handshakes too. I could not find the correct values for -flash-only Possible options are "nolo","kernel","initfs" and "rootfs". "nolo" is for both secondary and xloader bootloaders. You can specify them in any combinations, for example: sudo ./flasher --flash-only nolo,initfs,kernel -F image.bin -f Hello Ed, Is the flasher source available? Is this 'flashing some parts of the image' functionality available in windows version of the flasher? I am doing everything related to N770 programming in colinux instance with debian on windows XP. But to flash only the kernel I need to boot linux on different machine. Is there some possiblility of making the linux flasher source available? If it uses libusb there is a chance that it may compile in cygwin or mingw without major changes because libusb is ported to windows and works. Or alternatively I would be happy with declaration/parameters for the flasher.dll. Looks like the windows wizard is written in Visual Basic 6 and just calls into flasher.dll for all the work. Having advanced flashing from windows for developers would be really nice. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: backlight
OK, here http://fanoush.webpark.cz/maemo/ is quick and dirty solution for extended backlight level control for N770. If it breaks your device all pieces are yours :-) First I thought about making it accesible from another sysfs file but that would need extending some structures in kernel ==> possibility of breaking something. Any level is customizable but your changes is lost after reboot. It is not hard to make some init script to set your preferred values on boot. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: backlight
See this http://maemo.org/maemowiki/HowTo_KernelCompilation . If you don't want to do it in scratchbox target see also this http://www.gossamer-threads.com/lists/maemo/developers/3436 . On x86 debian it is a matter of installing just the kernel sources via dpkg -i file.deb. It puts archive of n770 kernel source to /usr/src/ and then you can continue like with any other linux kernel. On non-debian linux you can extract the deb via 'ar xv file.deb data.tar.gz' and 'tar xvf data.tar.gz' commands. Just don't forget to prepend arm cross compiler to the path before compiling the kernel. This one http://scratchbox.org/download/files/sbox-releases/0.9.8/tarball/scratchbox-toolchain-arm-gcc3.4.cs-glibc-0.9.8.5.tar.gz should do the trick (extracted to /). Just do a make n770_defconfig ; make menuconfig ; make. It should find the cross compiler (arm-linux-gcc) and do the right thing. Image is in arch/arm/boot/zImage and can be flashed directly with 'flasher -k zImage -f -R' As for the changes - I only modified file drivers/video/omap/lcd_lph8923.c I don't have original now, see modified version here http://fanoush.webpark.cz/maemo/lcd_lph8923.c Frantisek Brad Midgley wrote: Frantisek Nice work. Can you put a unified diff on your page or post it here (I realize it's a work in progress, but I'd like to see where it all applies) What is the process for patching and building the kernel .deb? Brad ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: backlight
Frantisek Dufka wrote: It means that either UI dynamically adjusts itself to the value of sysfs backlight_max or it uses directly tahvo. Yes, it uses sysfs. I implemented translation table and also hardcoded values for level 1 and 2 to values 1 and 2 (instead of 8 and 16) and it works like expected. Display is really dark on minimum UI level. Now I need to implement some way of setting this table from userspace. Then each UI backlight level can be customized. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: backlight
Hello, I just tried to compile my own kernel with backlight changes and found this: - my kernel works in the device without any ill effects and without messing with initfs, great :) I used kernel from http://repository.maemo.org/pool/maemo1.1/free/k/kernel-source-2.6.12.3/ I removed translation from 0-15 to 0-127 so backlight_max returns 127 now and any value goes directly to tahvo backlight. UI works still the same. It still has 9 levels going from same minimum to same maximum only values in sysfs are scaled now. It means that either UI dynamically adjusts itself to the value of sysfs backlight_max or it uses directly tahvo. I hope the first one is true. Now I am trying to make translation table in kernel and keep 16 levels but let each one to be configured with value 0-127. Second soulution is trying to hack brigtness applet to provide more levels than 9. I'll probably try both solutions. Frantisek Arnaud Patard (Rtp) wrote: Brad Midgley <[EMAIL PROTECTED]> writes: Arnaud The strange thing is that when you're on the lowest level the gui will allow (1), the display goes a little dimmer than that when idle and the sys file actually reports the value 0. But if you *write* a 0 to the sys file, the backlight turns off altogether. This leaves two interpretations for a 0 value. after looking at the kernel sources, you have 2 ways of setting the PWM value for the backlight : - through sysfs - through /dev/tavho with an ioctl (look at the tahvo-user.c and tahvo.h files in the kernel). If you use the first method, you're have to cope with a scale factor eg when you write 1, you'll write 1*0x7f/0x0f=0x08. This is also happening when you read the file. If you use the second method, you may write an arbitrary value for the pwm. This is probably how is working the gui. This is why 1 with the gui is not the same 1 as with sysfs. If you try to set the level with the ioctl, to something like 1, you'll get a darker screen as expected but it'll go a few sec later to the gui setting. I hope that this helps you :) Arnaud Brad Looks like it can be controlled via ioctl on the framebuffer device. http://maemo.org/lxr/source/osso-af-utils/src/omapfb.h struct lcd_panel has pointer int (*set_bklight_level)(struct lcd_panel *panel,unsigned int level); I'll try to figure out how it can be called. If anyone knows, don't hesitate to answer :) well, you can call it by echoing to /sys/bus/platform/devices/omapfb/panel/backlight_level In reality, the function called is lph8923_panel_set_bklight_level() in lcd_lph8923.c (which in turn calls tahvo_set_backlight_level). The code is saying that 1 is the lowest value (except 0 :P) and 15 the highest. So, you can't go lower unless there's an other way to play with the level. Arnaud Frantisek Brad Midgley wrote: Frantisek I noticed this too, but we know it can go lower... the backlight goes just a bit lower when you're idle and before it turns off altogether. Brad ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] problems of Instalingl a usb camera for N770
Kuisma Salonen wrote: ext [EMAIL PROTECTED] wrote: I just wanted to install usb camera for N770,the model I used is the Logetich quickcam pro4000,the driver is pwc.However when I installed the module pwc.ko ,it says invalid format.Is there anyone have isntalled a usb camera for N770? John Sound like same issue which is with kernel modules in general. Is the module should be compiled against the same kernel which will load the module. So the question is: is the module compiled against the same kernel which is in your 770 (the default 770 kernel unless you have replaced it with your own)? You can find the kernel sources from maemo website with little digging which you can use for compiling the module. Another possible cause could be that the kernel module is not compiled for ARM, which could happen as user mistake or if the kernel module described above is delivered as a binary (just trying to take in account every possible reason)... 100% sure the module is for ARM? And the third question is 'is the module compiled with same gcc version as the kernel in the device?'. I was bitten by this. I compiled source provided by nokia with default gcc 3.3 Everything went fine but I had same mesage when insmod-ing on the device. I had to recompile it with 3.4 and that worked fine. It is described in the wiki. http://maemo.org/maemowiki/HowTo_KernelCompilation Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: backlight
I hope the darkest level won't be too bright either. I see darker level when writing 1 via sysfs then it is possible via gui. When writing 2 it is same level as possible with GUI. But when writing 2 via sysfs it immediatelly returns 1 on read (and the brightness is same). I'll try the ioctl too. Thank you. Frantisek Arnaud Patard (Rtp) wrote: after looking at the kernel sources, you have 2 ways of setting the PWM value for the backlight : - through sysfs - through /dev/tavho with an ioctl (look at the tahvo-user.c and tahvo.h files in the kernel). If you use the first method, you're have to cope with a scale factor eg when you write 1, you'll write 1*0x7f/0x0f=0x08. This is also happening when you read the file. If you use the second method, you may write an arbitrary value for the pwm. This is probably how is working the gui. This is why 1 with the gui is not the same 1 as with sysfs. If you try to set the level with the ioctl, to something like 1, you'll get a darker screen as expected but it'll go a few sec later to the gui setting. I hope that this helps you :) Arnaud ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Re: backlight
Looks like it can be controlled via ioctl on the framebuffer device. http://maemo.org/lxr/source/osso-af-utils/src/omapfb.h struct lcd_panel has pointer int (*set_bklight_level)(struct lcd_panel *panel,unsigned int level); I'll try to figure out how it can be called. If anyone knows, don't hesitate to answer :) Frantisek Brad Midgley wrote: Frantisek I noticed this too, but we know it can go lower... the backlight goes just a bit lower when you're idle and before it turns off altogether. Brad ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] launching applications via .desktop file, process priorities - scummvm problem
Yes, by leaving the X-Osso-Service field empty. Note that you won't get a loading banner either so there's no visual indication if the launching actually worked (not even if the executable path is wrong). Yes, works fine. I was under impression that my script got killed but it was another error. I tried it with simple loop Nokia770-51:~$ cat /home/user/test.sh #!/bin/sh while true ; do date >>/tmp/test$$ sleep 1 done and desktop file Nokia770-51:~$ cat /var/lib/install/etc/others-menu/extra_applications/test.desktop [Desktop Entry] Encoding=UTF-8 Version=1.0 Type=Application Name=Test Exec=/home/user/test.sh and nothing gets killed. Even multiple invocation work fine. Apart from higher priority this script gets there is no problem. Thanks. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] launching applications via .desktop file, process priorities - scummvm problem
Kimmo Hämäläinen wrote: You can see that the patch works, if you e.g. start Browser and look at its priority. Browser is fine. In fact all maemo apps running as a service (having X-Osso-Service=foo) have normal priority. Just those without (like scummvm or my own shell script) have higher priority. I have reported it as a bug https://maemo.org/bugzilla/show_bug.cgi?id=374 BR; Kimmo Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] launching applications via .desktop file, process priorities - scummvm problem
Kimmo Hämäläinen wrote: If it was launched by one of the DBus daemons then it seems a bug. What version of DBus you have? Sorry, should have said it before. It is on the device, official 51 firmware. Looks like I should report it in buzilla then, right? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
