Re: N800 Video playback
On Tuesday 01 May 2007 20:49, Siarhei Siamashka wrote: Looks like I have to reply to myself. On Tuesday 01 May 2007 17:49, Kalle Vahlman wrote: Applied and build without problems for me. Thanks a lot for building the package and putting it for download, everything seems to be fine, but more details will follow below. [snip] Anyway, the new xserver package works really good. If we do some tests with the standard Nokia_N800.avi video clip, we get the following results with the patched xserver: # mplayer -benchmark -quiet -noaspect Nokia_N800.avi BENCHMARKs: VC: 29,764s VO: 7,666s A: 0,468s Sys: 64,635s = 102,534s BENCHMARK%: VC: 29,0287% VO: 7,4767% A: 0,4565% Sys: 63,0381% = 100,% BENCHMARKn: disp: 2504 (24,42 fps) drop: 0 (0%) total: 2504 (24,42 fps) # mplayer -benchmark -quiet -noaspect -dr -nomenu Nokia_N800.avi BENCHMARKs: VC: 30,266s VO: 5,490s A: 0,467s Sys: 66,286s = 102,509s BENCHMARK%: VC: 29,5255% VO: 5,3554% A: 0,4560% Sys: 64,6631% = 100,% BENCHMARKn: disp: 2501 (24,40 fps) drop: 0 (0%) total: 2501 (24,40 fps) Results with unpatched xserver and some more explanations can be found in [3]. Yes, now N800 is faster than Nokia 770 for video output performance at last :) Well, still not everything is so good until the following bug gets fixed: https://maemo.org/bugzilla/show_bug.cgi?id=1281 The patch for optimized Xv performance will not help to watch widescreen video which triggers this tearing bug. If you see tearing on the screen, you should know that the YUV420 color format conversion optimization patch does not get used at all and xserver most likely uses a slow nonoptimized YUV422 fallback code with software scaling. Fixing this bug is critical for video playback performance. I hope it will be solved in the next version of N800 firmware too. But it we get some patch to solve this problem for testing earlir, that would be nice too. Video output overhead on N800 is really at least halved. Of course, video output takes only some fraction of time in video player. So overall performance improvement for Nokia_N800.avi playback is approximately 20% but not 250%-300% which can be observed for 'omapCopyPlanarDataYUV420' function alone. Before anybody noticed, correcting myself :) This 'omapCopyPlanarDataYUV420' has 2.5x-3x improvement which is equal to 150%-200% in percents. Elementary arithmetics is tough when you are tired ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
On Monday 30 April 2007 12:26, Frantisek Dufka wrote: Daniel Stone wrote: Specifying that pixels must be exactly _doubled_ is a hack around both the performance issues and a lack of resolution independence. Apparently an important one, if you happen to like SDL games, but a hack nonetheless. Yes limiting ourselves to doubling is bad. Why not to add custom ratio if N800 can do that. This all leads to request to have some more advanced gaming API. Sadly this is probably not what internet tablets are currently designed for. Gamers are big target group and this device is meant for entertainment so maybe extending target audience to gamers in not that bad idea. Gaming devices are moving online too so this is direct competition. Why to buy internet tablet if better Sony or Nintendo device in future will do this too plus gaming. Unfortunately gaming business has complicated rules similar in complexity to devices with GSM radio. BTW are internet tablets in same Nokia multimedia division as N-Gage? Well, SDL is to some extent this advanced gaming API, its current implementation for Nokia 770/N800 is just poor. As for pixel doubling, a practical solution would be just to support 400x240 fullscreen resolution in SDL so that no extra hack would be required when porting each game or emulator in particular. N800 hardware probably makes it possible to set any resolution up to 800x480, with all this available using standard SDL API. Having support for both pixel doubled and normal graphics in the same game may be useful, but it will require extra efforts when porting games, while low resolution may already work out of the box without doing any tweaks to the sources. Let's try the simple solution first. The very first step would be to take Nokia 770 xserver and SDL sources and tweak them until setting 400x240 fullscreen resolution works transparently for any SDL applications. Anybody up to this task? Also it would be a good idea to benchmark SDL, identify maemo or ARM architecture related bottlenecks and try to fix them. Many older generation games worked perfectly on hardware way slower than Nokia 770. So Nokia 770 may be a good platform for mobile gaming if properly optimized (though I'm not sure about realtime games because of unsuitable controls). I could probably do these optimizations myself, but have quite a limited amount of free time available for free software development. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 Video playback
Kalle Vahlman wrote: I put the deb up at: http://iki.fi/zuh/xserver-xomap_1.1.99.3-0.zuh2_armel.deb until I get it to the repository. This version also has the composite extension enabled, but AFAIK it does not depend on the libs or change server behaviour if composite is not specifically used. The server *should* be compiled with '-mcpu=arm1136j-s -mfpu=vfp -mfloat-abi=softfp -O2', but as I had troubles with the SBOX_EXTRA_COMPILER_ARGS env var being honored some time ago I'm not guaranteeing it at the moment ;) I also succeeded in making the deb: http://fanoush.wz.cz/maemo/xserver-xomap_1.1.99.3-0osso31_armel.deb This one is compiled as thumb (except the ASM code) and no special CPU flags so it can be verified if there is any slowdown. Thumb mode saves approx. 300kb of executable size. It seems to be used by default in firmware images. Kalle, did it link properly for you? With the patch the final Xomap link did not add the ASM code, I had to do it by hand. I didn't find proper place in Makefile for it to be added to libomap.a, the place patched by Siarhei was ignored by the build process for me. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: a problem with nokia N800 - reboot evety 6 seconds
Hi, ext nati dobkin wrote: hi, thanks for replaying I will try to explain what is happening. when i start the device it shutdown after 6 secs, if i connect it to a charger then it starts a rstart loop and restart every 6 secs. I cant set the RD mode because the device is not stay on more the 6 secs and. if i connect it to the conputer then the conputer is not recognizing it becuase the device just shuting down. Is there another way to set the RD mode or flash the device? You're not doing this properly (the reboot happens after the bootloader has finished which would have taken care of the flashing / RD flag setting). Connect the USB cable, start flasher so that it waits for the device, only then start the device. Or if you want to start the device before the flasher program (while usb cable is connected), keep Home key pressed so that the device bootloader waits for the flasher program. Please see the instructions on the Maemo site. If you've run your battery empty, you need to charge it somewhere else (e.g. in some N-series phone) before trying flashing. - Eero ___ 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
ext Mike Cowlishaw [EMAIL PROTECTED] writes: While trying to test this on an aeroplane at the weekend -- with Wi-Fi offline, of course -- the browser would not connect to the server. I've since experimented further and find a similar (or the same) problem occurs online if no Wi-Fi connection is active. This is a showstopper for my application as it means I cannot easily view my data unless online and connected -- is there a fix/workaround? 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? -- Kalle Valo ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 Video playback
On Wed, May 02, 2007 at 09:16:01AM +0300, ext Siarhei Siamashka wrote: On Tuesday 01 May 2007 20:49, Siarhei Siamashka wrote: Results with unpatched xserver and some more explanations can be found in [3]. Yes, now N800 is faster than Nokia 770 for video output performance at last :) Well, still not everything is so good until the following bug gets fixed: https://maemo.org/bugzilla/show_bug.cgi?id=1281 The patch for optimized Xv performance will not help to watch widescreen video which triggers this tearing bug. If you see tearing on the screen, you should know that the YUV420 color format conversion optimization patch does not get used at all and xserver most likely uses a slow nonoptimized YUV422 fallback code with software scaling. Indeed. And the reason the code is there is because Hailstorm can only downscale at fixed ratios (half and one-quarter), and even then, it locked up when we tried. Similarly, the display controller's downscaling didn't work, either. So we can optimise the fallback path, but you'll still be screwed by sending 16bpp (instead of 12bpp) through RFBI. Fixing this bug is critical for video playback performance. I hope it will be solved in the next version of N800 firmware too. But it we get some patch to solve this problem for testing earlir, that would be nice too. The only patch is optimising that function, really. Even if we did work out a way to make Hailstorm happy, you can still only scale at those exact multiples, which doesn't make it a viable general solution. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 Video playback
On Tue, May 01, 2007 at 08:49:20PM +0300, ext Siarhei Siamashka wrote: On Tuesday 01 May 2007 17:49, Kalle Vahlman wrote: For testing, I fabricated some video with gstreamer: which resulted in [EMAIL PROTECTED] and [EMAIL PROTECTED] videos. For some reason 320x240 and 352x288 refused to play with: X11 error: BadValue (integer parameter out of range for operation) MPlayer interrupted by signal 6 in module: flip_page while gstreamer did play them just fine. Also the Nokia_N800.avi and NokiaN93.avi died in the same way. This X11 error on video playback start and also sometimes on switching fullscreen/windowed mode is a known problem [1] reported in this mailing list. If MPlayer dies on start, usually trying to start it again succeeds. So these 320x240 and 352x288 videos could be played as well if you were a bit more persistent :) Resizing is a bit tricky. Most video hardware lets you use the hardware to clip, so if you move it beyond the edge of the screen, it just happily ignores anything beyond the hardware's bounds. Unfortunately for us, attempting to move a video surface off-screen (even by just a few pixels) triggers a hardware lockup. Given that we can't display the frame at all, we send BadValue (there are a couple of other conditions where this is possible, but this is the main one). I don't see the point in returning Success when no video is drawn at all. So, I guess you could hack mplayer's error handler to just ignore BadValues from Xv(Shm)PutImage, unless you get more than five or ten in a row, say. As Daniel replied in one of the followup messages, it is most likely some race condition. The question is which code is a suspect. Is it MPlayer Xv video output code that has been around for ages and worked fine on different systems or relatively new Xv extension code from N800 xserver? In addition, a previous revision of N800 firmware had a serious bug [2] related to video playback. It should be noted, that MPlayer needed only about 1 minute to freeze on the initial N800 firmware. So the problem could be identified much more easily if MPlayer was included in the standard set of tests done by Nokia QA staff before each new IT OS release. Surely, Nokia is only interested in a properly working xvimagesink for the software included in IT OS by default. But testing with more client applications can improve overall xserver quality. Bear in mind that, as you've hinted at, the only part of the Xv code which is custom is the _output_ code. We're using the standard X server implementation (as used by tens of millions of people) for the protocol decode and standard semantics, the standard KDrive layer for extended stuff (as used by god-knows-how-many embedded and consumer devices), and then the only part we have to play is taking frames and putting them on the screen. Due to some restrictions (as above), we have to deliberately error out on some operations. But errors like that tend to say 'you've hit a hardware restriction, I can't do this', rather than 'you hit one of the many random return BadValues we put in this weird code just to confuse people'. Also, bear in mind that a lot of the initial instability was due to the DSP. The video was actually rather stable when you played without sound, although now the situation is somewhat reversed with the DSP being pretty steady now, and the new YUV420 code having complicated semsnatics. I have also submitted this patch to maemo bugzilla, hopefully it (or its modification) can get included into the next version of N800 firmware: https://maemo.org/bugzilla/show_bug.cgi?id=1278 I'll merge it with some changes. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 Video playback
On Tue, May 01, 2007 at 11:51:50AM +0300, ext Siarhei Siamashka wrote: On Monday 30 April 2007 17:49, Daniel Stone wrote: Indeed. Unfortunately this is slightly misleading in that it only shows the raw write speed. RFBI can't deal with the sorts of speeds that your hyper-optimised version is pumping out, e.g. So it's mainly just about cutting the latency into the critical path to low enough that it makes no difference. The 'framebuffer' is just the ordinary system memory, converting color format and copying data to framebuffer will be done with the same performance as simulated in this test. RFBI performance is only critical for asynchronous DMA data transfer to LCD controller which does not introduce any overhead and is performed at the same time as ARM core is doing some other work (decoding the next frame). RFBI performance matters only if data transfer to LCD is still not complete at the time when the next frame is already decoded and is ready to be displayed. When playing video, ARM core and LCD controller are almost always working at the same time performing different tasks in parallel. I think I had already explained these details in [1] Right. My point is that the numbers you're showing -- while very good, don't get me wrong -- won't necessarily have a huge direct impact on video playback. Particularly if you want to avoid tearing. So now the results of the tests are consistent - when doing video output, most of ARM core cycles are spent in this 'omapCopyPlanarDataYUV420' function. Well, either that, or just waiting for RFBI transfers to complete. Optimizing it using 'yv12_to_yuv420_line_armv6' will definitely provide a huge effect, video output overhead when using Xv will be at least halved providing more cpu resources for video decoding. Yes, this is one good aspect. I don't have any tips, per se. Once I get it all integrated it'll be in git, but for now, the only public source is the packages. OK, thanks. It may take some time though. I'm still using old scratchbox with mistral SDK here (did not have enough free time to upgrade yet). Until I clean up my scratchbox mess, I can only provide some patch without testing, if anybody courageous can try to build it :) I'm still using Scratchbox 0.9.8.5 for day-to-day stuff ... Well, anyway, everything worked perfectly and I could play 640x480 video on N800 with the following statistics: VIDEO: [DIVX] 640x480 12bpp 23.976 fps 886.7 kbps (108.2 kbyte/s) ... BENCHMARKs: VC: 87,757s VO: 8,712s A: 1,314s Sys: 3,835s = 101,618s BENCHMARK%: VC: 86,3592% VO: 8,5736% A: 1,2932% Sys: 3,7740% = 100,% BENCHMARKn: disp: 2044 (20,11 fps) drop: 355 (14%) total: 2399 (23,61 fps) As you see, mplayer took 8.712 seconds to display 2044 VGA resolution frames. If we do the necessary calculations, that's 72 millions pixels per second, quite close to 'yv12_to_yuv420_line_armv6' capabilities limit, so this function is the only major contributor to video output time. Video output took much less time than decoding, so it proves that video output overhead can be reduced to minimum (in this test tearsync was not used though). I'd be curious to see the results from this with tearsync _enabled_? i.e., after your OMAPFB_UPDATE_WIDNOW call, issue an OMAPFB_SYNC_GFX ioctl before you start writing to memory again. This is basically the limiter for us at this stage. When tearsync comes into action, everything gets a bit more complicated. I'm still investigating its impact on video playback performance. 'Not good'. :) Thanks again for your work. Cheers, Daniel signature.asc Description: Digital signature ___ 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
On Wed, 2007-05-02 at 11:11 +0300, Kalle Valo wrote: ext Mike Cowlishaw [EMAIL PROTECTED] writes: While trying to test this on an aeroplane at the weekend -- with Wi-Fi offline, of course -- the browser would not connect to the server. I've since experimented further and find a similar (or the same) problem occurs online if no Wi-Fi connection is active. This is a showstopper for my application as it means I cannot easily view my data unless online and connected -- is there a fix/workaround? The current method Maemo uses to detect an application wanting to access the Internet (by using ld.so tricks to hook into the socket() call) seems kind of kludgy to me - why not use the same sort of trick that PPP uses, where a network interface always exists and is tied to the default route, and when a packet is delivered to that interface for routing THEN bring up the appropriate connections. It would take modifications to the kernel - ideally some sort of DBUS message when a packet needs to be routed - but this would remove the need to hook into applications, and allow ANY app to generate a request for connection. ___ 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
On Wed, 2007-05-02 at 14:48 +0300, Kalle Valo wrote: It would take modifications to the kernel - ideally some sort of DBUS message when a packet needs to be routed - but this would remove the need to hook into applications, and allow ANY app to generate a request for connection. Sounds a bit complicated to do this in kernel. How would the application notify that it doesn't need the connection anymore? You don't do it ALL in the kernel, hence my statement about DBUS. All the kernel needs to do is provide DBUS messages for: Outbound packet detected with interface down More than $TIME has elapsed without an outbound packet. You could probably plug into iptables for this - just have an iptables plugin for generating a DBUS message on a matching packet. This has the advantage of being a nice general tool, which can be used for other things (e.g. notification of the firewall blocking a packet) as well. You then have an application watching for that event, and bringing up the connection dialog when needed. Once the connection is established, the application then: Signals the kernel to retry the packet Disables the iptables rule if needed. Watches the packet count on the interface to determine activity. When the packet count does not increase for some period of time, re-instate the iptables rule and down the interface. Of course, if the user forces the interface up directly, then all that becomes moot - you leave the interface up until it fails, or until the user tells you otherwise. Sounds a bit complicated to do this in kernel. How would the application notify that it doesn't need the connection anymore? The whole problem here is that the application *cannot* make the decision about whether the connection is needed, as it simply does not have the information needed. The application may know it wants to talk to a server, but the application may not know if that server is local to the device or remote, and requiring a connection - the browser being a perfect example of this. The browser would have to evaluate every host's address to determine routability - but that in and of itself may or may not require bringing up the interface to do a DNS query, and there is no way for the browser to know that until it does the query. And how can the application decide it does not need the connection? Again, to pick on the poor browser - how does the browser know that it is done loading the page? What if there is a META refresh on the page? What if there is AJAX running? All the application can say is that *at this moment* it doesn't need a connection. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Documenting maemo pearls (was Re: N800 Video playback)
On 5/2/07, Quim Gil [EMAIL PROTECTED] wrote: On Tue, 2007-05-01 at 03:29 -0300, ext Gustavo Sverzut Barbieri wrote: Daniel, Siarhei, Eero: I always find your mails to provide great deal of tech information about N800. What a coincidence, me too. ;) However we do not have a central place with these information, it would be great if you guys setup a wiki page with tech details about drivers, optimizations and weakness of current implementations so others could base work on. Indeed. But knowing about the day to day of these busy guys I kind of understand why things they write instantly in an email can't be easily reproduced by themselves in a more formal way. I know, and problem is that we're not always sure of some things, some effects are collateral, some are expected... that wastes our time and when you're finished, often you're so tired you won't document it, just archive the excerpt you want, without any context... you'll know it when you need. But we do want to have all these pearls available in a structured way in maemo.org. Easing web publishing is a step, partially covered now by the Midgard CMS integration. Providing an appropriate content structure is a next step (I'm responsible of). Having that doc manager in place will definitely help, as well, as making sure that every relevant component in our architecture is officially covered by someone of the team (still working on this). Until then we will keep getting busy developers really sensitive to openness and dialog, finding some spare time to answer questions and fill indirectly the gaps in our documentation. Quim, while formal documents as those maemo.org provides are cool, it consumes a lot of resources... doing simple but correct/consistent wiki is good enough. Maybe we could setup a techday that we'd meet on IRC and document some topics on Wiki. It would be great to get some people with deep knowledge on hw issues, like Daniel, Siarhei and Eero... I could help with writing and organization, as I never dig on hw that much (but I'll need to do so really soon). ... Said that, there is nothing stopping anyone from collecting these pearls in the maemo.org wiki. ;) Sure -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Documenting maemo pearls (was Re: N800 Video playback)
Hi, On Wed, May 02, 2007 at 10:05:13AM -0300, ext Gustavo Sverzut Barbieri wrote: On 5/2/07, Quim Gil [EMAIL PROTECTED] wrote: On Tue, 2007-05-01 at 03:29 -0300, ext Gustavo Sverzut Barbieri wrote: Daniel, Siarhei, Eero: I always find your mails to provide great deal of tech information about N800. What a coincidence, me too. ;) However we do not have a central place with these information, it would be great if you guys setup a wiki page with tech details about drivers, optimizations and weakness of current implementations so others could base work on. Indeed. But knowing about the day to day of these busy guys I kind of understand why things they write instantly in an email can't be easily reproduced by themselves in a more formal way. I know, and problem is that we're not always sure of some things, some effects are collateral, some are expected... that wastes our time and when you're finished, often you're so tired you won't document it, just archive the excerpt you want, without any context... you'll know it when you need. If there's anything you want to know directly, just ask on the list. I tend to deal with email when I'm not actively coding/building/etc, which is how I justify it. A wiki would require me to sit down for a while and really think about stuff, and I don't really have huge blocks of time available to me. But yeah, always happy to answer direct questions. But we do want to have all these pearls available in a structured way in maemo.org. Easing web publishing is a step, partially covered now by the Midgard CMS integration. Providing an appropriate content structure is a next step (I'm responsible of). Having that doc manager in place will definitely help, as well, as making sure that every relevant component in our architecture is officially covered by someone of the team (still working on this). Until then we will keep getting busy developers really sensitive to openness and dialog, finding some spare time to answer questions and fill indirectly the gaps in our documentation. Quim, while formal documents as those maemo.org provides are cool, it consumes a lot of resources... doing simple but correct/consistent wiki is good enough. Maybe we could setup a techday that we'd meet on IRC and document some topics on Wiki. It would be great to get some people with deep knowledge on hw issues, like Daniel, Siarhei and Eero... I could help with writing and organization, as I never dig on hw that much (but I'll need to do so really soon). If you can manage the timezones, that would probably be okay. America/Europe is doable if you guys get up early, just as long as no-one from Asia-Pacific wants to join in ... 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?
As for pixel doubling, a practical solution would be just to support 400x240 fullscreen resolution in SDL so that no extra hack would be required when porting each game or emulator in particular. +1 to this, as a user. 400x240 is a truely good resolution for a display size like that of a portable device. If some coder can do something towards the aim of improving gfx smoothness by rendering stuff fullscreen at 400x240, please consider the above suggestion and don't distract with harder to achieve aims if the simpler has not yet been done. The fact that the simpler aim is effectively a *hard* one as it seems from the replies to the initial post, should push the other one to a very low priority level. Having a fast screen update in SDL games and emulators at 400x240 (I repeat: a nice res for that screen size!) would be a breeze of fresh air for 770 usage :) -- Antonio ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Documenting maemo pearls (was Re: N800 Video playback)
Daniel Stone wrote: If there's anything you want to know directly, just ask on the list. I tend to deal with email when I'm not actively coding/building/etc, which is how I justify it. A wiki would require me to sit down for a while and really think about stuff, and I don't really have huge blocks of time available to me. But yeah, always happy to answer direct questions. Disadvantage is that it becomes lost in the list archive. Even when you do search the archive it is hard to know proper keywords and it is very likely your brilliant answer will not be found. Many times I am 100% sure the answer is in the list since I remember someone answered it some time ago but even then it is hard or impossible to find. Gustavo Sverzut Barbieri wrote: Quim, while formal documents as those maemo.org provides are cool, it consumes a lot of resources... doing simple but correct/consistent wiki is good enough. Maybe we could setup a techday that we'd meet on IRC and document some topics on Wiki. It would be great to get some people with deep knowledge on hw issues, like Daniel, Siarhei and Eero... I could help with writing and organization, as I never dig on hw that much (but I'll need to do so really soon). If you can manage the timezones, that would probably be okay. America/Europe is doable if you guys get up early, just as long as no-one from Asia-Pacific wants to join in ... This techday is good idea. Sadly it depends on people being available at that time and most probably most people providing interesting answers may be the most busy ones. I tend to avoid IRC because it is big waste of time. There are few gems too found in the archives (thanks Marius G. ;-) but 98% is just babble and FAQs repeated again and again. However I would try to join such techday on IRC (not that I expect my presence to be useful to others). It would be nice to have such tech days regulary preferably with few topics set in advance. But still I don't know how real it is to achieve this and whether wiki or mailing list is not better suited for this after all. Frantisek ___ 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
maybe same discussion at http://maemo.org/pipermail/maemo-developers/2007-February/007762.html ? On 5/1/07, Mike Cowlishaw [EMAIL PROTECTED] wrote: Hi, I have a Wiki running on my N800 using the usual configuration (for many applications) of a TCP/IP server running on the local host address (127.0.0.1) and an TCP/IP client on the same device. (In this case an HTTP web server and the Opera browser.) While trying to test this on an aeroplane at the weekend -- with Wi-Fi offline, of course -- the browser would not connect to the server. I've since experimented further and find a similar (or the same) problem occurs online if no Wi-Fi connection is active. This is a showstopper for my application as it means I cannot easily view my data unless online and connected -- is there a fix/workaround? Thanks -- mfc ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers -- --Antonio Gomes ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
format string vuln in the wifi applet
One year ago I found a security hole in the wifi applet. Which interprets incorrectly the ESSID of the associated accesspoint. This is sprintf(buf, access_point_name); and should be snprintf(buf, BUFSIZE, %s, access_point_name); Well these lines are in my mind (not in the maemo code), but i was unable to find the vuln line in the huge number of C files. I report that one year ago in the GUADEC personally to a Nokia developer, but seems that this bugs stills there. Please fix't :) NOTE: I was unable to exploit this bug, but try setting up an accesspoint with name a%ea or so :) Have phun --pancake ___ 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
Hmm, yes, same discussion - thanks. Unfortunately that thread just faded out with no real solution for how to connect to running server on N800 when offline. One suggestion 'rewrite the application' definitely not an option (especially as I've spent two months porting it to N800.). mfc -Original Message- From: Antonio Gomes [mailto:[EMAIL PROTECTED] maybe same discussion at http://maemo.org/pipermail/maemo-developers/2007-February/007762.html ? On 5/1/07, Mike Cowlishaw [EMAIL PROTECTED] wrote: Hi, I have a Wiki running on my N800 using the usual configuration (for many applications) of a TCP/IP server running on the local host address (127.0.0.1) and an TCP/IP client on the same device. (In this case an HTTP web server and the Opera browser.) While trying to test this on an aeroplane at the weekend -- with Wi-Fi offline, of course -- the browser would not connect to the server. I've since experimented further and find a similar (or the same) problem occurs online if no Wi-Fi connection is active. This is a showstopper for my application as it means I cannot easily view my data unless online and connected -- is there a fix/workaround? Thanks -- mfc ___ 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: By the way, do you have any plans for upgrading toolchain? Either I'm extremely unlucky, or current toolchain is really very buggy. You can see the known issues from the GCC bugzilla. There are a few bugs in C++ support which have been fixed in gcc 3.4.6 (Maemo toolchain is 3.4.4) or 4.x. But doesn't current maemo toolchain have lots of modifications to backport EABI support which only officially appeared in gcc 4.x? These modifications might have introduced some additional instability. True, but GCC bugzilla might anyway be missing bugs existing in upstream gcc too (especially ones that happen only on less common platforms such as ARM). :-) It does not support -pg option properly (for profiling with gprof), 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. On x86 I prefer valgrind/cachegrind/callgrind/kcachegrind as that way one can browse the source code interactively with the profiling information. Getting to know how the source really works is sometimes more useful than knowing the exact bottleneckedness percentage of some function. This is less useful for more hardware dependent features like video though. :-/ also I encountered at least one internal compiler error and a couple of invalid code generation bugs already. C++ code generation? Or C? (GCC bugzilla mentions only C++ code generation issues) I have encountered the following problems on C code (MPlayer). ICE: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22177 Definitely invalid code generation in inline asm (but the same bug apparently shows up in gcc 4.1.1 as well): http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31693 Invalid code generation suspected: https://garage.maemo.org/tracker/index.php?func=detailaid=254group_id=54atid=269 https://garage.maemo.org/tracker/index.php?func=detailaid=763group_id=54atid=269 I did not investigate these two last problems thoroughfully (this might be probably some bad code in MPlayer with 'undefined behaviour' which works better on some compilers but breaks on the others), but they disappear when compiling with gcc 4.1.1 crosscompiler (outside scratchbox using gentoo crossdev). ICE you can get around by trying another optimization level (sometimes -Os or -O3 works where -O2 doesn't). 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? But again, maybe I'm just unlucky to get hit by more bugs than the others :) I know only one issue where a bad code generation was suspected (in C++ code), but it was never really verified. 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) Installing new toolchains for Sbox shouldn't be a problem (if it's already available for it) and you can make a new Sbox target for each toolchain you want to test. Building packages with new toolchain would probably need to have libstdc++ linked statically for C++ applications to work on 770/N800, but otherwise everything should be fine. Actually, you cannot really build static binaries with Glibc. It links some stuff always dynamically (nss for example). I don't know whether this is a problem in practice though. (uClibc is better in this respect and produces significantly smaller binaries too.) One more question is about the kernel, ARM11 seems to support unaligned memory access in hardware, but this feature is not enabled on N800. What the seems, to support and feature enabled mean in the above clause? Seems how? And what is result? Enabled what? seems is a standard disclaimer which means that I did not work with these features myself, only read this information from docs and can't be sure if I understood everything correctly :) ARM CPU is able to trap them? Kernel could SIGBUS the co. processes? (as unaligned access has AFAIK undefined results on ARM, is often coding error and fixing those accesses on kernel side has definitive performance penalty) http://arm.com/documentation/ARMProcessor_Cores/index.html 'ARM1136JF-S and ARM1136J-S r1p1 Technical Reference Manual' Chapter 4 'Unaligned and Mixed-Endian Data Access Support' Did you read the section on ARMv6 unaligned data access restrictions? Basically it doesn't work in all cases, the accesses are not atomic and have performance implications. As ARM11 core used in N800 is little endian, does have floating point unit and supports unaligned memory access in hardware (which only needs to be
Re: Localhost unavailable when wi-fi offline or not connected
On May 2, 2007, at 11:26, Mike Cowlishaw wrote: Hmm, yes, same discussion – thanks. Unfortunately that thread just faded out with no real solution for how to connect to running server on N800 when offline. One suggestion ‘rewrite the application’ definitely not an option (especially as I’ve spent two months porting it to N800…). mfc -Original Message- From: Antonio Gomes [mailto:[EMAIL PROTECTED] maybe same discussion at http://maemo.org/pipermail/maemo- developers/2007-February/007762.html ? On 5/1/07, Mike Cowlishaw [EMAIL PROTECTED] wrote: Hi, I have a Wiki running on my N800 using the usual configuration (for many applications) of a TCP/IP server running on the local host address (127.0.0.1) and an TCP/IP client on the same device. (In this case an HTTP web server and the Opera browser.) While trying to test this on an aeroplane at the weekend -- with Wi-Fi offline, of course -- the browser would not connect to the server. I've since experimented further and find a similar (or the same) problem occurs online if no Wi-Fi connection is active. This is a showstopper for my application as it means I cannot easily view my data unless online and connected -- is there a fix/workaround? Thanks -- mfc It's pretty clear that there is a class of applications that needs to have a browser run against an on-board server even in places where it's not possible or not desirable to connect to an actual network. For my purposes, I'd be happy with any solution that either 1) Provides something similar to the old DUMMY IAP hack 2) Allows me to configure Opera for offline use. There's actually a setting in opera.ini that's tantalizing - Offline Mode=0 - but no matter what I do it does not seem to change Opera's behavior. 3) Uses a non-Opera browser, e.g. Minimo. I found a copy of Minimo that sort of runs on ITOS2007 but I couldn't get it working enough for what I need to do. (And, since then, I lost track of where I found it in the first place). The ITOS2006 compatible Minimo was fine in offline mode but needed too much memory. The pattern of on-board HTTP server + local web pages makes a really powerful application development environment. I'm using Python's BaseHTTPServer class to build a local server and Javascript/ AJAX web pages to build the user interface. The beauty of this paradigm is that you can use tools like Firefox's Firebug on a laptop/ desktop system to build the UI, even while talking to the server on the tablet. And, of course, it's possible to run the Python server code on a laptop/desktop as well. I'd like to encourage the people who are able to do so to actually pursue each of the options above. I'm not well-versed enough in Maemo development to help with any of the three but I'll sure put them to good use! Allan -- Allan Doyle http://museum.mit.edu/mwow +1.781.433.2695 ___ 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/2/07, Eero Tamminen [EMAIL PROTECTED] wrote: It's evil that games change screen resolution, system changes should be controlled by system software instead of random apps. If it's enough that the whole screen is scaled instead of a window or specific update, for Maemo the XRandR approach could be joined with my earlier proposal. I.e. if window has certain property (say geometry=320x200), the window manager could use XRandR to switch the screen resolution when that kind of a window is on top/focused/fullscreen(ed). When the window is not anymore focused/top/fullscreen or is closed, the previous/default resolution is restored. This way banners above the window wouldn't get the resolution changed (banners don't take focus), but dialogs (like power menu) would. Do you see any problems (besides getting these changes to Matchbox and SDL after adding XRandR support to Xomap)? Theres a big downside to this approach in that matchbox already supports randr and has done for a while in order to facilitate stuff like screen rotation - matchbox will in effect resize all windows and position dialogs as to adapt to the new screen resolution - like other WM's also do. This is what you'd expect in the general case. So if you pixel double via randr every single application is going to get resized and un resized. Whats worse is theres not going to be an easy way around this as much stuff in matchbox is obviously dependant on the 'real' display geometry. 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 :) -- Matthew ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
On Wed, May 02, 2007 at 07:08:24PM +0300, Eero Tamminen wrote: Hi, Daniel Stone wrote: Hence, XRandR. The only thing worse than designing a bad API, is designing _another_ API. Hm. I think the API on Desktop for scaling window content is OpenGL. ;-) Sure, but we don't have OpenGL support right now, and the only other way is using a Render transformation for every op, which would be mindblowingly slow. RandR allows you to change the screen size. This is what pixel doubling does: it changes the size of the entire screen, really. XRandR is a way to do this that doesn't end up making everyone angry. If you can come up with a policy that works in corner cases, you're a genius. It's evil that games change screen resolution, system changes should be controlled by system software instead of random apps. Indeed. If it's enough that the whole screen is scaled instead of a window or specific update, for Maemo the XRandR approach could be joined with my earlier proposal. I.e. if window has certain property (say geometry=320x200), the window manager could use XRandR to switch the screen resolution when that kind of a window is on top/focused/fullscreen(ed). When the window is not anymore focused/top/fullscreen or is closed, the previous/default resolution is restored. This way banners above the window wouldn't get the resolution changed (banners don't take focus), but dialogs (like power menu) would. Do you see any problems (besides getting these changes to Matchbox and SDL after adding XRandR support to Xomap)? It's a shocking hack, but sure, if we desperately need to support this kind of thing, then this seems like the most fail-safe option (the current option arguably being the most desirable, as it limits the damage). Of course, having OpenGL support would be preferable, but that's neither here nor there. joking Any chance of getting this into EWMH spec? /joking Ha! You first. Cheers, Daniel signature.asc Description: Digital signature ___ 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
allan, what minimo maemo port version are you running ? On 5/2/07, Allan Doyle [EMAIL PROTECTED] wrote: On May 2, 2007, at 11:26, Mike Cowlishaw wrote: Hmm, yes, same discussion – thanks. Unfortunately that thread just faded out with no real solution for how to connect to running server on N800 when offline. One suggestion 'rewrite the application' definitely not an option (especially as I've spent two months porting it to N800…). mfc -Original Message- From: Antonio Gomes [mailto:[EMAIL PROTECTED] maybe same discussion at http://maemo.org/pipermail/maemo- developers/2007-February/007762.html ? On 5/1/07, Mike Cowlishaw [EMAIL PROTECTED] wrote: Hi, I have a Wiki running on my N800 using the usual configuration (for many applications) of a TCP/IP server running on the local host address (127.0.0.1) and an TCP/IP client on the same device. (In this case an HTTP web server and the Opera browser.) While trying to test this on an aeroplane at the weekend -- with Wi-Fi offline, of course -- the browser would not connect to the server. I've since experimented further and find a similar (or the same) problem occurs online if no Wi-Fi connection is active. This is a showstopper for my application as it means I cannot easily view my data unless online and connected -- is there a fix/workaround? Thanks -- mfc It's pretty clear that there is a class of applications that needs to have a browser run against an on-board server even in places where it's not possible or not desirable to connect to an actual network. For my purposes, I'd be happy with any solution that either 1) Provides something similar to the old DUMMY IAP hack 2) Allows me to configure Opera for offline use. There's actually a setting in opera.ini that's tantalizing - Offline Mode=0 - but no matter what I do it does not seem to change Opera's behavior. 3) Uses a non-Opera browser, e.g. Minimo. I found a copy of Minimo that sort of runs on ITOS2007 but I couldn't get it working enough for what I need to do. (And, since then, I lost track of where I found it in the first place). The ITOS2006 compatible Minimo was fine in offline mode but needed too much memory. The pattern of on-board HTTP server + local web pages makes a really powerful application development environment. I'm using Python's BaseHTTPServer class to build a local server and Javascript/ AJAX web pages to build the user interface. The beauty of this paradigm is that you can use tools like Firefox's Firebug on a laptop/ desktop system to build the UI, even while talking to the server on the tablet. And, of course, it's possible to run the Python server code on a laptop/desktop as well. I'd like to encourage the people who are able to do so to actually pursue each of the options above. I'm not well-versed enough in Maemo development to help with any of the three but I'll sure put them to good use! -- --Antonio Gomes ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
On Wed, May 02, 2007 at 05:52:38PM +0100, ext Matthew Allum wrote: Theres a big downside to this approach in that matchbox already supports randr and has done for a while in order to facilitate stuff like screen rotation - matchbox will in effect resize all windows and position dialogs as to adapt to the new screen resolution - like other WM's also do. This is what you'd expect in the general case. So if you pixel double via randr every single application is going to get resized and un resized. Whats worse is theres not going to be an easy way around this as much stuff in matchbox is obviously dependant on the 'real' display geometry. I guess you could hack around this by walking the tree and looking for a full-screen override-redirect window (or one with the appropriate class). If you find one, then pend the resolution change of all windows to when you switch away from it; a correctly-behaved app will fix the resolution before it leaves, thus leaving you with no need to bother everything else. Would that work? 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. Cheers, Daniel signature.asc Description: Digital signature ___ 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
On May 2, 2007, at 13:37, Antonio Gomes wrote: allan, what minimo maemo port version are you running ? That's the funny thing. I was blitzing through a number of things, then reflashed, and wound up not getting back to it before I realized I don't know where I had found the Minimo. If I find it again, I can try it out again... Allan On 5/2/07, Allan Doyle [EMAIL PROTECTED] wrote: On May 2, 2007, at 11:26, Mike Cowlishaw wrote: Hmm, yes, same discussion – thanks. Unfortunately that thread just faded out with no real solution for how to connect to running server on N800 when offline. One suggestion 'rewrite the application' definitely not an option (especially as I've spent two months porting it to N800…). mfc -Original Message- From: Antonio Gomes [mailto:[EMAIL PROTECTED] maybe same discussion at http://maemo.org/pipermail/maemo- developers/2007-February/007762.html ? On 5/1/07, Mike Cowlishaw [EMAIL PROTECTED] wrote: Hi, I have a Wiki running on my N800 using the usual configuration (for many applications) of a TCP/IP server running on the local host address (127.0.0.1) and an TCP/IP client on the same device. (In this case an HTTP web server and the Opera browser.) While trying to test this on an aeroplane at the weekend -- with Wi-Fi offline, of course -- the browser would not connect to the server. I've since experimented further and find a similar (or the same) problem occurs online if no Wi-Fi connection is active. This is a showstopper for my application as it means I cannot easily view my data unless online and connected -- is there a fix/workaround? Thanks -- mfc It's pretty clear that there is a class of applications that needs to have a browser run against an on-board server even in places where it's not possible or not desirable to connect to an actual network. For my purposes, I'd be happy with any solution that either 1) Provides something similar to the old DUMMY IAP hack 2) Allows me to configure Opera for offline use. There's actually a setting in opera.ini that's tantalizing - Offline Mode=0 - but no matter what I do it does not seem to change Opera's behavior. 3) Uses a non-Opera browser, e.g. Minimo. I found a copy of Minimo that sort of runs on ITOS2007 but I couldn't get it working enough for what I need to do. (And, since then, I lost track of where I found it in the first place). The ITOS2006 compatible Minimo was fine in offline mode but needed too much memory. The pattern of on-board HTTP server + local web pages makes a really powerful application development environment. I'm using Python's BaseHTTPServer class to build a local server and Javascript/ AJAX web pages to build the user interface. The beauty of this paradigm is that you can use tools like Firefox's Firebug on a laptop/ desktop system to build the UI, even while talking to the server on the tablet. And, of course, it's possible to run the Python server code on a laptop/desktop as well. I'd like to encourage the people who are able to do so to actually pursue each of the options above. I'm not well-versed enough in Maemo development to help with any of the three but I'll sure put them to good use! -- --Antonio Gomes -- Allan Doyle http://museum.mit.edu/mwow +1.781.433.2695 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
On Wednesday 02 May 2007 20:40, Daniel Stone 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. This is what works for MPlayer on Nokia 770. It creates x11 window just to reserve some screen space and prevent other applications from using it. After that, it renders data directly to framebuffer and uses x11 for input. It is not very clean, but it works. And it works fast. The same trick can be probably done for SDL. Here is a link to the old discussion in the mailing list with the initial idea: http://maemo.org/pipermail/maemo-developers/2006-December/006646.html ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Fwd: Compiling latest kernel (from kernel.org, linux-omap git version) in n800
Guillerm, thanks for your reply. So, about the use of --force-vermagic with busybox modprobe... What should I have to do to make busybox modprobe support --force-vermagic? get modprobe source code, and...? How about to use n770? The WLAN interface driver source code is available or it is like n800? Thank you, Leandro. Guillem Jover [EMAIL PROTECTED]: On Thu, 2007-04-26 at 17:44:31 -0300, ext Leandro Melo de Sales wrote: So, finally. Is the unique solution to wait nokia until they release the umac.ko source and live with n800 + latest linux-omap kernel version without WLAN support? Normal module-init-tools' modprobe has a --force-vermagic option, which you could use to load umac.ko and ignore its vermagic info. I don't see this option supported right now by busybox modprobe, but should not be that much work to add it. Of course this is a workaround, and the proper solution would be to have the source for that module, but sadly that's not the case now so ... regards, guillem ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Fwd: Compiling latest kernel (from kernel.org, linux-omap git version) in n800
Leandro Melo de Sales wrote: Guillerm, thanks for your reply. So, about the use of --force-vermagic with busybox modprobe... What should I have to do to make busybox modprobe support --force-vermagic? get modprobe source code, and...? How about to use n770? There is slightly quicker/easier but more hackish and definitely wrong way which may or may not work. You can set kernel version in main kernel Makefile to be what you want (i.e. the older one, see /proc/version on device) and then recompile kernel. Modules will load without changing insmod/modprobe but some may crash. Those that will crash need recompiling. The proprietary umac could works since in theory it should not use kernel API. The WLAN interface driver source code is available or it is like n800? Hopefully yes, in Maemo garage. So if this one will crash you could recompile it. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Toolchain upgrade? (Was: Instructions cache flush on ARM)
On Wednesday 02 May 2007 18:48, Eero Tamminen wrote: On x86 I prefer valgrind/cachegrind/callgrind/kcachegrind as that way one can browse the source code interactively with the profiling information. Getting to know how the source really works is sometimes more useful than knowing the exact bottleneckedness percentage of some function. Sure, I'm also using valgrind/cachegrind/callgrind/kcachegrind in my work quite often. It's a very nice tool. But callgrind for statistics does not provide information about floating point math and integer divisions, so real results on ARM may be really very different. Also cache behaviour on Nokia 770 arm926ej-s core is very different from cache on x86. Actually arm926ej-s does not allocate cache line on write miss and all the x86 cpus do. This makes very big difference for the code which does lots of writes to uncached memory. Cachegrind only simulates write-allocate cache. I created the following patch for simulating read-allocate behaviour in callgrind (for more precise arm926ej-s simulation): http://ufo2000.sourceforge.net/files/vg-read-allocate-cache-patch.diff Though arm1136jf-s core from N800 now supports write-allocate cache and this patch is not needed when optimizing for N800 :) 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) Installing new toolchains for Sbox shouldn't be a problem (if it's already available for it) and you can make a new Sbox target for each toolchain you want to test. Thanks, I'll try that. In my preliminary tests, mplayer becomes a few percents faster for mpeg4 decoding when switching to gcc 4.1.1 (tested a build compiled with a crosscompiler outside scratchbox, with no audio/video output except for SDL, so not really useful for end users, but fine for benchmarking with gprof). Building packages with new toolchain would probably need to have libstdc++ linked statically for C++ applications to work on 770/N800, but otherwise everything should be fine. Actually, you cannot really build static binaries with Glibc. It links some stuff always dynamically (nss for example). I don't know whether this is a problem in practice though. 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. http://arm.com/documentation/ARMProcessor_Cores/index.html 'ARM1136JF-S and ARM1136J-S r1p1 Technical Reference Manual' Chapter 4 'Unaligned and Mixed-Endian Data Access Support' Did you read the section on ARMv6 unaligned data access restrictions? Basically it doesn't work in all cases, the accesses are not atomic and have performance implications. 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? 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. As ARM11 core used in N800 is little endian, does have floating point unit and supports unaligned memory access in hardware (which only needs to be enabled). It probably doesn't have any serious portability issues to be aware of anymore and vast majority of software initially developed for x86 should be easy to compile and run on it even without doing any modifications. Compiler aligns everything correctly if your code is correct. I think non-aligned code is bug and performance issue. In the real world such buggy code unfortunately exists. And it works fine on x86 which is probably the most widely used platform for software development. Enabling unaligned memory support will make life much easier for developers unfamiliar with ARM platform. The number of applications for
Re: Xsp pixel-doubling solutions for Nokia 770?
--- Siarhei Siamashka [EMAIL PROTECTED] wrote: Siarhei Siamashka wrote: This is what works for MPlayer on Nokia 770. It creates x11 window just to reserve some screen space and prevent other applications from using it. After that, it renders data directly to framebuffer and uses x11 for input. It is not very clean, but it works. And it works fast. The same trick can be probably done for SDL. Indeed SDL is the 'gaming api' in-use for games that run acceptably on tablets, and Xrandr would be the natural choice for changing screen resolution. While that would be fast and simple, it doesn't look good. See http://pupnik.de/ScalersExult.png As the screenshots show, a Scale2x or 2xSai scaler yields much more readable text (view on the tablet to get a good idea of this). While I appreciate that the folks at Nokia are looking into solutions aimed at future Xomap and tablet releases, my interest is directed toward improvements that can apply to current N770 and N800 tablets. To this end, my hope would be for a fast Implementation of SDL's HWSURFACE that would allow the SDL app to use an internal high quality scaler or 800x480 native resolutions. Siarhei Siamashka wrote: Also it would be a good idea to benchmark SDL, identify maemo or ARM architecture related bottlenecks and try to fix them. Many older generation games worked perfectly on hardware way slower than Nokia 770. So Nokia 770 may be a good platform for mobile gaming if properly optimized This is what works for MPlayer on Nokia 770. It creates x11 window just to reserve some screen space and prevent other applications from using it. After that, it renders data directly to framebuffer and uses x11 for input. It is not very clean, but it works. And it works fast. The same trick can be probably done for SDL. If the memcpy on 770 is something like 190MB/s, pushing 800x480 at 30fps would use only 12 percent of that bandwidth I feel that a better SDL implementation would be time/money well spent, as it would be an easier upgrade than Xomap for current 770/800s, and would also benefit future nokia tablets. 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?
On Wed, May 02, 2007 at 01:01:00PM -0700, ext Arnim Sauerbier wrote: Siarhei Siamashka wrote: This is what works for MPlayer on Nokia 770. It creates x11 window just to reserve some screen space and prevent other applications from using it. After that, it renders data directly to framebuffer and uses x11 for input. It is not very clean, but it works. And it works fast. The same trick can be probably done for SDL. Indeed SDL is the 'gaming api' in-use for games that run acceptably on tablets, and Xrandr would be the natural choice for changing screen resolution. While that would be fast and simple, it doesn't look good. See http://pupnik.de/ScalersExult.png As the screenshots show, a Scale2x or 2xSai scaler yields much more readable text (view on the tablet to get a good idea of this). I assume your 'xrandr' screenshot is taken on the desktop? RandR doesn't imply a specific scaling algorithm. Indeed, my plan was to just expose 800x480 and 400x240, and use the exact same pixel doubling in Hailstorm to achieve the latter. While I appreciate that the folks at Nokia are looking into solutions aimed at future Xomap and tablet releases, my interest is directed toward improvements that can apply to current N770 and N800 tablets. I don't see the conflict between working on new Xomap versions and improving the N800. To this end, my hope would be for a fast Implementation of SDL's HWSURFACE that would allow the SDL app to use an internal high quality scaler or 800x480 native resolutions. I don't see the point in doing pixel doubling in software. Thus, what we have is restricted to the hardware. Not only would the expansion take CPU time, but you then have to send the entire expanded screen over RFBI, which sucks. If the memcpy on 770 is something like 190MB/s, pushing 800x480 at 30fps would use only 12 percent of that bandwidth It's not about memcpy. I think the _maximum theoretical_ rate of screen updates is 28fps, 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. 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?
On Wednesday 02 May 2007 23:01, Arnim Sauerbier wrote: If the memcpy on 770 is something like 190MB/s, pushing 800x480 at 30fps would use only 12 percent of that bandwidth I'm sorry, I was the source of this misleading information, I forgot that you are a Nokia 770 user and mentioned some numbers from N800. I measured the memory bandwidth as ~170-190MB/s for memcpy and ~410MB/s for memset on N800. The same numbers on Nokia 770 are ~70-100MB/s for memcpy (depending on relative source and destination buffers alignment) and ~120MB/s for memset with the standard glibc functions. These glibc functions have ARM assembly optimizations developed by Nicolas Pitre from MontaVista Software, Inc., but according to comments found inside, they were developed for XScale cpus. Such code is not so good for Nokia 770 and can be replaced with something better. Using some arm926ej-s specific optimizations, it is possible to get ~100-110MB/s for memcpy and ~270MB/s for memset on Nokia 770. More details and a link to the necessary code can be found here: https://maemo.org/bugzilla/show_bug.cgi?id=733 Maybe it is time to try getting these optimized functions integrated into glibc for use on Nokia 770? Surely they need to be tested a bit more first. But improving core system components (glibc, xserver, SDL, ..) may help to make Nokia 770 at least a bit faster and more competitive. Any comments are surely welcome. I wonder if it would be possible to get a community improved firmware for Nokia 770 created (with bootmenu included, improvements to the kernel, gstreamer ogg vorbis support out of the box, some performance optimizations and bugfixes) and become available for download somewhere? Because of proprietary parts, probably this firmware should be hosted by Nokia in the standard place where the user needs to enter serial number to download it? Of course it would be unofficial and unsupported just like the hacker's edition. ___ 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 12:35:15AM +0300, ext Siarhei Siamashka wrote: Maybe it is time to try getting these optimized functions integrated into glibc for use on Nokia 770? Surely they need to be tested a bit more first. But improving core system components (glibc, xserver, SDL, ..) may help to make Nokia 770 at least a bit faster and more competitive. Any comments are surely welcome. I wonder if it would be possible to get a community improved firmware for Nokia 770 created (with bootmenu included, improvements to the kernel, gstreamer ogg vorbis support out of the box, some performance optimizations and bugfixes) and become available for download somewhere? Because of proprietary parts, probably this firmware should be hosted by Nokia in the standard place where the user needs to enter serial number to download it? Of course it would be unofficial and unsupported just like the hacker's edition. Step one would be for someone to get up and volunteer to lead this project. Step two would be for someone to put together a coherent and compelling package set that would justify a fork. Step three would be to scout around for hosting space. signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 Video playback
On Wednesday 02 May 2007 12:54, Daniel Stone wrote: The 'framebuffer' is just the ordinary system memory, converting color format and copying data to framebuffer will be done with the same performance as simulated in this test. RFBI performance is only critical for asynchronous DMA data transfer to LCD controller which does not introduce any overhead and is performed at the same time as ARM core is doing some other work (decoding the next frame). RFBI performance matters only if data transfer to LCD is still not complete at the time when the next frame is already decoded and is ready to be displayed. When playing video, ARM core and LCD controller are almost always working at the same time performing different tasks in parallel. I think I had already explained these details in [1] Right. My point is that the numbers you're showing -- while very good, don't get me wrong -- won't necessarily have a huge direct impact on video playback. Particularly if you want to avoid tearing. I have no idea what other proof would be enough for you. You already got all the numbers, and even benchmarks with patched xserver. They all confirm video output performance improvement. So now the results of the tests are consistent - when doing video output, most of ARM core cycles are spent in this 'omapCopyPlanarDataYUV420' function. Well, either that, or just waiting for RFBI transfers to complete. You need to wait a bit before displaying the next frame anyway, and the period between frames for 30 fps video usually eclipses transfer completion time. If you want some numbers, now 640x480 YUV420 (12bpp) screen update takes now 25ms without tearsync flag enabled (OMAPFB_FORMAT_FLAG_TEARSYNC for OMAPFB_UPDATE_WINDOW ioctl) and 25-42ms with tearsync. For 30 fps video, period between performing screen updates is normally 33ms. For playing video, we initiate RFBI transfer, wait till it completes, perform VY12-YUV420 color format conversion (which should take less than 4ms for 640x480 considering benmchmark results), wait till it is time to display the next frame and start RFBI transfer again. For 30 fps video 25ms+4ms is less than 33ms, so without tearsync enabled, any 640x480 video should play fine (considering video output performance). With tearsync enabled, we should add the time needed for performing vertical sync in LCD controller which breaks our nice numbers. Worst case (17ms wait for retrace + 25ms for actual data transfer) takes more time than 33ms between frames. We can be saved if LCD controller internal refresh rate is really 60Hz, it this case video playback will automagically synchronize to LCD refresh rate and each frame processing will be done exactly within 2 LCD refresh cycles (by the time we want to display a video frame, the next vertical will be near and we will not lose much time waiting for it). 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. That's what I'm investigating now. In any case, getting ideal 24 fps playback will be a bit easier. I hope all these explanations are clear now. And this is not just a theory, but already confirmed by some experiments and practical tests. I'm still using Scratchbox 0.9.8.5 for day-to-day stuff ... Thanks, that is what I would consider 'additional tips and tricks' :) It is good to know that maemo 3.x development can be also done with older scratchbox (I have 0.9.8.8 installed now), I'll try it without upgrading scratchbox then. Well, anyway, everything worked perfectly and I could play 640x480 video on N800 with the following statistics: VIDEO: [DIVX] 640x480 12bpp 23.976 fps 886.7 kbps (108.2 kbyte/s) ... BENCHMARKs: VC: 87,757s VO: 8,712s A: 1,314s Sys: 3,835s = 101,618s BENCHMARK%: VC: 86,3592% VO: 8,5736% A: 1,2932% Sys: 3,7740% = 100,% BENCHMARKn: disp: 2044 (20,11 fps) drop: 355 (14%) total: 2399 (23,61 fps) As you see, mplayer took 8.712 seconds to display 2044 VGA resolution frames. If we do the necessary calculations, that's 72 millions pixels per second, quite close to 'yv12_to_yuv420_line_armv6' capabilities limit, so this function is the only major contributor to video output time. Video output took much less time than decoding, so it proves that video output overhead can be reduced to minimum (in this test tearsync was not used though). I'd be curious to see the results from this with tearsync _enabled_? i.e., after your OMAPFB_UPDATE_WIDNOW call, issue an OMAPFB_SYNC_GFX ioctl before you start writing to memory again. This is basically the limiter for us at this stage. That's exactly how MPlayer works. It always waits on OMAPFB_SYNC_GFX before filling framebuffer with the data for the next frame. Not issuing OMAPFB_SYNC_GFX would introduce *artificial* tearing not related to sync with LCD
RE: Documenting maemo pearls (was Re: N800 Video playback)
Don't kill the messenger! But yeah, always happy to answer direct questions. Disadvantage is that it becomes lost in the list archive. This is an old problem communication science solved centuries ago: generally you have those generating information and those collecting it. Asking the sources to organize information is many times as useless as asking the documenters to generate new data. I keep thinking the right approach in our case is: - maemo.org should provide the right infrastructure to document easily (getting there). - the maemo team should make sure that all the essential information reaches the official documentation (still a while to get there). - the maemo community could help organizing themselves in wiki-based collaboration and pointing essential information missing in the official documentation (up to you, tell us where we can help). I keep insisting in a clear separation between official and community documentation. Don't get me wrong, I think the quality and usefulness of community docs can match and outsmart official documentation, in maemo and in any software project (in fact in *any* type of project). But think on the zillions of newcomers we want to welcome: most of them are looking for a single, comprehensive and reliable source of information, structured in a way that makes sense in order to find what I'm looking for. These are elements required in good quality official documentation, while these same elements can kill community workflow (generally quite spontaneous) if not handled properly. Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 Video playback
On Wednesday 02 May 2007 12:39, Daniel Stone wrote: On Wed, May 02, 2007 at 09:16:01AM +0300, ext Siarhei Siamashka wrote: On Tuesday 01 May 2007 20:49, Siarhei Siamashka wrote: Results with unpatched xserver and some more explanations can be found in [3]. Yes, now N800 is faster than Nokia 770 for video output performance at last :) Well, still not everything is so good until the following bug gets fixed: https://maemo.org/bugzilla/show_bug.cgi?id=1281 The patch for optimized Xv performance will not help to watch widescreen video which triggers this tearing bug. If you see tearing on the screen, you should know that the YUV420 color format conversion optimization patch does not get used at all and xserver most likely uses a slow nonoptimized YUV422 fallback code with software scaling. Indeed. And the reason the code is there is because Hailstorm can only downscale at fixed ratios (half and one-quarter), and even then, it locked up when we tried. Similarly, the display controller's downscaling didn't work, either. So we can optimise the fallback path, but you'll still be screwed by sending 16bpp (instead of 12bpp) through RFBI. The only thing which is unclear here is that Hailstorm does not need to downscale video in this situation. The bug can be reproduced with 512x288 video which just needs upscaling to 800x450. Also even standard Nokia_N800.avi video with proper aspect ratio causes a huge performance regression and tearing. Please give this #1281 issue another look. It looks like a bug in xserver, but not a hardware limitation. I can probably try to workaround it by requesting not 512x288 buffer from Xv, but something like 512x308, use only 512x288 part of it and artificially add black bands above and below. After that, Xv can be asked to expand it to 800x480 to get expected result But if it is a bug in xserver, it would be better to get it fixed, preferably before the next firmware update :) Fixing this bug is critical for video playback performance. I hope it will be solved in the next version of N800 firmware too. But it we get some patch to solve this problem for testing earlir, that would be nice too. The only patch is optimising that function, really. Even if we did work out a way to make Hailstorm happy, you can still only scale at those exact multiples, which doesn't make it a viable general solution. I will do optimized software YV12-YUV420 JIT scaler a bit later (on next weekend?). It will be only a minor modification of YV12-YUV422 scaler which already exists and works fine. If it can be useful for xserver, it might be added there at any time. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 Video playback
2007/5/1, Siarhei Siamashka [EMAIL PROTECTED]: On Tuesday 01 May 2007 17:49, Kalle Vahlman wrote: OK, here is this untested a patch for xserver to add ARMv6 optimized YUV420 color format conversion. Theoretically it should compile (I did not try to build xserver myself though) and work. If it refuses to compile, fixing the patch should be not too difficult. Applied and build without problems for me. Thanks a lot for building the package and putting it for download, everything seems to be fine, but more details will follow below. For testing, I fabricated some video with gstreamer: which resulted in [EMAIL PROTECTED] and [EMAIL PROTECTED] videos. For some reason 320x240 and 352x288 refused to play with: X11 error: BadValue (integer parameter out of range for operation) MPlayer interrupted by signal 6 in module: flip_page while gstreamer did play them just fine. Also the Nokia_N800.avi and NokiaN93.avi died in the same way. This X11 error on video playback start and also sometimes on switching fullscreen/windowed mode is a known problem [1] reported in this mailing list. If MPlayer dies on start, usually trying to start it again succeeds. So these 320x240 and 352x288 videos could be played as well if you were a bit more persistent :) No, it's actually 100% reproducable in this situation (yes, I tried a number of . You see, I didn't have the window manager running. It breaks with the N800 video too. Running with the window manager does make it runnable, but it also changes the window size which I wanted to avoid. My mplayer is compiled from the svn trunk of the garage project, with some additional cflags I use (so maybe those were the problem...). Do you have a set of cflags settings which work better than the default set? Can you share this information? If by default set you mean what the default options in the toolchain is, then yes (as there are none AFAIK ;). If you mean the default options for mplayer, I don't know if they add any value. I like to use my hardware well ;) so I tend to compile everything with VFP enabled and optimized for the processor: CFLAGS='-mcpu=arm1136j-s -mfpu=vfp -mfloat-abi=softfp -O2' Now, wheter it works better than thumb code is debatable, as optimizing code size might be more beneficial than having fast floats. But at least I was happy with the results we got from our testing, detailed in http://syslog.movial.fi/archives/46-N800-VFP-or-not-to-VFP.html I doubt they will do much good for mplayer, as I assume most critical operations will be highly optimized already by hand and not left entirely for the compiler... If you want a guaranteed video playback with divx/xvid/mpeg4 codecs, you should restrict to 512x384 resolution or lower and keep bitrate reasonable. The results for these 'insane' videos you have posted are somewhat weird, a complete statistics would require also a number of frames dropped, otherwise we don't know how much work was done by the player. Probably missing audio track resulted in MPlayer not being able to provide a proper report. Yeah, I guess the fabricated videos weren't that good. Have to do some more testing with real videos... Yes, now N800 is faster than Nokia 770 for video output performance at last :) This is _very_ cool indeed :) -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
