Re: capturing key presses on N770
Vinod Nanjaiah wrote: Hi, I am trying to capture key presses of the Hard keys (Up, Down, Left, Right, Home, etc) on Nokia N770. Is it possible to do so using a simple c program or shell script? Not sure what is the scenario you want to use it for. For low level access you can use kernel input subsystem directly see e.g. evkey.c [1] and its usage in bootmenu.sh [2]. Just beware that different devices have different device names and key events still go to the rest of the system. For playing nice with the system using powerlaunch [3] is indeed better. I am not aware of 770 version (the author [4] has/had N800) but the source is here [4]. Maybe it could build fine at least in OS2007 hacker edition. Frantisek 1. https://garage.maemo.org/plugins/scmsvn/viewcvs.php/tags/bootmenu_0_1/?root=bootmenu 2. https://garage.maemo.org/plugins/scmsvn/viewcvs.php/trunk/bootmenu/files/?root=bootmenu 3. http://powerlaunch.garage.maemo.org/ 4. http://austinche.name/maemo/index.html 5. http://repository.maemo.org/extras-devel/pool/diablo/free/source/p/powerlaunch/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Community updates for diablo
jarmo.ti...@nokia.com wrote: Hi, Just reminder about official Diablo kernel fix for USB networking with Windows PCs that seems to be missing from the list. Many things are missing from the list. I guess the posted list is not final? To me it looks more like what is included in current first testing version. Much longer list of possible fixes seems to be here http://wiki.maemo.org/Talk:Diablo_Community_Project , usb networing fix is listed as g_ether / RNDIS is broken in kernel 2.6.21 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Howto grab all Maemo5 zoom key events in SDL/SDL_gles app?
Till Harbaum / Lists wrote:
Any idea why this still delivers some key events to the volume control?
Maybe sometimes there is another window active which doesn't have the
_HILDON_ZOOM_KEY_ATOM set? Something specific to GLES and/or double
buffering? Does it work with simple SDL app without GLES?
SDL_SysWMinfo info;
SDL_VERSION(info.version);
if ( SDL_GetWMInfo(info) ) {
/* We use the SDL GFX display (we're using the GFX window too after all) */
Display *dpy = info.info.x11.display;
unsigned long val = 1;
Atom atom_zoom = XInternAtom(dpy, _HILDON_ZOOM_KEY_ATOM, 0);
info.info.x11.lock_func();
Window win = info.info.x11.window;
XUnmapWindow(dpy,win);
XChangeProperty (dpy,win,atom_zoom,XA_INTEGER,32,PropModeReplace,(unsigned char
*) val,1);
XMapWindow(dpy,win);
info.info.x11.unlock_func();
}
Does it work for you otherwise? Works better for me without
XUnmapWindow(dpy,win)/XMapWindow(dpy,win) pair, just XChangeProperty.
But maybe that's because I am messing with info.info.x11.fswindow and
info.info.x11.wmwindow and SDL doesn't like (un)mapping those directly.
I am not sure why there are three X windows in info.info.x11 structure
(fswindow, wmwindow and window). From brief look into SDL sources it
seems to me like the 'window' is used when SDL is initialized with not
owned pre-created window passed to SDL via SDL_WINDOWID variable,
otherwise wmwindow and fswindow are used depending of full screen state.
In case you are not using SDL_WINDOWID maybe setting wmwindow and
fswindow would help you with volume keys?
Frantisek
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: ssh uploading to gregale/bora/chinook extras broken?
Niels Breet wrote: On Wed, April 7, 2010 12:16, Frantisek Dufka wrote: drop.maemo.org works for scp login but now I am getting scp: /var/www/extras/incoming/gregale: No such file or directory Seems I missed a link there. Does it work for you now? While scp or dput uploads the file correctly it does not appear in extras I tried yesterday (manual scp) and today morning again (dput just in case) and still nothing. I've added gregale to the wiki here: https://wiki.maemo.org/Uploading_to_Extras-devel#dput Thank you. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Bora/OS2007 extras is dead? Re: ssh uploading to gregale/bora/chinook extras broken?
Niels Breet wrote: The queue for Bora extras should now be available again and should be processed like it was in the past. Just tried and I'm getting scp: /var/www/extras/incoming/bora: No such file or directory Warning: The execution of '/usr/bin/scp' as 'scp -p /scratchbox/users/maemo/home/maemo/scummvm/scummvm_1.1.0_armel.deb /scratchbox/users/maemo/home/maemo/scummvm/scummvm_1.1.0_armel.changes fano...@drop.maemo.org:/var/www/extras/incoming/bora' returned a nonzero exit code. Error while uploading. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Bora/OS2007 extras is dead? Re: ssh uploading to gregale/bora/chinook extras broken?
Niels Breet wrote: Bora was not actively killed, just forgotten to setup last December. Since then nobody complained about it. Date of last change is 22.12.2009 http://repository.maemo.org/extras/dists/bora/ Download numbers don't come above noise levels, but if you think we should keep it for a while then no problem. Download as in getting *.deb file or just checking for updates? Do you know how many people (unique IPs) are checking for Bora updates? Downloading new packages may be rare since there is not much of new stuff. If I am the only one using it, it is OK to kill it :-) And BTW, dput upload to bora worked few minutes ago, thanks. Let's see if it ends up in http://repository.maemo.org/extras/pool/bora/free/s/scummvm/ Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
ssh uploading to gregale/bora/chinook extras broken?
Hello, I have a problem with upload binary deb to gregale/bora/chinook extras. Is this supposed to be working? First I noticed that server key was changed so I needed to remove old one from known hosts. And then uploading via dput still fails with permisison denied, see below Permission denied (publickey). lost connection Warning: The execution of '/usr/bin/scp' as 'scp -p /scratchbox/users/maemo/home/maemo/scummvm/scummvm_1.1.0_armel.deb /scratchbox/users/maemo/home/maemo/scummvm/scummvm_1.1.0_armel.changes fano...@garage:/var/www/extras/incoming/gregale' returned a nonzero exit code. Error while uploading. I have checked my garage account and my ssh key is still there. My ~/.dput.cf has following section [gregale-extras] login = fanoush fqdn = garage method = scp hash = md5 allow_unsigned_uploads = 0 incoming = /var/www/extras/incoming/gregale Same thing happens with Bora. It worked fine last time I needed it (2009-12-01). And BTW I canot find this in maemo wiki anywhere (due to cleanups?) It should be documented in http://wiki.maemo.org/Extras. Nearest relevant topic is http://wiki.maemo.org/Uploading_to_Extras-devel#dput Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: ssh uploading to gregale/bora/chinook extras broken?
Andrew Flegg wrote: Permission denied (publickey). [...] fano...@garage:/var/www/extras/incoming/gregale' Should this now be drop.maemo.org? The change wasn't well communicated at all, especially the impact on the legacy servers. Oh, thanks, I totally missed the server name change. But anyway drop.maemo.org works for scp login but now I am getting scp: /var/www/extras/incoming/gregale: No such file or directory What are corect paths for binary uploads to gregale/bora/chinook? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Bora/OS2007 extras is dead? Re: ssh uploading to gregale/bora/chinook extras broken?
Niels Breet wrote: Seems I missed a link there. Does it work for you now? Yes. Thanks. Bora has been dead for a while now, chinook is also EOL. Bora is dead? Oh really? So why there is http://maemo.org/downloads/OS2007/ with old version I cannot update? When and why was this discussed/decided? I am using OS2007 on my N800 and I like it (Opera, no huge menus, better UI speed overall). I want to support people who do want to keep OS2007 on their N800. And Bora is also alive as a hacker edition for 770. As for Chinook, well, Diablo broke some stuff in browser so it may be a good choice too but killing it is understandable. But why OS2007? Should we kill 770/OS2006 too? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: proper icon path
daniel wilms wrote: Is there a proper location or is everything acceptable? The proper location for the icons is in: /usr/share/icons/hicolor/scalable/hildon/ Is this documented somewhere now? Long time ago I filed https://bugs.maemo.org/show_bug.cgi?id=3619 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Howto configure borderless 4:3 tv-out on n900?
I don't know if there is some high level api but a lot of things can be done either via framebuffer ioctl or via changing stuff in /sys/dev/ices/platform/omapdss/ see http://gitorious.org/linux-omap-dss2/linux/blobs/master/Documentation/arm/OMAP/DSS Having full PAL or NTSC with no translation/scaling would be good both for games and video playback too. So far I have only succeeded to change the default 800x480 - TV scaling to be a bit better so it is no longer fuzzy due to extra downscaling. On my TV I can get exactly 480 lines visible in PAL mode which makes reading text much better. http://talk.maemo.org/showthread.php?p=461660#post461660 For NTSC output (640x480) it would be enough to render to part of the screen and set the size and offset accordingly. For full PAL it would need resizing framebuffer to get more lines (ioctl?). I wonder how OMAP3 display controller features (gfx,vid1,vid2 planes, scaling, mirroring, rotation, tv-out) are mapped to Xv and other X APIs. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Howto configure borderless 4:3 tv-out on n900?
Attila Csipa wrote: Can you (or anyone with intimate knowledge) chip in with some comments of how playing with these can (not) affect the devices (or what gets attached to them) ? Well as long as you only write 'pal' or 'ntsc' to /sys/devices/platform/omapdss/display1/timings nothing should go wrong. It is not needed to mess with tv-out signal timings. It is only about what pixel data gets sent via tv-out (setting data source, position, size, scaling). ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N900 kernel module recompile
Nils Faerber wrote: Then kernel config: cp arch/arm/configs/rx51_defconfig ./.config make oldconfig A make modules does cleanly compile the modules. Fine so far (except for that te modules are *huge* and a arm-none-linux-gnueabi-strip -R .not -R .comment --strip-unneeded seems reasonable). Looks like this strips module version symbols too. Tried similar approach with same result before. But when I try to load one of the new modules I get: -1 Invalid module format And dmesg shows: no symbol version for struct_module In addition I got hit by message saying that the version does not match. I did some 'harmless' changes to kernel configuration before and found them not to be so harmless wrt symbol versions :-( Even when copying original config back and recompiling kernel and modules (trying also with make clean, make mrproper) they were still different. I had to restore Module.symvers file from kernel source. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: rx-51 xkb file: how does FOUR_LEVEL type work?
Denis DeLaRoca wrote:
I can
only trigger F6 by pressing Fn+Shift simultaneously. The method of
locking either Fn or Shift first, doesn't work for me.
Yes, same here. And IMO it is better like that. When having shift locked
and wanting to write number, it is good it really writes number and not F6.
I then tried replacing the F6 mapping with,
key AD06{ [ y,Y, 6, bracketleft ] };
but no luck, it doesn't work...
it looks as if the hildon-layer is doing special
processing for this.
I wanted to map Tab and it doesn't work either. Replacing Tab with
Escape for same key mapping works and gives me Escape key. Looks like
software issue to me not hardware issue with the keyboard.
Same thing does work with N810/OS2008, I have various types of brackets
and other symbols mapped to shift+fn combinations and it works fine.
The only unsolvable issue I encountered is with SDL library and other
software that use low level keyboard info and is interested in state of
shift, ctrl, alt keys. Programs that use such information may be
confused with shift+fn mappings because shift is pressed. As an example
when F6 is mapped to shift+fn+y pressing it would always do shift+f6
action, never f6 action.
Frantisek
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: rx-51 xkb file: how does FOUR_LEVEL type work?
Denis DeLaRoca wrote: On Mon, 1 Feb 2010, Arkady Glazov wrote: N900 hardware keyboard does not support simultaneous pressing three keys. You must lock function key by double press Fn and after them shift+ letter It is not guaranteed but it mostly works. For N810 it produces phantom extra key for M and N but otherwise it works fine with any shift+Fn+key. Not sure about N900 keys. Understood! But notice that for my sample xkb config, to print the [ char that I slotted at the 4th level but it doesn't work. The trick is to press shift first, not Fn. Just tried with my N900 and mapped shift+Fn+Backspace to Escape and it works. Also tried shift+Fn+qwertyuiop to F1-F10 and at least fullscreen and zoom keys (F6,7,8) work. OTOH I also tried shift+Fn+Enter or Space to do Tab and it doesn't work for me with N900. It worked fine with N810. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Where are the N900 too much time at 600Mhz safeguards?
Javier S. Pedro wrote: When I got my N900, one of the first things I noticed is that (as measured by powertop) I could never get a 100% ratio at 600 Mhz, but more like 95%. I quickly assumed this was the safeguard for the issue Igor Stoppa talked about at the Maemo Summit. See also http://talk.maemo.org/showthread.php?p=499042#post499042 I wrote it before noticing this thread but the numbers quoted from OMAP35XX datasheet may be still interesting. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
author vs packager/maintainter Re: Donate $x button on Packages and/or Downloads
Matan Ziv-Av wrote: For example, looking at this page: http://maemo.org/downloads/product/Maemo5/vim/ I see that you (together with Marius Gedminas) wrote this marvelous text editor, which in my estimation took thousands of work hours, so I'll happily donate to you. Does this sound fair? Good point. And it is not only about donations. It is about giving proper credit. And also about accountability - similar issue is curently discussed in Maemo extras repository package uploader/maintainer verification? There should be a way to specify and see original authors (upstream project) and Maemo maintainter/packager. I have same problem with ScummVM. I don't like being mentioned as 'Author'. Previously I had the homepage link pointing to my page too (with maemo specific help) but later changed it to www.scummvm.org to make it clear I am not the author. And BTW at that time it was possible to tag wiki page with downloads project name and the link to such page was visible in downloads. I used it for having extra link to maemo specific help but this feature went away with midgard to mediawiki wiki move. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: gtk clutter tearing
Kimmo Hämäläinen wrote: Recent hildon-desktop versions disable compositing automatically for fullscreen windows, unless you use HildonStackableWindow (which requires the sliding animation). I wonder what happens to translucent information messages (charger attached/removed, ...) in fullscreen SDL applications, are these not shown when compositing is off or are they done in different way and still shown? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
Marius Vollmer wrote: The plan for Maemo 6 is to put everything on the eMMC by default. Excellent idea. Finally :-) It has not been implemented yet, and there is thus not much experience with running the whole OS from the big eMMC. As for getting experience - it is easy to gain it by cloning any current OS version to card ;-) There might still be some surprises caused by the performance differences between ext3 and ubifs, or between the OneNAND and the eMMC. For previous devices it felt faster when booted from card except some corner cases (frequent fsyncs in sqlite causing metalayer-crawler to take ages). For N900 the boot feels a bit slower but once system is booted I don't see much difference (with ext2) but it is too early to really tell. And BTW when OneNAND is free, in theory it could be used for swap (over ubi) causing less writes to eMMC when system is out of memory and already slow. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Commands for adjusting screen brightness for N810
David Weinehall wrote: The relevant GConf key in question is: /system/osso/dsm/display/display_brightness and valid values are 1-5. There is also a kind of hack used by advanced brightness applet. The system below (=dsme daemon) has finer granularity. Brignthess can be changed (as root user) via command chroot /mnt/initfs dsmetest -l n n = 0-255 The hardware itself has only 127 levels so for dsmetest you need to multiply by two. Also running dsmetest with no paremeter prints a help, you might find -d,-b,-x useful too. All this is valid for OS2008 only (N8x0). Also when playing with brightness on this level it is useful to disable ambient light sensor or it will change it. This can be done by removing filter-brightness-als from Module line in /etc/mce/mce.ini (this works for N900 too). Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Find out Maemo version from script
There is /etc/osso_software_version but the file is part of some package that can be uninstalled. Then there is osso-product-info command that reads it from config partition (where it is stored by flasher) and prints it. Why do you need it? Maybe checking specific version of specific feature/debian package is better that this? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PPTP Problem No Auth is Possible
Hello Christian, part of the problem is that mppe is not enabled in kernel. Few pointers http://talk.maemo.org/showthread.php?t=13725 http://fanoush.wz.cz/maemo/#pptp http://fanoush.wz.cz/maemo/kernel-diablo-2.6.21-200842maemo1.tar.gz http://fanoush.wz.cz/maemo/modules-diablo-2.6.21-200842maemo1.tar.gz Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Any new information on Developer Device Program?
ds wrote: Christmas is approaching, and to me it is absolutly not transparent, what happend to a N900 Developer Device Program. I could not find any information on maemo.org. Oh, you mean you missed all the haiku in Maemo talk thread http://talk.maemo.org/showthread.php?p=398254#post398254 ? Definitely worth reading :-) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Debian on the n900 / Configuring NOLO
Carsten Valdemar Munk wrote: . Or allow for flashing the NAND/eMMC through USB. Oh, right, if it can flash eMMC then the mmc code is in, so loading kernel from mmc is one NOLO bugzilla enhancement away ;-) In this case, noone says you cannot include a bootmenu in that zImage that selects a new root. Since I posted previous mail I have checked this and it looks like attaching some sort of initrd/initramfs is not available for arm architecture. It is very platform and bootloader dependent. https://linuxlink.timesys.com/forum/1021 http://www.denx.de/wiki/view/DULG/CombiningKernelAndRamdisk Also It is nontrivial to unzip kernel, modify command line and zip it again. It is implement at linker level piggy.S: - .section .piggydata,#alloc .globl input_data input_data: .incbin arch/arm/boot/compressed/piggy.gz .globl input_data_end input_data_end: - The input_data_end label is used in decompressor code (size=input_data_end-input_data) and whole image is zipped so different text yields different length. For out tablets it is still of course doable to modify decompressor code directly and change the size there. It is not very clean, though. Again, having kernel commandline stored inside config partition and NOLO using it instead of builtin command line would be ideal situation. I doubt u-boot will be ported due to the lack of JTAG and that it's a bit of risky business in terms of bricking your device trying to port it. :) It should be possible to modify any current free bootloader to appear as zImage becoming 3rd stage bootloader. zImage is run with basic hardware already initialized and MMU still off so any bootloader code should be happy with this. Also there is this old LAB idea http://handhelds.org/moin/moin.cgi/HpIpaqH2200LAB Also kexec is another option. So basically we either need free bootloader that can show on-screen menu and load kernel etc. or use linux kernel and userspace code to do this (kexec, pivot_root). Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Debian on the n900 / Configuring NOLO
Frantisek Dufka wrote: Oh, right, if it can flash eMMC then the mmc code is in, so loading kernel from mmc is one NOLO bugzilla enhancement away ;-) Again, having kernel commandline stored inside config partition and NOLO using it instead of builtin command line would be ideal situation. FWIW I have created bug for this https://bugs.maemo.org/show_bug.cgi?id=6468 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Debian on the n900 / Configuring NOLO
Kimmo Hämäläinen wrote: On Thu, 2009-11-26 at 05:10 +0100, ext Christopher Allan Webber wrote: However, I realize I need to configure the bootloader to load off the SD card. This is proving a bit hard to do, however, as I cannot find any documentation on configuring the NOLO bootloader. So even if I install the system, I don't know how to get it to boot! :) This was not possible (or documented if possible) on previous devices. It would be great to have bootloder configurable. But anyway, it is quite unlikely there is mmc and ext2 support inside NOLO. Workaround was changing root early in boot sequence. For previous devices it was like this even for stock system - initfs (/dev/mtd3) is set as root in kernel command line and it does some initialization and then does pivot_root into real root (/dev/mtd4). bootmenu was the solution. See https://wiki.maemo.org/Booting_from_a_flash_card With N900 initfs is not used (even if currently present on device !?) and root is hardcoded in kernel command line. Initial bootmenu changes for N900 is there but I am still not sure whant option is the best when there is no initfs. The current easy way is to change /sbin/preinit in rootfs in flash but it is not optimal. I am thinking about some way to modify kernel command line in currently flashed kernel on the fly and possibly also attaching small initramfs filesystem to it. Any tips regarding this would be helpful. I guess unzipping, changing commandline and re-gzipping and reflashing kernel is doable but I am not sure if initramfs can be attached to kernel or it needs to be loaded by bootloader separately. Advice on this is appreciated. (Any other advice to heed while exploring this I am receptive to hearing as well...) Did you try giving it as the kernel command line: ./flasher -broot=/dev/mmcblk1 Is this commandline stored somewhere in config partition for N900? It would be great to have it there. Sounds like good enhancement request for bugzilla :-) So far the -b option was only one time option when you have usb cable with flasher attached so it is not usable for changing boot sequence permanently. Didn't work for me, though. It seems the kernel module needed for the memory cards is not loaded yet. True. mmc interface is compiled as module now. I wonder why (when considering that we have one mmc card hardwired inside). Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-release
Andrew Flegg wrote: That still seems to be an outstanding question in my mind; what does maemo-release do that maemo-version doesn't? If it is something useful, is it going to be changed to return the right version numbers? I also wonder what is the result. Gabriel, can you let us know what are your plans? IMO maemo-version should stay, old SDK versions should stay too to prevent confusion (i.e. gregale being 2.2 etc.) and the http://wiki.maemo.org/Maemo-releases or other documentation should stay too but use maemo-version instead. Someone helped me to discover maemo-version only recently and until now I planned only to read /etc/maemo_version in my debian/rules. The idea about using it in Build-Depends was new to me, thanks for that. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-release
Gabriel Schulhof wrote: I suppose I should've asked around some more. We can still have interesting discussion now :-) Actually I am not sure if maemo-version solves every problem maemo-release wanted to solve or developers need to solve to have same package for more SDK versions. maemo-version/maemo-release can solve different Build-Depends: fields maemo version provides also /etc/maemo_version so one can check it in /debian/rules when building the package and act differently (include different files, define different variables) What else is needed? How can I differentiate between arm and x86 builds? Example - x86 may use vorbis package but arm can use tremor so Build-Depends: can be different for x86 vs ARM. arm may also benefit from arm specific compiler flags. How can I solve that? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-release
Mikko Vartiainen wrote: How can I differentiate between arm and x86 builds? Example - x86 may use vorbis package but arm can use tremor so Build-Depends: can be different for x86 vs ARM. arm may also benefit from arm specific compiler flags. How can I solve that? I'm not sure why would you want to do that in maemo context. Well, yes, my example was vorbis vs tremor but true that tremor/libivorbisdec is in x86 target too so I can use tremor in both. I don't have any other real world example. But still it could be useful to set different compiler flags for arm (vfp, thumb mode) or workaround some stuff not available in stratchbox environment. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-release
Gabriel Schulhof wrote: Hey, all! I added a package to the extras(-devel)? repositories called maemo-release. It has version 1.0.0 in gregale, 2.0.0 in bora, 3.0.0 in Chinook, etc. ... There already is package named maemo-version in the SDK. And the numbering is different (and consistent with SDK releases), Gregale is 2.2, Bora 3.x, Chinook 4.0, Diablo 4.1, Not good :-( Regards, Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Turning on Automatically when connected to power
Kimmo Hämäläinen wrote: It's called act dead mode and it's a different init run-level (maybe 5?), so if you make /etc/rc5.d to point to the normal run-level (/etc/rc2.d or 3?), it will boot normally. No, this will not solve it completely. The /proc/bootreason is probably checked in some places so it still acts in a strange ways unless /proc/bootreason is really changed as Faheem describes. Old discussion here http://lists.maemo.org/pipermail/maemo-developers/2009-June/thread.html#19572 some version of the patch by kernel hacker qwerty12 http://pastebin.com/f3f36d2df ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: recovery from apt-get dist-upgrade gone wrong
yes, apt-get upgrade is a cake (and cake is a lie :-) Andrea Borgia wrote: plan B, for a way to extract one from another device(*) That should be possible. You need just the rootfs. On working tablet mount rootfs again to some other directory (to get rid of other filesystems mounted on top of it) and create rootfs image of it. Than the linux flasher (flasher-3.5 for Fremantle) should hopefully flash it. Or at least that was it with previous devices that use jffs2 filesystem. There is mkfs.ubifs so hopefully it is otherwise the same or very similar, see here http://www.linux-mtd.infradead.org/faq/ubifs.html#L_mkfubifs Sadly I don't know more details sice I couldn't go to summit and don't have the device. Many things changed with N900. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
David Weinehall wrote: IMHO we have three options: - Real VFAT (with all the drawbacks it brings) - VVFAT - A separate program (PC Suite, most likely) to do the transfers (probably leaving Linux and MacOS users out in the cold) There is also MTP [1]. It is less generic than one would want but still it tries to solve this problem. Too bad there is no generic USB standardized filesystem gadget. 1. http://en.wikipedia.org/wiki/Media_Transfer_Protocol ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
Andrew Flegg wrote: ...because /opt is a hack because no-one at Nokia had the foresight to imagine that users might want to install multiple applications, and large new frameworks like Qt. It wasn't really hard to see this coming. We are booting from MMC since the OS2006 days and one of reasons users do it is that the space in internal NAND is too small. 3 years later someone noticed this problem and we have this ugly /opt hack done in last minutes. Oh well ;-) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How much are Nxxx open?
Nicola Mfb wrote: I come from OpenMoko Freerunner experience, where I'm able to flash the bootloader, the logo, the kernel, the rootfs and have multiple boot option to run several linux distro on different sd partitions. There are two bootloaders, the first in NOR readonly, the second in NAND and is used as default and is flashable, so you are able to use a modern and upgradable bootloader and if something goes wrong are able to debrick it booting from NOR, making the freerunner perfect as a Linux hacking device. Bootloader on N8x0 and 770 is closed. Kernel and rootfs can be replaced but for best experience one needs to stay with Nokia released kernel versions (2.6.18, 2.6.21). Other versions boot too but not everything is working 100% since some bits are closed or never went upstream or were removed due to bit rot (dspgateway). With N900 we don't know yet but hopefully the bootloader will be u-boot. Also the hardware is very similar to other OMAP3 based devices (OpenPandora, Beagleboard, Touchbook, even Palm Pre) so the chance of bit rotting is lower. Previously problematic parts (wi-fi, dsp) are more open now, new 'problematic' stuff is 3d and phone parts. 3d have kernel parts open but userspace is not, phone is hopefully open enough. Overall I guess it will be perfect as a Linux hacking device if you like N900 hardware. The hardware is exposed by kernel in a standard way, e.g. the phone audio connections are managed by alsa while on other fakefree devices (like HTC dream) there are some closed source libraries to do that preventing the port of opensource phone stack (FSO). The oFono phone stack is open. http://lwn.net/Articles/332820/ So may someone explain what's about the N900? How much is it open? Wee need to wait a bit until first hardware gets into our hands. Do we have dmesg log already? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How much are Nxxx open?
Nicola Mfb wrote: With N900 we don't know yet but hopefully the bootloader will be u-boot. That's nice, the best would be if we'll be able to update/replace u-boot, and have a way to debrick the device if something goes wrong. u-boot is just my guess, any other choice does not look sane to me, but still it can be a wrong guess. OMAP3 is designed to be unbrickable, it can boot from usb or serial or mmc directly from its boot ROM, bootloader in flash is not needed. I'm not sure how configurable is the priority list for booting (i.e. if it could be locked to load bootloader only from NAND flash) but hopefully it will by possible to bypass even the bootloader in NAND(u-boot or whatever). See also http://elinux.org/BeagleBoard#BootRom Also the hardware is very similar to other OMAP3 based devices (OpenPandora, Beagleboard, Touchbook, even Palm Pre) so the chance of bit rotting is lower. Previously problematic parts (wi-fi, dsp) are more open now, new May you elaborate please? wifi is exposed normally? In N900? Yes. N8x0 used own closed wireless stack and own closed wlan driver. Wlan driver was opened later but it needs newer kernel which lacks other stuff. See http://stlc45xx.garage.maemo.org N900 uses normal mac80211 kernel stack and the wl1251 driver is open source too. Also apart from Nokia being more open with N900 also TI is more open with OMAP3 in general (unlike with OMAP2 based N8x0) so there is more information available and bigger community overall. beagleboard.org community is quite active Again about that, are applications able to full use opengl acceleration without using closed userspace libraries? Not now. Looks like PowerVR's business model is currently not open source friendly :-) Maybe someone will write open alternative in future? http://forum.openhandhelds.org/viewtopic.php?f=14t=341 Finally, it may be nice if Nokia may donate some devices to FSO and OpenEmbedded core team, any interest/chance about that? We don't know yet about N900 device developer program but it may be useful to join maemo.org community right now and become a karma hunter ;-) For previous program check http://flors.wordpress.com/2007/10/19/n810-maemo-device-program/ http://flors.wordpress.com/2007/11/05/rewarding-community-contributors/ Also having application in Fremantle extras-devel repository might be a good idea :-) Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Howto enable portrait mode support on Fremantle
Alberto Garcia wrote: Landscape is by definition when width height, and portrait when width height Maybe I'm overlooking something, but why would you need any new API? And how would you expect that API to work? Not sure what Fremantle provides but in general there are more modes (90 vs 270 degrees, 0 vs 180) which may be important to your application because of position of HW buttons or maybe camera input format (may be upside down) etc. You can't find this from screen resolution alone. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Howto enable portrait mode support on Fremantle
Andrew Flegg wrote: My interpretation: * You set HILDON_PORTRAIT_MODE_SUPPORT _if_ the device is portrait _before_ you open a window. * You pick up events (DBus or size-changed depending on whether you need orientation or just aspect) and then explicitly set HILDON_PORTRAIT_MODE_REQUEST. Hmm, my interpretation would be: HILDON_PORTRAIT_MODE_SUPPORT - your application is OK with rotation, rotation may happen anytime (depends on user actions or on accelerometer state) and the switch is handled by system automatically HILDON_PORTRAIT_MODE_REQUEST - your application knows better and actively wants to switch the mode right now to landscape ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Howto enable portrait mode support on Fremantle
Graham Cobb wrote: So, why are there two flags? I still don't understand what HILDON_PORTRAIT_MODE_SUPPORT does. This is link that Andre posted before http://wiki.maemo.org/Using_Fremantle_Widgets#Marking_Your_App_As_Portrait_Capable The support flag tells Hildon that it is allowed to rotate your application. The request flag directly puts your application into portrait mode. It´s important to note that all visible windows must support portrait mode, otherwise the screen is not rotated. BTW, in my previous mail please replace landscape for portrait in last sentence ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
closed tools, Re: Maemo Flasher-3.5 Tool Beta for Fremantle and Diablo released
jarmo.ti...@nokia.com wrote: BTW I think flasher is the only closed source tool we have in maemo development environment. Or at least I do not know any other binary only tool :). I think gcc/uclibc toolchain for initfs development would qualify but it is much worse here, we even don't have the tool (despite GPL) :-( https://bugs.maemo.org/show_bug.cgi?id=3373 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: closed tools, Re: Maemo Flasher-3.5 Tool Beta for Fremantle and Diablo released
Dave Neary wrote: I've seen people say that Nokia doesn't even distribute the initfs tools. If that's the case, there wouldn't be any GPL violation. Let's move detailed discussion back to the bug report. Quick and hopefully correct summary is that Nokia is distributing modified uclibc (EABI patched 0.9.28) so we should get at least exact uclibc sources used for building initfs. That is indeed enough to satisfy GPL and also to close the bug report since we can rebuild gcc with such uclibc and make the toolchain ourselves. uclibc is IMO really the tricky part, PCMIIAW but 0.9.28 does not support EABI out of box, there are several (maybe incomplete) patches to add EABI support to 0.9.28 mentioned in uclibc mailing list so it is quite hard to decide which specific version (if any) went into the binary which is distributed with the tablets. The original request is for toolchain binary since my idea was that it is easier for both sides (the binary exists inside Nokia - name was mentioned is OS2007 hacker edition guide, and hopefully there is no reason to keep the sources or binaries of gcc closed). Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Default nice value setting
Nick Nobody wrote: if an application is launched by the menu directly from an executable (using the Exec variable in the .desktop file) it gets a nice value of -1. But, if the application is started over D-Bus (using the X-Osso-Service variable in the .desktop file) it gets a nice value of 0. Which OS version it is? This is a bug, both should have priority 0. Can you reopen that bug Faheem linked with details about your OS version if you see it on current OS version? Oh wait, maybe just forget it, it'll be WONTFIXed anyway for any current system :-) Sadly I think that you cannot raise the priority from 0 to -1 unless being root, you can just lower it so that setpriority call may not help you. The scummvm problem in the bug was different, scummvm didn't like higher priority (or better said - system audio daemon didn't like scummvm having higher priority) so the solution was to lower the priority from -1 to 0 which worked for ordinary user. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Default nice value setting
Henrik Hedberg wrote: If it is really crucial for the application to have higher priority, maybe it could be installed as setuid root. In that way, it could first set priority from 0 to -1, and then drop the privileges. Or postinstall script could add some helper to sudoers which could raise priority when started from inside the application. I think Vagalume uses this trick. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N800 Power cycles
Eero Tamminen wrote: Hi, Is there a way (by changing linuxrc further) to get a lot more information during boot instead of the nice but almost informationfree image? Using the text2screen utility above? Some additional tips are here http://talk.maemo.org/showthread.php?t=16056 With easy modification you may see which /etc/init.d/* scripts are started and syslog may help a lot too. I just noticed that I cannot write that file, the fs is mounted readonly: /dev/root on /mnt/initfs type jffs2 (ro) If I remount it rw mount -o remount,rw /mnt/initfs to do the change, would that break something? No but it allows you (or some code running as root) to mess it up. initfs was more or less writable (i.e. mounted 'rw' but more or less full) since OS2005 days, changing mount options to 'ro' is new in Diablo. Also mounting it 'rw' eats some tiny bits of memory by having extra jffs_gcd_mtd3 garbage collection kernel thread running. Initfs may be too full for changes. You need to remove things first (e.g. initfs factory test stuff you can find -name '*test*'). It was full before Diablo. In Diablo initfs partition was enlarged so there is enough free space at least for N800 and plain N810. The wimax edition has some additional firmware and binaries so the free space may be bad again. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N800 Power cycles
Faheem Pervez wrote: I do not know what provides /proc/bootreason but (if it's the kernel, like I'm hoping), it may be easier to not make it say charger in bootreason if it's booted with a charger. linux/arch/arm/plat-omap/bootreason.c cfg = omap_get_config(OMAP_TAG_BOOT_REASON, struct omap_boot_reason_config); strncpy(boot_reason, cfg-reason_str, sizeof(cfg-reason_str)); Should be easy to replace charger for pwr_key there. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N800 Power cycles
Rainer Dorsch wrote: Under which circumstances is the N800 started automatically, when the power supply is plugged in? N800 is always started when you plug it in. The difference is in unix runlevel the device boots into. Normal is runlevel 2 when maemo-desktop starts fully. When bootreason (/proc/bootreason) is 'charger' it boots into runlevel 5 with slightly different boot sequence which in final stage shows only charging icon but otherwise the system behind it is almost fully booted. So in theory you can have reboot loop which happens only in runlevel 5 and not in runlevel 2 if the failing part is specific to runlevel 5. Maybe you saw this? More details is in /mnt/initfs/linuxrc in function enter_state(), normal mode is USER state, charging mode is (or is one case of?) ACTDEAD state. I hope I am not wrong about this. Personally I don't like this behaviour so I am always powering device by power key and if I know battery is empty I have charger prepared and plug it in just after screen lights up to avoid this charging mode. There is short window of time to do this before dsme/bme starts and decides to shutdown the system due to low battery. It would be interesting to modify linuxrc to go to runlevel 2 even in this charging state and see if it manages to boot normally. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N800 Power cycles
Anderson Lizardo wrote: It would be nice if some kind of emergency menu be available where the user would either return to a previous good state (e.g. a file system image previously saved in a MMC) or at least allow to run some tasks to free space or defragment/fsck the JFFS2 partition (if that is possible). If that does already exist (even as a community tool), I'd like to know about it :) https://wiki.maemo.org/Booting_from_a_flash_card#Install_bootmenu http://fanoush.wz.cz/maemo/#initfs also search talk.maemo.org for 'bootmenu' You can either boot into clean system copy (mmc or flash) or you can log in over usb networking if you don't have full system to boot. backing up whole rootfs as jffs2 image to mmc and restoring is possible too via mtd-utils commands (search t.m.o for mkfs.jffs2) Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo UI
Hubert Figuiere wrote: The real problem is that PDF is not a format for electronic books. Because it hardcodes paper size and layout, it is not independant of the media. PDF is a format for digital rendering of printouts. They've added to some relatively recent version of pdf format (5?) the possibility of reflowed PDFs to support ebooks. Not sure how well it works in reality. See http://www.adobe.com/uk/epaper/tips/acr5reflow/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: BeagleBoard and maemo
Kees Jongenburger wrote: Hi For next week's hacking week-end I want to install maemo 5.0 beta on the beagle. http://maemo-beagle.garage.maemo.org/ only talks about the alpha. Got my BB yesterday and was wondering the very same thing :-) Maybe all Nokia devs finally got their OMAP3 tablet prototypes so no need for Beagle anymore? ;-) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to get a program window into the task/window switcher?
Faheem Pervez wrote: P.S: Frantisek, have any plans on updating the Game_development wiki page with your tip? It'd help those who do not subscribe here. I just did and kept both variants. I don't know what is the lifecycle of those two windows so I'm not sure when it is effective to set the title of both windows and how long it lasts. At least in Maemo where screen resolution/depth does not change it looks like the are both allocated once in the beginning and kept all the time so the title sticks when set like this when switching fullscreen on on off. The 'if (win)' is needed for me in scummvm since I have no precise control of when the title is set and I've seen segfaults in XStoreName when it was called too early at startup. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to get a program window into the task/window switcher?
Faheem Pervez wrote: For C programs, Mikkov made the following code which works a treat for SDL stuff: http://wiki.maemo.org/Game_development#Set_the_window_title This is great and works fine to set first line in task switcher window list but it would be nice to put something to second line too like hildonized apps do. Any tips for setting second line from SDL/x11 C code? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to get a program window into the task/window switcher?
Faheem Pervez wrote: char *name = Title to show on first line - Title to show on second line and then pass that char to XStoreName as the third argument: Indeed. Thanks for figuring this out. One definitely needs the - part including spaces there. BTW as for the Mikkov's wiki code sample I've ended with seting both windows at once no mater if fullscreen or not. This saves me updating title of the other window after each fullscreen switch. win = info.info.x11.fswindow; if (win) XStoreName(dpy, win, title); win = info.info.x11.wmwindow; if (win) XStoreName(dpy, win, title); Seems to work for me. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SGX Driver (was Re: Frets on Fire on Fremantle)
Kimmo Hämäläinen wrote: I think the interface that is used to communicate with SGX is not public, so it would be quite challenging to implement your own drivers. (Not to speak of the million lines of required code...) There is interesting attempt in planning stage http://forum.openpandora.org/viewtopic.php?f=14t=341start=0 It does not target OpenGL API family but something more low level. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: kernel source and maemo fremantle
ext Leandro Sales wrote: Hi all, I'd like to know if I can do make n800_defconfig to set the proper kernel configs for fremantle. Try rx51_defconfig or rx51_tiny_defconfig. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Screen orientation
gary liquid wrote: thanks for the reminder :) I have put together a report including test cases on the itt forum http://www.internettablettalk.com/forums/showthread.php?p=261099 I have added my comment there but I'm not sure where is the best place to discuss it. I am not sure where the problem originates from so putting the issue centrally is the best option. I believe the problem is in kernel or starts in kernel. The first patch By Rodrigo Vivi has additional part mentioned here http://www.internettablettalk.com/forums/showthread.php?p=155704#post155704 This part caused video and camera to not to work at all. Quick hack was to remove those lines so dimensions of planes are not touched but I still believe this is wrong (to remove them) and plane information should be somehow correctly rotated too. It would be nice to know how exactly those 3 planes are used (plane 1 is XV? 2 is camera?) and what sizes they should normally have. After system boot virtual_size (/sys/class/graphics/fb?/virtual_size ) of all of them is set to 800x480 but after using stock media player or enabling camera they are resized to much smaller size (not sure when and how). Maybe those lines should be put back to kernel but the userspace code (Xv driver in Xserver? what about camera?) that plays with dimensions of those planes should be somehow make aware of the rotation and resize them again as they need. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Does anyone know the mechanism in Nokia's LCD driver?
Huang Gao (Gmail) wrote: Dear all Maemo fans: I just noticed that Maemo used a different mechanism in LCD driver from normal FB drivers. It seemed that Maemo does not use the automatic DMA refresh in the driver, which is replaced by an ioctl named OMAPFB_UPDATE_WINDOW, and a method called TEARSYNC. However, I am confused why it will improve the performance of graphics applications. Is there anyone that may give me some tips on this topic? This was done because of relatively high resolution (800x480x16 bits). Automatic DMA would continuously steal a lot of SDRAM cycles and slowed down everything. Perhaps it would also eat more power and prevented system from sleep when the display is on. I wonder if this is still the case for upcoming OMAP3 based device. BTW, there is kernel ioctl to set automatic refresh and the refresh rate can be tweaked in kernel source but the results are suboptimal. Maybe at least for Nokia 770 it would be possible to use tearsync flag for such automatic update and set the update timer to lcd refresh rate or lcd refresh rate/2 to get nice result. N8x0 cannot update whole screen in one lcd refresh cycle anyway so you'll always get tearing on the bottom. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Does anyone know the mechanism in Nokia's LCD driver?
Siarhei Siamashka wrote: XV should make a perfect backend for SDL, because it maps fine on SDL API (SDL_SetVideoMode/SDL_Flip/...). In general, XV is a good backend for anything that uses double-buffered or triple-buffered fullscreen/fullwindow blits. It is possible to get ~27.5 frames per second in 800x480 resolution for 16bpp rgb color format without tearing. With a lower resolution it is possible to go up to ~55 frames per second. Hmm, I hope there is some work done on this front (Xv or even openGLES based backend for SDL) for Fremantle. The alpha release has same old 1.2.8-23 SDL version though. Or is there some alternative to SDL for 2D graphics? BTW, as for the external lcd controller status - I have just checked and CONFIG_FB_OMAP_LCDC_EXTERNAL is disabled for both RX-51 confugurations in Fremantle alpha kernel (unlike e.g. PowerVR stuff) so maybe we finally has directly mapped framebuffer in SDRAM ? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: what's the function of bme-dbus-proxy?
Alex T. W. LEUNG wrote: Hi maemo team, Does anyone happen to know the role / function of bme-dbus-proxy? What unique function does it provide, in contrast to the bme daemon process? At least for current devices bme is started early on boot from initfs partition and is linked to uclibc. My guess is that it was not possible to put dbus support directly to bme so there is this proxy which implements dbus bme interface and talks to real bme over some unix socket. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
osso-statusbar-cpu Re: Beware Personal launcher
Santtu Lakkala wrote: Frantisek Dufka wrote: osso-statusbar-cpu does exactly this. With memory reporting turned off it is nice statusbar clock with black background. Once the background turns solid blue you know there is a problem :-) Actually it should have graphs of cpu and/or memory usage, not black background; there's just a bug I haven't fixed that causes it to be black by default. If you change the settings, it should start to work. Sorry for the confusion, it does have graph of CPU usage. I don't see any bug. I meant that in normal case CPU usage is pretty low so it is mostly black. BTW long time ago I got chinook version from http://people.debian.org/~tschmidt/maemo/chinook/osso-statusbar-cpu/ Yesterday I noticed there is also 0.7.x (since June 2008) with 'official' chinook support in maemo-hackers.org repository http://maemo-hackers.org/apt/pool/main/o/osso-statusbar-cpu/ Both of them work fine, they just look different. With default OS2008 theme I like a bit more the old 0.6.1 look with thin border :-) Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Beware Personal launcher
Till Harbaum / Lists wrote: Unfortunately there's no fan on the n8x0 becoming noisy if the device is under heavy load. So even a simple thing like a taskbar icon indicating a high cpu load and being able to present something similar to the windows task manager might help. osso-statusbar-cpu does exactly this. With memory reporting turned off it is nice statusbar clock with black background. Once the background turns solid blue you know there is a problem :-) http://inz.fi/blog/category/geeky/maemo/maemo-hackers/osso-statusbar-cpu/ Chinook build works in diablo too http://people.debian.org/~tschmidt/maemo/chinook/osso-statusbar-cpu/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: ICd2 header files released
Patrik Flykt wrote: Hi, It's been a while, but the promised ICd2 header files are released for Diablo[1]. With the help of the ICd2 header files networks such as USB and BT PAN can be integrated more tightly into ICd2 without relying on glue provided by the dummy network. The header files themselves are available as BSD, but ICd2 itself is still Nokia proprietary. The header files are documented in Doxygen syntax. Excellent, thanks ! Do you think source to dummy network could serve as a good skeleton and example in addition to the documented headers? If yes, is it relatively easy to release its source? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo Bug Jar #30
Stephen Gadsby wrote: A Quick Look at Maemo Bugzilla (https://bugs.maemo.org/). 2008-11-03 through 2008-11-09 As of 2008-11-10 Maemo Bugzilla contains 2973 (+4 this week) items, including 1008 open issues (-14 this week): * 619 open bugs (-11 this week) ... * 16 easyfix (+1 this week) ... * 16 patch (+1 this week) that is +1 for patch and +1 easyfix but below with detailed list there is no listing for this easyfix+patch bug ==--- Keyworded Items ---== ( glossary: https://bugs.maemo.org/describekeywords.cgi ) ... 0 bugs were tagged easyfix. ... 0 bugs were tagged patch. Is this Bug Jar bug or feature? The +1 patch+easyfix bug not listed in keyworded items is here: https://bugs.maemo.org/show_bug.cgi?id=2747 - inconsistent mmc device naming at boot time when one card is missing Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to get a general utility package cross-listed from tools to extras?
tz wrote: This is no longer academic as my minigpsd program is sitting in extras-devel, and the ONLY problem it has is the bluez-utils-test dependency. Well, maybe bluez-utils-test is in SDK repository because it is mainly for testing? What part of bluez utils you need? Bluez moved to handling most things via D-bus so command line utils like rfcomm, hcitool etc are no longer the only (or even the preferred) way to do things. So maybe instead of using them you may start to use d-bus? I went this way with kbdd and did everything I needed (open rfcomm connection). See dbus-bluez-* stuff and btkbd inside http://fanoush.wz.cz/maemo/kbdd.tar.gz API is described here http://wiki.bluez.org/ Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Projects Nokia should support (yours?)
Quim Gil wrote: I'm a bit surprised about the little discussion generated by our call to support cool projects. Was the call so casual that it ended up being unclear? Well, to me it is a bit unclear how Nokia could help to specific projects. IMO all developers will benefit from - early SDK release(s) and documentation - somewhat accurate device emulation or developer device program (with devices reaching developer hands before end users) - in general as much information as possible preferably to everyone If we get this then no special help may be needed. What kind of support? Whatever those cool projects under development need to be stable and exciting for real users. You tell us and we will do our best helping you. Do you have anything specific on your mind? What kind of help Nokia expects to provide in this support project? Does it include @nokia.com developers who will help with porting specific code to newer OS? I guess not. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Projects Nokia should support (yours?)
Frantisek Dufka wrote: this should be available to anyone who asks/subscribes (even to avoid duplicate effort for same issues of self-help from other developers). s/of/or/ 'even to avoid duplicate effort for same issues or allow self-help from other developers' ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Projects Nokia should support (yours?)
Huh, the correction went through sooner than original text, here it is again, please disregard if you already have it. I don't see it in list archives or my maemo-developers received mail folder. Original Message Subject: Re: Projects Nokia should support (yours?) Date: Wed, 22 Oct 2008 10:48:22 +0200 Quim Gil wrote: Access to hardware before sales start is expensive and highly regulated. I see. Well, even at the same time as end users would be very helpful (=posible discount codes working since day 1). Nokia provides such access business-as-usual to certain developers, usually through commercial or research agreements with private or public organizations. Doing the same for individuals or small groups without a legal entity is something we could do in Maemo. But you see our point of working with a selected list of projects beforehand. I see. Sounds great :-) Then how do you explain that so many promising community projects fail in the last mile (or before)? Some developers look for more time, some projects look for certain skills, some look for more testing, more feedback, more help... Yes but I am not sure targeting only selected group is ideal. Maybe we can have focused maemo-fremantle-porting mailing list or discussion forum or irc channel if maemo-developers is too noisy/broad for that. Having few skilled people watching it with greater care providing help you mentioned would be indeed nice. But this should be available to anyone who asks/subscribes (even to avoid duplicate effort for same issues of self-help from other developers). If you are afraid of too many people asking for help then those who help can perhaps decide what is worth of helping without doing the selection now. Does it include @nokia.com developers who will help with porting specific code to newer OS? I guess not. Why not. Surely the work wouldn't be done by the Maemo SW developers busy stabilizing Fremantle That was precisely what I wondered. Every competent developer will be busy chasing last minute bugs :-) , but why not funding someone else to work on that. Great so what about someone providing such support channel with answers, examples, testing and packaging help? maemo-developers is good even now, we have several great Nokia people here but if someone is funded to go the extra mile it may make some difference. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Projects Nokia should support (yours?)
Quim Gil wrote: Access to hardware before sales start is expensive and highly regulated. I see. Well, even at the same time as end users would be very helpful (=posible discount codes working since day 1). Nokia provides such access business-as-usual to certain developers, usually through commercial or research agreements with private or public organizations. Doing the same for individuals or small groups without a legal entity is something we could do in Maemo. But you see our point of working with a selected list of projects beforehand. I see. Sounds great :-) Then how do you explain that so many promising community projects fail in the last mile (or before)? Some developers look for more time, some projects look for certain skills, some look for more testing, more feedback, more help... Yes but I am not sure targeting only selected group is ideal. Maybe we can have focused maemo-fremantle-porting mailing list or discussion forum or irc channel if maemo-developers is too noisy/broad for that. Having few skilled people watching it with greater care providing help you mentioned would be indeed nice. But this should be available to anyone who asks/subscribes (even to avoid duplicate effort for same issues of self-help from other developers). If you are afraid of too many people asking for help then those who help can perhaps decide what is worth of helping without doing the selection now. Does it include @nokia.com developers who will help with porting specific code to newer OS? I guess not. Why not. Surely the work wouldn't be done by the Maemo SW developers busy stabilizing Fremantle That was precisely what I wondered. Every competent developer will be busy chasing last minute bugs :-) , but why not funding someone else to work on that. Great so what about someone providing such support channel with answers, examples, testing and packaging help? maemo-developers is good even now, we have several great Nokia people here but if someone is funded to go the extra mile it may make some difference. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: R: Can't force display light to stay on forever?
Owen Williams wrote: Is there a good way of doing this temporarily, for instance while playing back video? Can I do it in python? You need to periodically call osso_display_blanking_pause in libosso http://maemo.org/api_refs/4.1/libosso-2.16-1/ http://maemo.org/api_refs/4.1/libosso-2.16-1/group__Devstate.html#gbd82d7b0160e26cd15479f2685697322 Not sure if there is python binding but it is quite likely. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: R: Can't force display light to stay on forever?
Frantisek Dufka wrote: Not sure if there is python binding but it is quite likely. If not, you can use d-bus to tell it to MCE directly, see the source http://mxr.maemo.org/diablo/source/libosso-2.16/src/osso-hw.c#89 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: programming on the n800 itself
Hendrik Boom wrote: That's acceptable. How did you install gcc and those libraries in teh first place? apt-get, gcc is in SDK repository http://repository.maemo.org/pool/chinook/free/g/gcc-3.4/ As for reducing big memory requirements of gcc see http://www.internettablettalk.com/forums/showthread.php?p=220028#post220028 Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: stlc45xx: open source WLAN driver for N800 and N810
Kalle Valo wrote: I'm excited to announce a new project called stlc45xx, an open source WLAN driver for Nokia N800 and N810. Excellent news, many thanks Nokia :-) This saves our N8x0 tablets from bitrotting. And hopefully 770 too. Now it actually makes sense to beat linux-omap into working shape for all current tablets giving them extra life for years. It's using mac80211 stack included in Linux since 2.6.22. I wonder what kernel will Fremantle use. Would be nice to run it with same kernel and switch between wi-fi stacks on the fly. Our aim is to run the project in community mode and all community contribution is very welcomed. Will definitely try. 770 support comes to my mind first, current stlc45xx_readXX/writeXX code uses SPI framework, 770 has the chip connected over McBSP port. Should be posible to either resurrect direct McBSP code back or maybe add its driver it into SPI framework. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: stlc45xx: open source WLAN driver for N800 and N810
John Holmblad wrote: Frantisek, ok, you got me. bitrotting? May I surmise that that is what happens to files, hw software when you throw them in the bit bucket aka the trash-heap of digital history? Yes, this happens also to linux kernel and all software running on the tablet. Having free wi-fi driver means open possibilities to have newer systems ported to the tablet (like Android for instance) so people are not permanently stuck with ancient software on the tablet. Until now it was possible to use wi-fi on the tablet only with 2.6.16, 2.6.18 and 2.6.21 linux kernels (all quite old today) and only in specifc configurations that do not break closed wi-fi driver module. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: stlc45xx: open source WLAN driver for N800 and N810
Kalle Valo wrote: Nokia 770 has stlc4370 and documentation for that chipset is not available. I'm not aware of the differences between stlc4370 and the newer chips so I cannot say how much work there is needed to get the driver working in 770. Not good :-( But still, the driver talks to the firmware and so far you were shipping both (3825/3826.arm) firmwares together so I hoped they offer same API when accessed over SPI. Or do you have some special and different 3826.arm firmware now for open source driver? Or is the difference in umac.ko for 770 vs N8x0? I hope not, I think Poky people were succesfull with 2.6.18 kernel and umac.ko for N800 runing on 770. So can we take the firmware as working black box offering same functionality for both chips? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SDK, sources Re: On the problem of Nokia bugs substituting changelogs
Frantisek Dufka wrote: So will we get updated SDK release with sources for latest Diablo update (and any further one too)? No answer, looks like people responsible are busy with more important stuff. Just an additional info - old SDK also hurts people when doing development directly on tablet, see this one http://www.internettablettalk.com/forums/showthread.php?p=220639#post220639 The 4.2008.30-2 update was released 08-11-2008 so it is more than 3 weeks now. Also can this whole firmware and SDK release procedure be changed so building and releasing sources is integral part of building and releasing any binary (firmware or SSU) as it is 'suggested' by GPL licence? Does it make sense to report this as separate bug in bugzilla? Or is it in wiki 2010/100days agenda somewhere? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SDK, sources Re: On the problem of Nokia bugs substituting changelogs
Quim Gil wrote: (It is discouraged to install SDK packages in the devices. If someone wants to do this fine but as the own post you link says it might be *hazardous*. OK. We are also discouraged from having root access on the device ;-) The hazardous part here was mainly installing old packages to new system because of old -dev packages in current SDK. Otherwise having SDK repository configured on device is pretty sensible thing to do for any competent developer just like root access (discouraged or not). This is how the process works. This time there was one exception because the mentioned events related to this WiMAX code - see also https://bugs.maemo.org/show_bug.cgi?id=3648#c3 Our apologies and hopefully this won't happen again. Thank you and apology for missing bug 3648. I should better check bugzilla next time. Sorry for creating too much noise too late. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
SDK, sources Re: On the problem of Nokia bugs substituting changelogs
Hi Quim, nice to see you back :-) Quim Gil wrote: but there are others that are about as bad as they could get. Let's list them too, and we will show them the previous list for reference on how a Nokia team can do things right. Another bad example here is the kernel, search the http://p.quinput.eu/debfarm/changelog.html file for 'kernel-diablo'. We can see only '* Updated kernel version XXX' instead of real info. So basically we are completely in the dark if new kernel actually fixes something or not. This is yet another annoyance to the fact that we still don't have updated sources in http://repository.maemo.org/pool/diablo/free for GPLed stuff updated in latest 4.2008.30-2 Diablo update. This is of course bad for any GPLed package but it causes practical problems especially for linux kernel source. There are a lot of kernel hacks in the wild and after each firmware people must choose between older customized kernel and new (possibly fixed? how can we know?) one. So will we get updated SDK release with sources for latest Diablo update (and any further one too)? Also can this whole firmware and SDK release procedure be changed so building and releasing sources is integral part of building and releasing any binary (firmware or SSU) as it is 'suggested' by GPL licence? We discussed this topic many times here with no visible change so far. Random pointers to previous discussion: http://lists.maemo.org/pipermail/maemo-developers/2008-January/031424.html http://lists.maemo.org/pipermail/maemo-developers/2008-January/031426.html Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SDL, pixel format and little endian issue
Michael Stepanov wrote: Hi, I have a SDL application where I have to replace color of specified pixels. So, I have a color in RGB representation and convert it to the pixel color using that approach: Uint32 PixelSrc = (0 PF-Rshift) | (128 PF-Gshift) | (192 PF-Bshift); But as result I get color 0x10c0 instead of 0x0080C0. Why it's happens? You did not mention pixel format, if you use device native 16 bit format (RGB565?) you cannot use values like 128 or 192 since it will overflow 5 or 6 bits. Also you should do proper masking. Moreover, I found following values for Xshift for little endian: const int rshift = 0, gshift = 8, bshift = 16, ashift = 24; Uini32 PixelDest = (0 rshift) | (128 gshift) | (192 bshift); But the byte order is different. I get 0xc08000 but it should be 0x0080c0. 00c08000 seems fine to me for 00 | 0x808 |0xC016. I think you should add a bit more of your example code and also tell us what you want to do (and maybe even why). Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Tasknavigator icon sizes and usage not documented Re: Maemo Bug Jar #19
Stephen Gadsby wrote: A Quick Look at maemo Bugzilla (https://bugs.maemo.org/). 2008-08-18 through 2008-08-24 Hi, I am missing bug https://bugs.maemo.org/show_bug.cgi?id=3619 - Tasknavigator icon sizes and usage not documented in your list. Maybe there is bug somewhere? I even hoped people would have a look at it and add few comments when it is mentioned in bug jar. I would like to know how this should really work. In fact I should perhaps fill another bug. But since I don't know how it should work I'm not sure this is bug or feature. I am building scummvm as one package installable in all IT200x systems. It worked fine but recently I noticed one little issue. With OS2008 we have big nice icons by default in menu. I do supply lot of icons at random sizes in upcoming 0.12 release but still OS2008 shows small icon unless I remove scummvm.xpm and rebuild icon cache and reboot. Unfortunately OS2006 works only with this icon, it doesn't see other png ones. So currently I hacked it to check OS version and remove xpm icon in postinst script on OS2007 and up but I don't think this is proper solution. If someone is interested in checking the package, it is here http://www.internettablettalk.com/forums/showthread.php?t=23071 Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Tasknavigator icon sizes and usage not documented Re: Maemo Bug Jar #19
David Greaves wrote: Stephen J. Gadsby wrote: Hi, I am missing bug https://bugs.maemo.org/show_bug.cgi?id=3619 - Tasknavigator icon sizes and usage not documented This is a web site bug, and the Bug Jar stopped including those a few weeks ago. It focuses on just Maemo software now, as several people commented the web site bugs were unnecessary noise in the summaries. I'm not sure that this is a 'website' bug. I am not sure too. When I reported it I tried to file it in Maemo Software - Documentation then Maemo Software - Development platform but did not find any suitable component. At last I simply clicked link Improve this page on the bottom of http://maemo.org/development/documentation/tutorials/maemo_4-0_tutorial.html I was not happy about the Website category from the beginning but now I see there is additional disadvantage of being lost in the noise :-) Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Location of /home, /tmp and /var folder kills tablet device in a couple of months
Jason Edgecombe wrote: I think you're much better off by leaving the internal flash alone and just booting straight from SD card. Yes. You also won't save much space, 'df' and 'du -sk /usr' tells that most of the meat is in /usr anyway so full clone is not that much bigger. And it really simplifies things a lot to keep system on card and internal flash separated. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: border in osso-xterm in fullscreen?
Stefan Kost wrote: Sounds good. Have you filed an enhancement request at bugzilla.gnome.org? Should be easy to fix. Seems like this was reported year ago http://bugzilla.gnome.org/show_bug.cgi?id=471920 I have added comment. BTW if anyone cares about this you can get recompiled libvte for Diablo here http://www.internettablettalk.com/forums/showthread.php?p=211159#post211159 Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Location of /home, /tmp and /var folder kills tablet device in a couple of months
Oliver wrote: The main problem here are for example the Browser Cache and E-mail directory in /home and other data that is stored in /tmp or /var. This data all result in many write accesses to the internal flash device and in the long term this will have the result that the Tablet can't store new data on the internal flash device which makes the tablet useless. See some explanation in http://bugs.maemo.org/show_bug.cgi?id=598#c9 If you are concerned about this you can also boot whole system from SD/MMC card - http://wiki.maemo.org/Booting_from_a_flash_card Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Multi-boot Diablo and Chinook
David Greaves wrote: Hi all So I've been trying to get my N800 to multi-boot into an everyday Diablo and a 'clean' test install of Chinook and Diablo. This is perfectly possible. I'm runing everyday Chinook and 'clean' test install of Diablo. Kernel and initfs is from Diablo. I've written up my progress here: https://wiki.maemo.org/Advanced_booting and now I'm stuck. Neither the Chinook nor Diablo partitions run correctly; they both progess to about 90% (blue line on bottom of splash screen) and then reboot. I'd appreciate some assistance :) I don't see anything wrong, few random hints - extract rootfs.jffs2 from .bin again and never mount it rw on desktop i.e. do 'mount -t jffs2 -o ro /tmp/mtdblock0 /tmp/jffs2' on PC. I've seen corruption of the image if mounted rw on PC. - use tar instead of rsync (should not make much difference) - performance tip - mount destination ext2 with noatime, run rsync with --inplace to prevent creating 2x more files in destination (one temporary, one real) Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: border in osso-xterm in fullscreen?
Andrew Zabolotny wrote: From Wed, 06 Aug 2008 14:31:08 +0200 Frantisek Dufka [EMAIL PROTECTED] wrote: I'm wondering why fixed font with height of 16 won't give me full 30 lines in osso-xterm but 29 lines plus one empty line on the bottom. Anyone knows answer to this mystery? Of course that's because the height of the client window area is not divisible by the fonw height. Unlikely. Well, it can be bug in fonts or freetype/gtk/pango (whoever decides font height from the font file) but most probably it is just because the font is not rendered from the top so there is 1 or 2 lines missing on the bottom. I tried two 16px/12pt height fonts both having the same problem Fixedsys Excelsior http://www.fixedsysexcelsior.com/ Terminus http://fractal.csie.org/~eric/wiki/Terminus_font http://chlamydia.fs.ei.tum.de/~corecode/unsorted/Terminus.ttf BTW, later I tried this also in Gnome terminal in Ubuntu 8.04 and I see exactly the same problem when in fullscreen mode (F11, right click - turn off menu bar). Screen height 800 is divisible by 16 but I see same empty line on the bottom and same hairline white border around Midnight Commander's blue panel and see only 49 lines instead of 50. This also means it is not Maemo specific so it does not belong here. You may want to try DejaVu Sans Mono, the pre-packaged DejaVu fonts can be downloaded here: http://cs.ozerki.net/zap/maemo/dists/diablo/main/binary-armel/ttf-dejavu_2.25-1_all.deb In my opinion, DejaVu Sans Mono gives a much nicer appearance to the terminal. Tried it just to verify the bug and now I have another mystery :-) I am no expert on font sizes and units but from the information on the net it looks like there are two main units - pixels and points. Point is 1/72 inches so 1 pixel = 1 point at 72 dpi. At 96dpi (our tablet or any MS Windows OS in normal configuration) 1 point is 1.33 (or 4/3) pixels so 12 points = 16 pixels. On tablet this should produce 480/16=30 lines. The mystery is that Dejavu font at 12 points gives me only 25 lines + some tiny space like 2 pixels. And same happens for Courier New copied from Windows. This would mean pixel height for those fonts is slightly more than 480/25=19.2, why?. As for Dejavu/Vera fonts and other scalable fonts in general - they are great but IMO at small sizes nothing can beat bitmap fonts. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: border in osso-xterm in fullscreen?
Giacomo Tufano wrote: http://en.wikipedia.org/wiki/Em_(typography) have, probably, the informations you're looking for. The answer to the Frantisek problem is, IMHO, that (citing the page) In digital type, the relationship of the height of particular letters to the em is arbitrarily set by the typeface designer. However, as a very rough guideline, an average font might have a cap height of 70% of the em, and an x-height of 48% of the em. These differences could account for the numbers Frantisek found... Thanks. So one basically cannot guess how many lines will fit from the point size alone, it depends on specific font and its designer. Quite confusing but nevermind :-) As for the first mystery - I found the solution. vte-0.12.2/src/vte-private.h #define VTE_PAD_WIDTH 1 When changing to 0 and rebuilding libvte4 it fits. Sadly same constant is used for padding width and height which is pretty unfortunate. Left border padding would be nice, without border there is no space and letters touch black LCD border and look a bit strange. Top and bottom border doesn't look so bad. I think splitting VTE_PAD_WIDTH into VTE_PAD_X and VTE_PAD_Y would be useful. And making it variable would be event better. Both for user customization and for computing it at runtime for proper centering when font size doesn't fit exactly. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
border in osso-xterm in fullscreen?
Hi, I'm wondering why fixed font with height of 16 won't give me full 30 lines in osso-xterm but 29 lines plus one empty line on the bottom. Anyone knows answer to this mystery? My theory is that there is 1 pixel border around terminal widget (but not scrollbar) so it won't fit because of 1 or 2 missing pixel lines on the bottom. If you set border in osso-xterm to white an run some fullscreen terminal application with colored background (like midnight commander) there is thin white line around it. I have searched matchbox and gtk theme files, diablo version of osso-xterm and libvte sources but did not find anything suspicious. Ideas? Since the color of the border actually changes when changing osso-xterm window background color setting it looks like terminal widget gets full area for drawing but still the font is drawn with thin border i.e like drawn at 1,1 coordinates instead of 0,0. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Chmod Issue on 810
Dr. Nicholas Shaw wrote: Frantisek, I tried the link and the deb file for sqlite3 but it is not installable on Chinook, incompatible application package. Sigh... Download it and run 'dpkg -i sqlite3_3.4.1-1osso3_armel.deb' as root. Application Manager can install only 'user friendly' packages and this limitation is deliberate. sqlite is not such package so you need to use dpkg (or apt-get install when package is in repository). Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Chmod Issue on 810
Graham Cobb wrote: On Thursday 31 July 2008 23:11:49 Dr. Nicholas Shaw wrote: Graham Cobb has sqlite3? Ok, over to his web site... :-) Sorry, Nick, no. I have sqlite (including the sqlite shell), but not sqlite3. http://lists.maemo.org/pipermail/maemo-developers/2008-June/033562.html Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Community Kernels garage project created
Hello, this was already discussed here http://www.gossamer-threads.com/lists/maemo/developers/36516#36516 but nothing happened. Today GeneralAntilles mentioned it again http://www.internettablettalk.com/forums/showthread.php?p=203080#post203080 so I have finally sumbitted request for garage project which was approved - https://garage.maemo.org/projects/kernels/ Primary goal is to accumulate kernel patches so they do not get lost, secondary goal is to build kernel images for all devices and latest versions of all IT200x releases. Patches should primarily apply to kernel sources release in Maemo SDK (i.e not current linux-omap). I am currently not the best admin for this project (daughter born last week :-) so feel free to join and help. Good place to discuss ideas is perhaps open-discussion forum of the project https://garage.maemo.org/forum/forum.php?forum_id=2801 Big question is to how to structure patches and where to keep them (directly in svn tree, tracker). Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Community Kernels garage project created
nick loeve wrote: Congrats! I am willing to put in some time, and I see Im already an admin of the project :) Excellent. Yes, anyone competent that wants to help (even with administration) is welcome. As I explained I don't have much spare time so I don't want to slow down anybody. The GA's idea of packaging set of patches properly so they can be pushed to extras-devel (and built by autobuilder) as specific community kernel release makes perfect sense. My first idea was just to keep source patches somewhere but this could make life significantly easier for end-users too. This will need some additonal (admin and debian related) work I did not expect at first. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
770 info in wiki Re: Has maemo-pc-connectivity been substituted by USB Networking applet (in control panel)?
Dave Neary wrote: Information for older OSes or for the 770, should be (IMHO) a footnote at lest, or a reference to an archived page which doesn't show up when browsing the wiki normally. Well, I would not be surprised to hear such opinion from @nokia.com but I am a bit surprised to hear this from @maemo.org :-) Nokia 770 is not dead. There are still plenty of users of 770. You can still buy 770 new in a box on ebay and used devices change hands to new users who need information too. Please be careful with removing 770/OS2006 or 2007(HE) information. Also people still use N800 with OS2007, latest in not always greatest :-) Perhaps the newest stuff should be first but footnote or archived page is going too far IMO. Can we tag pages or sections with OS/device names? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
building from source requirement, scummvm Re: Diablo extras repository proposal
Graham Cobb wrote: A week is a long time for someone funded to work on this full time. It is nothing at all for people working on this in their spare time! Exactly :-) In my case, a big problem is dependencies which were previously uploaded into Extras without sources. In my case of scummvm I have following problems 1. dependencies scummvm depends also on mad, tremor, flac and mpeg2 which I compiled and 'make install'-ed from tar.gz into my scratchbox environment. Most possibly they are in debian but I need to hunt them. I avoided the problem so far by linking them statically (they are quite small and I prefer to not to have too many dependencies anyway). 2. specific library build options AFAIK flac must be built without ogg containter (not default) because of tremor, tremor provides ogg too, but is incompatible with real ogg in reality this means for me that -lFLAC needs also -logg by default, -logg and -livorbisdec together produce duplicate symbols, scummvm needs both flac and tremor(a.k.a. ivorbisdec) Maybe it is solvable without building flac in special way (no ogg) but so far I had no time to solve it. 3. internal compiler error scummvm is buildable with -Os (my preferred option) but one source in kyrandia engine fails with ICE both with -O2 and -Os Only -O3 or no optimization works. Currently I don't know how to tweak makefile for this specific source. 4. how to make buildable source :-) I am sorry for being so ignorant but how exactly do I produce debian source that can be uploaded? I am still packaging newbie. Any direct links to howtos appreciated. Overall I like the idea of autobuilding from source very much but sadly it will take me a lot of time to make scummvm buildable. Also so far any work on the actual code (scummvm or other) had higer priority and my time is limited. You guys are forcing me to either change priorities or sabotage you worthy goal, tough choice :-) If anyone could lend a hand, you can get 0.11.1 release tarball from scummvm.org, search the README for Maemo and try. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Diablo released
Quim Gil wrote: SDK announcement to land soon. It is great to have kernel source at the same time, many thanks. http://repository.maemo.org/pool/maemo4.1/free/k/kernel-source-diablo/ Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Making a custom root FS
D. Scott Brown wrote: 3. extract the rootfs from the retail image, mount it, and tar it. If I mount the JFFS2 using kernel memory emulating a MTD, I get error inserting mtdram - cannot allocate memory. If I mount the JFFS2 using block device emulating MTD, the tar fails with tons of read errors at byte 0. Check script and folowup posts here http://www.internettablettalk.com/forums/showthread.php?p=192475#post192475 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Community council is a representative body - not community leadership (upate2)
Darius Jack wrote: Yesterday I had a dream. Great dream. I was reading news using newspaper-like monitor. Wow, just wow. Couldn't resist and did a google search and it looks like in Poland he is a living legend called Expierd (funny wordplay on word Expert). If you understand polish check the series http://licorea.pl/bart/blog/2007/01/30/ekspierd/ People also collected book of his funny quotations since 1996 here (in polish) http://xox.pl/~zamsz/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Community council is a representative body - not community leadership (upate2)
Aniello Del Sorbo wrote: You're serious ??? Yes. Sorry if it wasn't clear. What I mean is that it seems Darius has relatively rich history of trolling on Polish internet. Too bad I can't find babelfish equivalent for PL language, here is also some analysis again in polish from 2001 by one of his 'admirers' http://groups.google.com/group/pl.internet.polip/browse_thread/thread/c927092e6b09f6da/24d5ccf55b4ff862 Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Hello Maemo - CFSONID 2008
Robert Schuster wrote: So the answer is no. As long as Maemo's goal is not 'providing a 100% free platform' as well I[0] will not contribute[1] to it There is difference between Nokia and Maemo here. It may not be be goal for Nokia as a company (no matter what is our opinion on this) but it can be goal for Maemo and community around it. And I believe some work is slowly done towards this goal. Both at community side via replacing few closed bits or running alternative distributions, and some work is done on Nokia side too (with glacial speed) so we may have less roadblocks in future. and I expect that with more and more freedom respecting projects/products you will have a hard time finding people who do. Yes. I also hope the future is bright and have no problem switching to something more open with same qualities in future. Today (or maybe at least yesterday? ;-) Maemo is the best choice for me. It makes more sense (to me) to collaborate with them and try to push it towards openness than trying to start yet another tiny 100% open platform from scratch :-) Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N810 discount code frustration
Vivia Nikolaidou wrote: Anyway, here is the story: All this is very unfortunate and it is too late now but you could have done some things better to minimize those issues. I'm not sure about N810 program but with N800 there was a FAQ page http://maemo.org/community/wiki/n800developerdeviceprogram/ (see Nokia shops don't cover my country, do I still have a chance?) and implications were discussed in this list many times. Maybe with future developer device programs (if any) this should be stressed again to prevent or minimize such frustration. Here are the facts: - devices are sold only in some countries - you need to use online store of those countries - you need to use credit card with shipping and billing address from that country So the best way is to have friend from that country who will buy the device for you, use his/her own credit card, gets the device, then preferably also tests the device (and handles possible replacement) and then ships it to you. Unfortunately you can't ship device directly to you and you can't use your own credit card. And most probably you can't easily claim warranty in your country if device arrives broken or gets broken later. This is the reality you either accept or not. The other choice Maemo team had (and I think they really considered it) was to limit the program only for developers from those selected countries to prevent similar unhappy stories. Fortunately they decided against such 'unfair' setup and some developers (including me) are very happy with this :-) The first (770) device program was done differently and maemo team shipped device directly which was of course better for developer outside of those countries but I can perfectly understand this was not easy and most possibly such experiment was possible only in the beginning of such project. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sqlite3 CLI?
[EMAIL PROTECTED] wrote: Which package do I need to install to have the sqlite3 command-line tool available ? There is no such package in SDK repository, you should install sqlite3 but this one is disabled in maemo patch for sqlite3 so you need to rebuild it from source and revert part of sqlite3_3.4.1-1osso3.diff.gz patch which disables it. http://repository.maemo.org/pool/chinook/free/s/sqlite3/ I had same problem some time ago, my build for chinook is here http://fanoush.wz.cz/maemo/sqlite3_3.4.1-1osso3_armel.deb Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sqlite3 CLI?
Marius Gedminas wrote: Do you know the reason for that? No. I also wondered why someone took the time to edit debian files to remove it from the build, it does not look like the most productive thing to do :-) Maybe it saves some trees? Is there a bug filed on bugs.maemo.org for restoring the command-line tool? I did not file any since removing it was intentional and nobody missed it (except me). Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
