Re: Localhost unavailable when wi-fi offline or not connected
Hi, On Wed, 2007-05-02 at 11:11 +0300, Kalle Valo wrote: There is/was dummy IAP support which you could use here: http://maemo.org/maemowiki/DummyIAP But it accidentally went kaput at some stage. Patrik, what's the status with that? It's still kaput and I have no time allocated to fix that currently. It involves some surgery on icd that has to be thoroughly tested before released. BR, Patrik -- Patrik Flykt [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
Hi, ext Matthew Allum wrote: For the use case which is being described here - namely always full screen applications which need exclusive access to the display at a lower resolution Why not do something like switch to another VT and do it directly on the framebuffer ? and then wrap this with something that makes sure you can always safely return to/from X - maybe something managed through systemUI or some such. This is a different approach but could prove simpler in the long run though I havn't thought long and hard about it so there could be some obvious downsides - More a random idea :) Egh, my eyes! Dealing with input in particular could be a pain. I guess that means SDL cant run on a raw framebuffer. It can. The problem is that it's not the only process running. Think what would / should happen if user presses power menu while game has switched to another VT... I think Daniel has also mentioned some (kernel) race conditions in switching VT. I really think using xrandr for this wont buy you much though (in fact you'll probably loose) as you really only want the single topped app to notice the display has shrunk not everything server wide (as randr is intended). That should be a problem only from the performance point of view. And if that's the thing you're concerned about, then switching screen orientation will be a similar problem and Matchbox should anyway be fixed to notify only visible windows of the screen geometry changes. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 Video playback
Siarhei Siamashka wrote: If decoding time for each frame will never exceed 28-29ms (which is a tough limitation, cpu usage is not uniform), video playback without dropping any frames will be possible even with tearsync enabled. Would a double or multiple buffering help with this? Does mplayer use different threads for displaying and decoding and decode frames in advance? ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Toolchain upgrade? (Was: Instructions cache flush on ARM)
Siarhei Siamashka wrote: I'm not going to statically link with glibc, but only with libstdc++ (standard c++ library). There are a few known tricks to make gcc link with libstdc++ statically, but dynamically with all the rest of libraries. One of them is creating a symlink to libstdc++.a in some empty directory and specify this directory with -L option in gcc command line. When gcc will start linking, it will be fooled to link with a static libstdc++ library. But I guess just killing libstdc++.so in scratchbox will do the the job. After that, the compiler theoretically should create binaries which should run with no problems on the device even for c++ applications. I used this trick for scummvm for IT2005. It works as long as your program does not load dynamically (directly or indirectly) some other c++ code compiled with stdc++ too e.g. when using some plugins in your application or other libraries written in C++. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
Hi, Eero Tamminen wrote: Hi, ext Matthew Allum wrote: ...clip... I really think using xrandr for this wont buy you much though (in fact you'll probably loose) as you really only want the single topped app to notice the display has shrunk not everything server wide (as randr is intended). That should be a problem only from the performance point of view. And if that's the thing you're concerned about, then switching screen orientation will be a similar problem and Matchbox should anyway be fixed to notify only visible windows of the screen geometry changes. If we need one fullscreen app, why not to launch a new X-session that uses this lower, pixel-doubled resolution and then run our SDL game there? Other applications would not recognize anything. just my two cents... -Markku- ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Toolchain upgrade? (Was: Instructions cache flush on ARM)
Hi, ext Siarhei Siamashka wrote: Did you also read Intel docs? Unaligned access has some restrictions on x86 as well. Do you have an example of some practical case where hardware unaligned support from ARM11 would work worse than on x86? No. Would be nice if somebody would test it. The compiler should do the job aligning data for performance reasons (as it does on x86 as well). But if you happen to have some unaligned data in memory anyway, just reading it with some minor unavoidable performance penalty will be faster than reading data one byte at a time and combining it into a 32-bit or 16-bit value (instructions timings can be also found in this Technical Reference Manual). Enabling hardware unaligned access support should make explicit pointer conversion hacks that are sometimes used in not very portable C code work just like they do on x86. Which is a good thing in my opinion. Same test could check whether the CPU alignment fixup mode has any performance penalty also for aligned operations... The number of posts asking for help is also nonzero: http://www.internettablettalk.com/forums/showthread.php?t=2668 What!?! People who are porting/re-making m68k games haven't heard of alignment issues? Where the world is going... Like ARM, M68k required things to be aligned and generated buserror/SIGBUS if they weren't. And these are not the only architectures where things should be aligned. If I remember correctly Alpha (first 64-bit machine I tried almost 10 years ago) required also aligning. In addition, I remember having explained about alignment issues to a few people on #maemo channel over all this time, they all came complaining about applications working on x86 but crashing on ARM. So in my opinion this problem really exists, even if it is not so significant. The quality of the developers these days, sigh... ;-) People really should learn to use a compiler, it tells about these issues (signed/unsigned in addition to alignment) when asked. These warnings produce some false positives though, so one doesn't want to keep them on all the time. I'm more concerned about bugs in code being silenty fixed (wrong) by the CPU instead of developer getting notified about the issues (with a crash). - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
Hi, ext Markku Vire wrote: ...clip... I really think using xrandr for this wont buy you much though (in fact you'll probably loose) as you really only want the single topped app to notice the display has shrunk not everything server wide (as randr is intended). That should be a problem only from the performance point of view. And if that's the thing you're concerned about, then switching screen orientation will be a similar problem and Matchbox should anyway be fixed to notify only visible windows of the screen geometry changes. If we need one fullscreen app, why not to launch a new X-session that uses this lower, pixel-doubled resolution and then run our SDL game there? Other applications would not recognize anything. Same problem as using framebuffer directly. How user switches to another application? How to invoke power menu properly etc. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Deleting alarms
If I understand the alarm API http://www.maemo.org/platform/docs/howtos/howto_alarm_interface_bora.html properly, it can be used to specify a D-Bus method to be called at regular intervals. I guess the application/service will be started if necessary. But how can I remove an existing alarm (to replace it with a new alarm with a different interval) if that alarm was set by a previous instance of my application. Should I save the cookie_t ID in gconf in order to use it later? Or, do the alarms only work while my application is already running, and stop working when my applications stops? -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
Hi; On 5/3/07, Eero Tamminen [EMAIL PROTECTED] wrote: I guess that means SDL cant run on a raw framebuffer. It can. The problem is that it's not the only process running. Think what would / should happen if user presses power menu while game has switched to another VT... It would switch back to X VT ? Isnt that what you want ? i.e systemUI or whatever could manage this. I think Daniel has also mentioned some (kernel) race conditions in switching VT. Doh! I really think using xrandr for this wont buy you much though (in fact you'll probably loose) as you really only want the single topped app to notice the display has shrunk not everything server wide (as randr is intended). That should be a problem only from the performance point of view. I t not so much a performance problem - its much more a problem you effectively want to lie all windows but one about what the display resolution actually is. Thats not what randr is for. There will be issues. The screen DPI will change for one of which applications could respond too (font rendering wise) completely outside of MB's control. And if that's the thing you're concerned about, then switching screen orientation will be a similar problem and Matchbox should anyway be fixed to notify only visible windows of the screen geometry changes. Its not matchbox notifying the windows that the display size has changed. -- Matthew ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
Hi; On 5/3/07, Markku Vire [EMAIL PROTECTED] wrote: If we need one fullscreen app, why not to launch a new X-session that uses this lower, pixel-doubled resolution and then run our SDL game there? Other applications would not recognize anything. If the games need everything an xserver provides then this could be another option (if a little more extreme =)) -- Matthew ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Toolchain upgrade? (Was: Instructions cache flush on ARM)
Siarhei Siamashka wrote: Hm. The toolchain might not be built with -pg support. As to using gprof, that produces fairly unreliable results. I'd recommend building Oprofile kernel and latest oprofile user-space tools. Maybe Oprofile is good, but gprof is better than nothing and does not require recompiling kernel. OTOH you don't need to recompile apps with -pg to profile with oprofile. One needs to just recompile the kernel once. Well, I'm worried not about how to workaround ICE but about the overall quality of the compiler. I wonder how many compiler related bugs are lurking in maemo software but are not caught yet? Me too.. Did anybody try installing newer toolchains in scratchbox and use them with maemo SDK? I just don't have much free time for these experiments and don't want to break my installation of scratchbox which works now (more or less acceptable) No reason why it shouldn't work, one just needs to be sure the glibc/libstd++ built is matching enough. I tried the newer codesourcery toolchain (based on gcc 4.1, and it mostly worked, except for apps using certain depreciated syscalls. (i've forgotten already which ones). http://www.scratchbox.org/wiki/ForeignToolchains Enabling unaligned memory support will make life much easier for developers unfamiliar with ARM platform. The number of applications for N800 should grow up, as less newbee developers will be turned away frustrated by the alignment bugs they have never heared about before. Alignment issues exist for other risc processors as well (hppa, alpha, ia64), so most Linux programs to be ported to n800 should already be fixed. Also, who says all maemo products will be arm11 based? arm9 isn't going to disappear overnight, especially it seems xscales will continue to evolve as arm9-based. This is of course just objecting for the sake of it:) I don't have anything against enabling unaligned memory support, so tested patches would be appreciated ;) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
--- Daniel Stone [EMAIL PROTECTED] wrote: I assume your 'xrandr' screenshot is taken on the desktop? RandR doesn't imply a specific scaling algorithm. Yes. I mistakenly assumed that xrandr would imply a point-scaler algorithm. I don't see the conflict between working on new Xomap versions and improving the N800. There is none, but look again at the title of this thread. :) I don't see the point in doing pixel doubling in software. The point is to consider alternatives to improve performance for SDL games on the 770 (and by extension, the 800). It's not about memcpy. I think the _maximum theoretical_ rate of screen updates is 28 fps due to the limited bandwidth between OMAP dispc and Hailstorm. You cannot push pixels any faster than this, even if you try, and even if you optimise SDL to death. Thanks for that info. I estimate my action games need roughly 20-25 FPS at 640x480 and RPGs 8-15 FPS at 800x480, so available bandwidth would be sufficient, correct? I'd like to thank Matthew, Eero, Daniel and Tapani for sharing their ideas on the future of pixel doubling and Xomap here, but given the status of N770 support, we in the community can not reasonably ask or expect Nokia to implement them for IT2006. If this is correct, I respectfully request that discussion about future Xomap releases be forked to another thread and we return here to the question of how to improve SDL game performance on the current OS. To review: - When UQM updates the full 320x240 screen (as in the intro and settings menus) Xsp doubling works as intended. When it updates portions of the screen (main menu, combat, dialogues) doubling is getting disabled. I don't understand why this is happening and apparently nobody else does either. - UQM combat is running at 21-24 FPS in 320x240 mode and at 6-11 FPS in 640x480. Getting 640x480 up to 20+ FPS is all that's needed to make it playable. - Given the stated goal (deliver SDL games to current tablet users) and the known constraints (Xsp problems, no Xomap fixes for IT2006), I see three potential solutions for the community (not Nokia): 1) find out and document how to avoid the Xsp-doubling/damage problems for SDL apps, in general 2) write a SDL putrect equivalent that can use DSP pixel doubling directly, without using Xsp 3) write a fast SDL putrect equivalent direct to framebuffer (cf mplayer) - optional SW scaling There are a number of classic SDL games that are close to playable on the 770. We could dive into each one individually and look for performance gains, but speeding-up scaled SDL surfaces across the board would yield a bigger payoff. I have doubts whether #1 is possible and #2 would require an intrepid coder who can venture into 'here be dragons' DSP-land. I think #3 (basically Siarhei's suggestion) looks like the most general and do-able route to speed up SDL games, since he's already implemented something like this for mplayer. Any thoughts? (besides sell your 6-month old 770) Arnim __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
Eero Tamminen wrote: ext Markku Vire wrote: If we need one fullscreen app, why not to launch a new X-session that uses this lower, pixel-doubled resolution and then run our SDL game there? Other applications would not recognize anything. Same problem as using framebuffer directly. How user switches to another application? How to invoke power menu properly etc. So to sum it up - for this to be workable solution, not hack with various nasty side effects it should: 1. not crash due to pixeldoubling mode left turned on by mistake 2. allow system dialogs and infoprints to overlay active window and have normal density (i.e. 800x480) 3. allow SDL apps to use half resolution(s) easily 4. optionally allow to intermix updates both resolutions at it suits developer (not portable, maemo specific port) 4. needs to work anyway due to 2. and also 3. can be written by using 4. Still this leads me to original suggestion of having pixel doubling to be not persinsten flag but property of rectangle update. If this is not possible to do in X the most sane solution IMO is to hack direct framebuffer access it into SDL to do such updates possibly together with emulating different resolutions in SDL too. Since we have sources there can be community volunteers to do it (including myself). The question is, does it have any chance to be merged to official firmware? Expecting people to update SDL just for your game is not good. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
On 5/3/07, Eero Tamminen [EMAIL PROTECTED] wrote: [...] Same problem as using framebuffer directly. How user switches to another application? How to invoke power menu properly etc. What problem with using framebuffer directly? Everything should be fine, you can get notifications from xserver when your window becomes obscured, so you can stop drawing. I suggest you to try MPlayer on Nokia 770 to check how it interacts with xserver. The worst thing that can happen is some garbage data left on screen on fast applications switching. That can happen because there is no support to synchronize access to framebuffer in a reliable way (application using framebuffer directly may get notification from the xserver about getting inactive too late and overwrite some other application window). Adding support to xserver for proper synchronization with direct framebuffer access applications should be quite possible. It already synchronizes access to framebuffer with DSP (Xsp API for registering DSP area). Almost all the necessary changes will probably have to be added at the same places in xserver which support interaction with DSP. I guess it can't be helped and I will make an example application for using framebuffer directly and some kind of tutorial. Don't know when I will have enough free time to do this though. I'm pretty much confident that direct framebuffer access (also with pixel doubling support) is quite possible for SDL. I don't care much if you believe me or not :) Someone just needs to do the dirty work and implement all this stuff. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
(I have all your other mails queued up to read again and reply to, but I'd like to reply to this one as quickly as possible.) On Thu, May 03, 2007 at 12:39:11PM +0300, ext Siarhei Siamashka wrote: On 5/3/07, Eero Tamminen [EMAIL PROTECTED] wrote: Same problem as using framebuffer directly. How user switches to another application? How to invoke power menu properly etc. What problem with using framebuffer directly? Everything should be fine, you can get notifications from xserver when your window becomes obscured, so you can stop drawing. I suggest you to try MPlayer on Nokia 770 to check how it interacts with xserver. The worst thing that can happen is some garbage data left on screen on fast applications switching. That can happen because there is no support to synchronize access to framebuffer in a reliable way (application using framebuffer directly may get notification from the xserver about getting inactive too late and overwrite some other application window). Behold, the problem. Also bear in mind that the X server is perfectly within its rights to change the framebuffer setup, layout, and dimensions, and you won't have any idea. Adding support to xserver for proper synchronization with direct framebuffer access applications should be quite possible. It already synchronizes access to framebuffer with DSP (Xsp API for registering DSP area). Almost all the necessary changes will probably have to be added at the same places in xserver which support interaction with DSP. This will _never_ be added. I think you're basically microoptimising at this point. If someone can show that our primary performance bottleneck is app - server - framebuffer (and that it's not just caused by naive use of the X libraries, which is generally the case), then sure, we've got something to work with there. But I don't see that this is at all the case. All we're adding is unnecessary complications and layering violations. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Deleting alarms
On tor, 2007-05-03 at 11:12 +0200, ext Murray Cumming wrote: If I understand the alarm API http://www.maemo.org/platform/docs/howtos/howto_alarm_interface_bora.html properly, it can be used to specify a D-Bus method to be called at regular intervals. I guess the application/service will be started if necessary. That's the idea, at least. But how can I remove an existing alarm (to replace it with a new alarm with a different interval) if that alarm was set by a previous instance of my application. Should I save the cookie_t ID in gconf in order to use it later? You can either save the cookie_t ID (this is the preferred solution, since it's guaranteed to be correct), or request a list of all alarms happening in a specific time interval (using alarm_event_query), then iterate the list of cookies (retrieving each alarm_event_t with alarm_event_get) and see if the exec_name or dbus_name matches your application (as mentioned, this is not 100% fail-safe; think of cron-like execution schedulers for instance). Or, do the alarms only work while my application is already running, and stop working when my applications stops? No, alarms keep working even when you quit your application. Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
On Thu, May 03, 2007 at 02:28:04AM -0700, ext Arnim Sauerbier wrote: --- Daniel Stone [EMAIL PROTECTED] wrote: I don't see the conflict between working on new Xomap versions and improving the N800. There is none, but look again at the title of this thread. :) Pretty sure the hacker edition uses the most recent X server anyway, so it should be okay? I don't see the point in doing pixel doubling in software. The point is to consider alternatives to improve performance for SDL games on the 770 (and by extension, the 800). Yes, but if you're doing it _in software_, then surely the performance impact from that would make your lower resolution kind of pointless. It's not about memcpy. I think the _maximum theoretical_ rate of screen updates is 28 fps due to the limited bandwidth between OMAP dispc and Hailstorm. You cannot push pixels any faster than this, even if you try, and even if you optimise SDL to death. Thanks for that info. I estimate my action games need roughly 20-25 FPS at 640x480 and RPGs 8-15 FPS at 800x480, so available bandwidth would be sufficient, correct? Right. You get 28fps at 800x480, assuming you have one frame queued up to push as soon as the last one has hit. I'd like to thank Matthew, Eero, Daniel and Tapani for sharing their ideas on the future of pixel doubling and Xomap here, but given the status of N770 support, we in the community can not reasonably ask or expect Nokia to implement them for IT2006. If this is correct, I respectfully request that discussion about future Xomap releases be forked to another thread and we return here to the question of how to improve SDL game performance on the current OS. If new Xomap doesn't work on the 770, I'd like to know about it. (I don't have time to constantly test it, but I can -- and will -- fix it.) To review: - When UQM updates the full 320x240 screen (as in the intro and settings menus) Xsp doubling works as intended. When it updates portions of the screen (main menu, combat, dialogues) doubling is getting disabled. I don't understand why this is happening and apparently nobody else does either. Presumably this is because it's writing outside the 400x240 area. If you do this on older versions, pixel doubling will get disabled. If you do it using a recent (2007.whatever) version of ITOS2007, you'll just get clipped. - Given the stated goal (deliver SDL games to current tablet users) and the known constraints (Xsp problems, no Xomap fixes for IT2006), I see three potential solutions for the community (not Nokia): 1) find out and document how to avoid the Xsp-doubling/damage problems for SDL apps, in general 2) write a SDL putrect equivalent that can use DSP pixel doubling directly, without using Xsp 3) write a fast SDL putrect equivalent direct to framebuffer (cf mplayer) - optional SW scaling There are a number of classic SDL games that are close to playable on the 770. We could dive into each one individually and look for performance gains, but speeding-up scaled SDL surfaces across the board would yield a bigger payoff. I have doubts whether #1 is possible and #2 would require an intrepid coder who can venture into 'here be dragons' DSP-land. I think #3 (basically Siarhei's suggestion) looks like the most general and do-able route to speed up SDL games, since he's already implemented something like this for mplayer. We don't use the DSP for pixel doubling, it gets done by the graphics hardware (Tornado/hwa742 on 770, Hailstorm/s1d13745 on N800). As I've said before, I think the framebuffer solution is a very poor idea. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
Hi, ext Matthew Allum wrote: I really think using xrandr for this wont buy you much though (in fact you'll probably loose) as you really only want the single topped app to notice the display has shrunk not everything server wide (as randr is intended). That should be a problem only from the performance point of view. I t not so much a performance problem - its much more a problem you effectively want to lie all windows but one about what the display resolution actually is. Thats not what randr is for. There will be issues. The screen DPI will change for one of which applications could respond too (font rendering wise) completely outside of MB's control. Windows that are not visible should not be updated, so there shouldn't be any need for Xft to regenerate the font bitmaps for text output. For banners getting pixelwise smaller text would actually be better as then it's physical size would be right (just not the borders). :-) For system dialogs (which take focus) coming on top of the fullscreen application, the screen size was supposed to be switched back to normal by the WM before it allows it on screen. If the dialog contents are rendered before the dialog is shown, this could be a problem, but doesn't that happen at expose event i.e. hopefully late enough that the screen size is back at normal? If this cannot be guaranteed, then it's better that the screen size would be changed only when the topmost window changes. And if that's the thing you're concerned about, then switching screen orientation will be a similar problem and Matchbox should anyway be fixed to notify only visible windows of the screen geometry changes. Its not matchbox notifying the windows that the display size has changed. Will the DPI change also for applications that don't have any mapped windows on screen? (Did Matchbox unmap the windows when the are backgrounded, or are they just not visible?) I guess this would need some testing... Anybody on the list who would be willing to patch Matchbox and SDL to test this? Or just do a simple test program using XrandR when it switches to fullscreen? I think it should be possible to test how this behaves just with Xephyr. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
Hi; On 5/3/07, Eero Tamminen [EMAIL PROTECTED] wrote: Hi, ext Matthew Allum wrote: I really think using xrandr for this wont buy you much though (in fact you'll probably loose) as you really only want the single topped app to notice the display has shrunk not everything server wide (as randr is intended). That should be a problem only from the performance point of view. I t not so much a performance problem - its much more a problem you effectively want to lie all windows but one about what the display resolution actually is. Thats not what randr is for. There will be issues. The screen DPI will change for one of which applications could respond too (font rendering wise) completely outside of MB's control. Windows that are not visible should not be updated, so there shouldn't be any need for Xft to regenerate the font bitmaps for text output. For banners getting pixelwise smaller text would actually be better as then it's physical size would be right (just not the borders). :-) For system dialogs (which take focus) coming on top of the fullscreen application, the screen size was supposed to be switched back to normal by the WM before it allows it on screen. If the dialog contents are rendered before the dialog is shown, this could be a problem, but doesn't that happen at expose event i.e. hopefully late enough that the screen size is back at normal? If this cannot be guaranteed, then it's better that the screen size would be changed only when the topmost window changes. Note, this was just one potential problem - and with any problem theres going to be somekind of workaround. Its just special casing everything to 'subvert' randr is going to need alot and therefor I dont see what you gain from using randr to do it ? And if that's the thing you're concerned about, then switching screen orientation will be a similar problem and Matchbox should anyway be fixed to notify only visible windows of the screen geometry changes. Its not matchbox notifying the windows that the display size has changed. Will the DPI change also for applications that don't have any mapped windows on screen? No idea I guess this would be toolkit dependant. (Did Matchbox unmap the windows when the are backgrounded, or are they just not visible?) MB does not unmap windows unless they are minimised. It would be trivial to make it do so however. Any comments on my 'simple' non vt switching solution without randr ? It would be fairly easy to simulate in Xephyr if thats a worry btw. -- Matthew ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Localhost unavailable when wi-fi offline or not connected
Hi, On Wed, 2007-05-02 at 07:10 -0500, ext David Hagood wrote: Outbound packet detected with interface down This has one additional problem: The packets sent to the dummy interface will vanish and not be re-routed to the new interface once it's up. If the packets were meant for DNS, the application most likely would end up with a host not found while the connection would still be connecting in the background. If the device should not have DNS packets triggering connection creation there are problems as all applications do their name resolution before they actually connect, so nobody would be able to connect. In order to fix this, the device could of course implement its own DNS resolver, which would signal with the connectivity subsystem to get the interface up. Usually any delay in name resolution keeps the application in a frozen state, as name resolution is expected to be a fairly quick operation. If we don't mind name resolution triggering connection creation or a host not found error every now and then then this is not a showstopper. More than $TIME has elapsed without an outbound packet. That we basically have with the idle timer settings and iptables. Signals the kernel to retry the packet Hmm, is this possible with recent kernels? What about those packets to DNS and elsewhere whose state in the application has already timed out? Regards, PAtrik -- Patrik Flykt [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Deleting alarms
On Thu, May 03, 2007 at 12:50:37PM +0300, David Weinehall wrote: No, alarms keep working even when you quit your application. Except when they don't: https://maemo.org/bugzilla/show_bug.cgi?id=1112 Marius Gedminas -- ... there is always a well-known solution to every human problem -- neat, plausible, and wrong. -- H. L. Mencken (1880-1956), Prejudices signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Research on Maemo
Hi everybody, I'm writing a survey about the state of the art on free software related research. It's part of my PhD and I'm interested on involve Maemo on it.I would like to know if there is any research ( published articles on conferences and publications ) that talk about : * Maemo architecture ( Embedded architectures using OSS ) * FLOSS ( Free as Libre Open Source Software ) relation with Maemo Project Management ( related projects vs maemo , comunity vs maemo,... ) * Open Source Development Model relation with Maemo development model * Nokia policy related to Free Software Also if there is any group on any university that work on any of this subjects would be fine to know about them. Thanks a lot Ramon ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
Hi, ext Matthew Allum wrote: For system dialogs (which take focus) coming on top of the fullscreen application, the screen size was supposed to be switched back to normal by the WM before it allows it on screen. If the dialog contents are rendered before the dialog is shown, this could be a problem, but doesn't that happen at expose event i.e. hopefully late enough that the screen size is back at normal? If this cannot be guaranteed, then it's better that the screen size would be changed only when the topmost window changes. Note, this was just one potential problem - and with any problem theres going to be somekind of workaround. Its just special casing everything to 'subvert' randr is going to need alot and therefor I dont see what you gain from using randr to do it ? Daniel wants to get rid of non-standard Xsp. :-) And if that's the thing you're concerned about, then switching screen orientation will be a similar problem and Matchbox should anyway be fixed to notify only visible windows of the screen geometry changes. Its not matchbox notifying the windows that the display size has changed. Will the DPI change also for applications that don't have any mapped windows on screen? No idea I guess this would be toolkit dependant. (Did Matchbox unmap the windows when the are backgrounded, or are they just not visible?) MB does not unmap windows unless they are minimised. It would be trivial to make it do so however. Any comments on my 'simple' non vt switching solution without randr ? Using Xsp? Using TN instead of MB (why?)? It would be fairly easy to simulate in Xephyr if thats a worry btw. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
On Thu, 3 May 2007 15:12:43 +0100, Matthew Allum wrote: You are essentially changing the server viewport area here *not* the display size. But isn't this exactly one of the features provided by the new RandR 1.2 stuff? -Carl pgpGTUcbNAuU5.pgp Description: PGP signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Problem installing bash / OS2007
Hello, i tried to install the bash on my N800/OS 2007 version 3.2007.10-7. Using the Program Manager causes a conflict - so i tried it using apt-get. But apt tries to remove dpkg and busybox! Does someone has an explanation for this behaviour? In principle i want to install the SDK, but the install script for the scratchbox uses bash. So this is the reason why i want to use bash. I tried also to install zsh before, but i got the ususal bug, that zsh is not installable and not removable any more. After this attempt i flashed the OS again. === Nokia-N800-10:~# apt-get install bash Reading package lists... Done Building dependency tree... Done The following extra packages will be installed: libblkid1 libuuid1 mount Suggested packages: bash-doc The following packages will be REMOVED: apt-https bluez-utils busybox chavo codelockui dnsmasq docpurge dpkg hildon-control-panel hildon-control-panel-navigatorapplet hildon-control-panel-personalisation hildon-im-hwr-teach hildon-initscripts ke-recv libconbtui0 libosso-certman1 maemo-af-desktop maemo-launcher maemo-select-menu-location maemoblocks mediaplayer-ui multimedia-applications netbase nokia-repository operator-wizard osso-accounts-obr osso-addressbook osso-af osso-af-base osso-af-cpa osso-af-hildon-input-method osso-af-hildon-input-method-product osso-af-startup osso-af-utils osso-ai osso-app-killer osso-applet-accounts osso-applet-certman osso-applet-datetime osso-applet-device osso-applet-devicelock osso-applet-display osso-applet-hwkeyboard osso-applet-languageregional osso-applet-memory osso-applet-screencalibration osso-applet-sound osso-applet-textinput osso-application-installer osso-backup osso-bluez-compat osso-browser osso-browser-plugin osso-browser-ui osso-calculator osso-calculator-ui osso-chat-ui osso-chess-ui osso-clock-ui osso-connectivity osso-connectivity-ui osso-connectivity-ui-btsettings osso-connectivity-ui-conndlgs osso-connectivity-ui-connmgr osso-connectivity-ui-gwsettings osso-connectivity-ui-gwwizard osso-connectivity-ui-statusbar osso-core osso-core-busybox osso-core-config osso-cow osso-dsm-ui osso-email osso-email-ui osso-filemanager osso-filemanager-ui osso-games-startup osso-global-search osso-help osso-help-ui osso-ic osso-lmarbles osso-mahjong osso-multimedia osso-notes osso-pdf-viewer osso-rss-feed-reader osso-rss-feed-reader-applet osso-rss-feed-reader-list osso-sketch osso-startup-greeting osso-startup-wizard osso-statusbar-alarm osso-systemui osso-systemui-actingdead osso-systemui-alarm osso-systemui-devlock osso-systemui-modechange osso-systemui-powerkeymenu osso-systemui-splashscreen osso-systemui-tklock ppp pre-installed-documentation pre-installed-images pre-installed-sounds pre-installed-videos ssh sysvinit vpnc-gui The following NEW packages will be installed: bash libblkid1 libuuid1 mount WARNING: The following essential packages will be removed. This should NOT be done unless you know exactly what you are doing! dpkg busybox (due to dpkg) sysvinit 0 upgraded, 4 newly installed, 109 to remove and 0 not upgraded. Need to get 846kB of archives. After unpacking 49,4MB disk space will be freed. You are about to do something potentially harmful. To continue type in the phrase 'Yes, do as I say!' ?] Abort. -- Best regards, Frank Schreiber ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Research on Maemo
Hi Ramon, you might want to contact Martin Michlmayr [EMAIL PROTECTED] from Cambridge. He is an active Debian developer and is writting his PhD thesis on a similar topic (though he probably did not look at maemo). Regards, Rainer Am Donnerstag, 3. Mai 2007 20:00 schrieb Ramon Navarro Bosch: Hi everybody, I'm writing a survey about the state of the art on free software related research. It's part of my PhD and I'm interested on involve Maemo on it.I would like to know if there is any research ( published articles on conferences and publications ) that talk about : * Maemo architecture ( Embedded architectures using OSS ) * FLOSS ( Free as Libre Open Source Software ) relation with Maemo Project Management ( related projects vs maemo , comunity vs maemo,... ) * Open Source Development Model relation with Maemo development model * Nokia policy related to Free Software Also if there is any group on any university that work on any of this subjects would be fine to know about them. Thanks a lot Ramon ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers -- Rainer Dorsch Lärchenstr. 6 D-72135 Dettenhausen 07032-359190 jabber: [EMAIL PROTECTED] GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E Full GPG key: http://pgp.mit.edu/ ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: format string vuln in the wifi applet
For the record, ESSIDs are not strings! For example, \0\0 is a valid (2- byte) ESSID. On a slightly related note, can anyone point me in the right direction for the implementation of the EAP-TTLS MSchap authentification? I was thinking about extending that to WEP+EAP TTLS PAP (university wireless), but I didn't find the eap bits. wlancond (in osso-wlan) only sets up the connection but does not do the authentification? Volker ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Osso-help in python app?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all. There exists some possibility of running osso-help from a python app? Might it be done by means of dbus-send...? I have looked a bit the osso-help code, but my small knowledges of C did not allow me to obtain anything clear. I might do a help dialog inside the app but I prefer doing it by means of osso-help. Already I take advantage of the email to ask to the pymaemo people, when you have thought to publish the first version of python-conic? I see enough movement in the SVN these days. In this moment is it stable? Thanks for your work. Thanks in advance. Best Regards. - -- Daniel Martín Yerga dyerga(arroba)gmail.com GNU/Linux user #372827 http://yerga.freehostia.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGOhyscnvB1T3xmfMRAms1AKCJzz/xruq4L0VSHTQ19no2gYEBDwCdESJy Bj9EeZyuuG3wRti9U0onOiE= =8fIE -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
On Thu, 3 May 2007 18:08:36 +0100, Matthew Allum wrote: On 5/3/07, Carl Worth [EMAIL PROTECTED] wrote: But isn't this exactly one of the features provided by the new RandR 1.2 stuff? Can it - any more details ? Would seem a really nice fit if so. Here's a link to the latest protocol specification [*]: http://gitweb.freedesktop.org/?p=xorg/proto/randrproto.git;a=blob_plain;h=HEAD:randrproto.txt Here's a short excerpt that talks about the new CRTC notion in 1.2 that's independent and configured separately from the screen: To extend RandR for this model, we separate out the output, CRTC and screen configuration information and permit them to be configured separately. For compatibility with the 1.1 version of the protocol, we make the 1.1 requests simultaneously affect both the screen and the (presumably sole) CRTC and output. The set of available outputs are presented with UTF-8 encoded names and may be connected to CRTCs as permitted by the underlying hardware. CRTC configuration is now done with full mode information instead of just size and refresh rate, and these modes have names. These names also use UTF-8 encoding. New modes may also be added by the user. Additional requests and events are provided for this new functionality. ┌┬──┐ ┏━━━┳───┐ ╔╗ ╔╗ ┃ 1 ┃ │ ║ A║ ║ B║ ┃ ┏━━━╋━━━┫ ║║ ║║ ┣━━━╋━━━┛ ┃ ╚╝ ╚╝ │ ┃ 2 ┃─┐ │ ┃ ┃╔═══╗ │ ┃ ┃║ ║ │ ┗━━━┫║C ║ └───┘║ ║ ┌──┐ ┏┓ ╔══╗ ║ ║ │screen│ ┃CRTC┃ ║output║ ╚═══╝ └──┘ ┗┛ ╚══╝ In this picture, the screen is covered (incompletely) by two CRTCs. CRTC1 is connected to two outputs, A and B. CRTC2 is connected to output C. Outputs A and B will present exactly the same region of the screen using the same mode line. Output C will present a different (larger) region of the screen using a different mode line. So to me that seems plenty flexible to do what's needed. The X server could advertise two CRTCs: one covering the entire screen, and one covering only half with pixel-doubling, and client-initiated events could control which CRTC is connected to the output (obviously only one in this device) at any given time. Daniel, am I on the right track with this? -Carl [*] The gitweb process is spewing out the wrong character encoding, so if you view this in a web browser, you'll need to manually change it to UTF-8 instead of ISO-8859-1 to view it properly, (View-Character Encoding-Unicode in firefox-ish browsers for example). pgp7UuYILNSET.pgp Description: PGP signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: Research on Maemo
Hi Ramon, you might want to contact Martin Michlmayr [EMAIL PROTECTED] from Cambridge. He is an active Debian developer and is writting his PhD thesis on a similar topic (though he probably did not look at maemo). Indeed. Martin has completed his thesis already. It is available here: http://www.cyrius.com/publications/michlmayr-phd.html It is very good work by the way. He only mentions Maemo passing by though. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Research on Maemo
Thanks for the information, I'm in touch with him and I knew about his disertion publication. He focused on release plan on projects, an is a erally interesting reading. What I'm writing is a survey about research on free software. Ramon En/na [EMAIL PROTECTED] ha escrit: Hi Ramon, you might want to contact Martin Michlmayr [EMAIL PROTECTED] from Cambridge. He is an active Debian developer and is writting his PhD thesis on a similar topic (though he probably did not look at maemo). Indeed. Martin has completed his thesis already. It is available here: http://www.cyrius.com/publications/michlmayr-phd.html It is very good work by the way. He only mentions Maemo passing by though. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
maemo.org maintenance break today (2007-05-04)
Hello, We are in the final phase of the website migration. It means we will switch over from the old maemo.org server to the shiny, new Midgard powered site today. This switch will affect all maemo.org services: bugzilla, mailing lists, wiki, planet, lxr, viewcvs... We try to keep the services online, but there might be some breaks. As some of you have noticed the wiki is already in read-only mode. Wiki editors have to wait till the new site is online. Anyway the goal is to launch the site today. Please bear with us if you experience problems at maemo.org. It will not take long, I hope. Cheers, ferenc ps for the impatient: Sneak peek of the renewed bugzilla UI: https://test.maemo.org/bugzilla. NOTE! This is just a preview. The database will be overwritten, so don't bother filing bugs here, please. ___ maemo-announce mailing list [EMAIL PROTECTED] https://maemo.org/mailman/listinfo/maemo-announce ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
