Re: How to remap keyboard at start up
On Thu, Sep 27, 2007 at 10:47:40AM +0200, ext Tomàs Jiménez Lozano wrote: We have written a very simple script to remap HWKeys using xmodmap that works fine when we launch it from the command line. However, when we try to execute it within the start up process it doesn't work. We are launching it at the end of the /etc/osso-af-init/real-af-base-apps script and, in fist instance, it seems to work properly. Just after start up, we ask for the keyboard mapping (ie: xmodmap -pk) and HWKeys have been remapped. But whenever we use any of the HWKeys our remapping is overriden and default configuration seems to have been set again. Any help would be appreciate. You might rebuilding the X server with http://people.freedesktop.org/~daniels/mapping-changes-for-all.diff. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Freescale Licenses AMD Graphics Technologies for use in iMX processors
On Wed, Sep 19, 2007 at 09:22:02PM -0400, ext Jon Smirl wrote: Here's a good reason to switch from OMAP to iMX31 in next gen device Combine this with AMD's decision to open source the specs. AMD today announced Freescale Semiconductor will license its 2D and 3D graphics technology. Freescale Semiconductor will use the AMD graphics technologies to equip its i.MX processors with OpenGL ES 2.0 and OpenVG 1.0 technologies. OpenGL ES 2.0 and OpenVG technologies are designed for mobile applications where battery life is key, including portable gaming, navigation and media player devices. AMD has opened the Radeon graphics specs. Their embedded chipsets (based on work by the Bitboys crew) have nothing to do with the Radeons, and nothing to do with the announcement in the slightest. signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Leaving N800 connected to AC for long periods
On Mon, Sep 17, 2007 at 10:20:30AM +0100, ext Jonathan Matthews-Levine wrote: On 9/16/07, Jeffrey Barish [EMAIL PROTECTED] wrote: For development, I have my N800 running all day. Surely, it's bad for the battery to run it down every day and charge it every night. But how is it for the battery to leave the N800 connected to AC all day? Is it possible to run the N800 without a battery and would that be better? The 770's battery was required for operation: I've not got my N800 with me today to check if it can run battery-less. ISTR that others have said on this list that it also completes the circuit, without which the N800 can't power on. It can't power on without the battery, no. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: DSME code?
On Fri, Sep 14, 2007 at 11:15:52AM -0400, ext Dave Neuer wrote: If you still have it cached, and could describe how it works to someone who hasn't seen it, it would be an opportunity for the community to work on a replacement. The D-Bus API is a very good start: have you considered looking at that? I don't see anything stopping anyone from starting work on DSME, now, commits or no (you really don't want questions about the legitimacy of your code). Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: DSME code?
On Fri, Sep 14, 2007 at 11:44:40AM -0400, ext Dave Neuer wrote: But honestly, just as I'm sure it's tiresome for Nokia employees to hear me constantly harp on the closed nature of the IT OS, it's tiresome for me to hear well-intentioned Nokia employees such as yourself and Igor insist I should just look at D-Bus or hints dropped on mailing lists and guess what closed Nokia software does. Hi, DSME doesn't do anything complex, really. Looking at the API, it's trivial to reimplement, but as far as I can tell, no-one's ever started. Of course, it should be open, but the fact that no-one's even tried probably says something about how desirable/essential it is to current community efforts, to be honest. Implementing something relatively trivial is definitely vastly easier than reverse-engineering current-generation video cards, let me tell you. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: DSME code?
On Fri, Sep 14, 2007 at 12:19:15PM -0400, ext Dave Neuer wrote: It's possible that people who aren't happy, but aren't getting paid to work on the IT OS for 770 are worried that they will start, run into obstacles and a lack of information and have wasted their time -- DMSE is just one of several components that need to be replaced in order to have a completely-open 770, right? There's no real such thing as a waste of time in this regard. If you don't manage to completely replace the entire thing, you still have something, you may have still learned something, and you may have helped convince people that there are people who actually want to work on DSME (and thus, from a business point of view, a benefit to open-sourcing it). As I said before, DSME isn't even terribly difficult to reverse-engineer. I'm saying this as someone who's read the DSME code, and also the DSME API. The closed components I can think of (barring anything high up in userspace: browser, email, UI, whatever) are nolo, DSME, and BME. BME could be done, though you want to watch your battery for signs of puffiness. nolo is very difficult, though it's entirely predictable, so while it could be done, it'd be extremely tough. DSME is trivial. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: DSME code?
On Fri, Sep 14, 2007 at 12:39:18PM -0400, ext Jesse Guardiani wrote: I'd personally love to see DSME open sourced. Oh, me too. Nothing I've said on this list should indicate otherwise. In particular, there are screen ON/OFF/Notify events that it sends/receives via dbus that I'd love to extend. For example, I've got a DSME related ticket that I'd like to close using dbus, but that probably isn't possible with DSME as-is: https://www.guardiani.us/projects/kagu/ticket/52 You can just bypass DSME and deal with omapfb directly: see asm-arm/arch-omap/omapfb.h. Note that DSME does this every 1s or so, so you're in a godawful race, so you might just have to nuke the blanking plugin or something. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Trapping application crashes?
On Tue, Sep 04, 2007 at 11:01:40PM -0700, ext Jayesh Salvi wrote: If you end up registering your signal handlers - do only little in those signal handlers. It's not a good idea to keep executing once you have corrupted memory - you might run into more ugly errors. Indeed, man signal (at least from glibc) explicitly lists the only calls that are safe to run from signal handlers. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Trapping application crashes?
On Wed, Sep 05, 2007 at 11:43:34AM +0300, Marius Vollmer wrote: ext Daniel Stone [EMAIL PROTECTED] writes: On Tue, Sep 04, 2007 at 11:01:40PM -0700, ext Jayesh Salvi wrote: If you end up registering your signal handlers - do only little in those signal handlers. It's not a good idea to keep executing once you have corrupted memory - you might run into more ugly errors. Indeed, man signal (at least from glibc) explicitly lists the only calls that are safe to run from signal handlers. Which is of course a different thing: even if you only use the signal-safe functions in your handler, you shouldn't ever return from it and try to continue the program. Of course; I wasn't trying to suggest otherwise. 'Do absolutely bugger all, and then get out.' signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: OSSO Media Server and system pauses
On Wed, Aug 29, 2007 at 03:35:16PM -0400, ext Jesse Guardiani wrote: This is the result of communicating with Tony and Kemal (disq) off list: https://www.guardiani.us/projects/kagu/changeset/483 Seems to have always been that way. Probably just a typo. Amazing what happens when you file coherent, detailed, bug reports, instead of just mentioning on an unrelated list somewhere that Kagu is complete overengineered crap and should never be used by anyone, mm? signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Do you ltrace work well?
On Fri, Aug 17, 2007 at 01:55:45PM +0800, ext 杨明 wrote: I download ltrace source code from http://repository.maemo.org/pool/maemo/ossw/source/l/ltrace/ and build it. but it can' t work . Nokia-N800-12:~# ./ltrace -p 889 breakpointed at 0xb9a4 (?) __libc_start_main(69245, 1, 0xbecea6f4, 70500, 70596 unfinished ... breakpointed at 0xb9a4 (?) __libc_start_main(69245, 1, 0xbecea6f4, 70500, 70596 unfinished ... breakpointed at 0xb9a4 (?) . breakpointed at 0xb9a4 (?) __libc_start_main(69245, 1, 0xbecea6f4, 70500, 70596Error: call nesting too deep! unfinished ... breakpointed at 0xb9a4 (?) __libc_start_main(69245, 1, 0xbecea6f4, 70500, 70596Error: call nesting too deep! unfinished ... . You need to build with -fomit-frame-pointer. signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: where is the source code of icd
On Fri, Aug 17, 2007 at 02:49:41PM +0800, ext 杨明 wrote: I can't find out it in repository. icd isn't open source. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Do you ltrace work well?
On Fri, Aug 17, 2007 at 03:26:10PM +0800, ext 杨明 wrote: I download ltrace-0.3.31 from http://repository.maemo.org/pool/maemo/ossw/source/l/ltrace/ # cd ltrace-0.3.31 # ./configure update make file add -fomit-frame-pointer to CFLAG # make upload to n800, , N800 have flash with Maemo_Dev_Platform_v3.1_armel- rootfs.jffs2. But ltrace can't work , same error as before. Sorry, I meant -fno-omit-frame-pointer, and your app has to be built with that, not ltrace. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Software categories
On Wed, Aug 15, 2007 at 07:12:13PM +0300, Ed Bartosh wrote: On Wed, 2007-08-15 at 18:59 +0300, Daniel Stone wrote: On Wed, Aug 15, 2007 at 06:55:54PM +0300, ext Ed Bartosh wrote: Thank you for the info, will look at it. Does it mean that we have to install sid if we want to use this? Hmm... No, the functionality's been present for about six or seven years or so, so it should be okay. Just read dpkg-scanpackages manpage. Format of override file contains package name. Does it mean that repository maintainer have to put every package there in order to override section? Well, if you're using dpkg-scanpackages or apt-ftparchive, then the long-winded answer is that you're currently using /dev/null as an override file (that second argument), so it already allows incomplete override files. The short-winded answer is, no. (But this is trivially established by experiment.) It doesn't mean that we can't use bright new Debian approach in future, but now people already using this one. Right. It's not about having an instant 100% solution that magically fixes every package, but means that any package imported from Debian in future doesn't have to be forked, which seems like a win to me. Well, as far as I know only top level application packages are required to have 'User' in section, but most of them are forked anyway, because they use hildon libraries. Rest of packages could be taken as is if Debian would have armel architecture supported. So, what's the issue we're trying to solve? My assertion -- and I take this is axiomatic -- is that every change we have to make that can be trivially eliminated, should. It means less work for initial packaging (and, hopefully, people get the idea that Debian exists and works just fine: no more 'look, I ported mutt', which contains a tarball with ./configure make having been run, on Planet Maemo), less work for ongoing maintenance and merges, less work for Debian to get our changes, and one less thing to forget when you're trying to make your package work with Maemo. signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GAUDEC 2007 Presentations?
On Thu, Aug 09, 2007 at 11:04:34PM +0100, ext Neil MacLeod wrote: I've seen several blog postings recently (such as this one by Carlos[1]) which reference GUADEC presentations (eg. Tko's Maemo and gtk+: Past, present and future[2]) and I'd like to view the presentations/slides that were given (if they are available). A whole bunch of Maemo and Nokia related presentations were given at this years GUADEC, is it possible for them to be hosted centrally on maemo.org for us all to view? Sadly we're all not able to attend GUADEC and miss out on these presentations which are no doubt interesting and informative. I have no slides from my X/GTK+ workshop, because it was just the 3 X guys and some GTK hackers sitting around, chatting about what we need to do on both sides. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Now *that*'s what I call a changelog...
On Fri, Aug 10, 2007 at 01:25:45PM +0100, ext Andrew Flegg wrote: With all the recent discussion about release notes and changelogs, *this* is what I like to see in a changelog: http://browser.garage.maemo.org/news/4/ Congratulations to timeless for putting the effort into the release notes for the new version of microb: I can already see a number of things which are worth the upgrade. Except for the categorisation (and HTML format, instead of text), what you then want is essentially /usr/share/doc/*/changelog.Debian.gz. signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: 3.2007.10-7 - Detailed change log?
On Mon, Aug 06, 2007 at 12:21:24PM +0200, ext Koen Kooi wrote: Makes me sad when nokia (employees) don't tell us enough and then try guilting us into shutting up with statements like the above. Hi, It's pretty easy to just see Nokia as a nameless, faceless corporation responsible for all the world's evils. But please remember that, on maemo-developers, you're talking to people (often free software developers in their own time[0]). You can try to pin every single failing of Nokia, or a couple-of-hundred-person organisation within Nokia, on them, but after a while, we'll probably just give up and go back to lurking. I'm not responding to this thread, because every time I do, I end up feeling like every single shortcoming of Maemo is on my shoulders, and quite honestly, I can't be arsed with that. Cheers, Daniel, free software developer paying food and rent through his job [0]: On this list, you have active developers from Debian, the Linux kernel, and X.Org to name but a few. Between us, we've maintained dpkg, X, DirectFB, KDE, GNU/Hurd, GNU/kFreeBSD and many others, in both Debian and Ubuntu. signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: 3.2007.10-7 - Detailed change log?
On Fri, Aug 03, 2007 at 06:19:40PM +0100, ext Neil MacLeod wrote: Let's face it, the existence of two bug tracking systems (one internal and one public) isn't helping matters This is a basic requirement of corporate security, for reasons I assumed were obvious, but given that they apparently aren't: having non-public information in the same BTS as the public one opens it wide up for abuse if a hole is found in Bugzilla, e.g. This is not acceptable. nor is the repeated promises that the situation will improve when there is little evidence of this happening - there is precious little Nokia involvement in the public Bugzilla, bug #1204 being a prime example. As has been noted repeatedly in public, our SD/MMC guy is on holiday (continental Europe has this one month of holiday in summer thing), so there's not a lot a lot we can do until he gets back. There is no more information about this in private than in public. So that's a pretty terrible example. Why is it not possible to use the public bugzilla to track the majority of the bugs? I'm sure your internal system is tracking bugs that we also eventually find, but why do we have to double up on bug detection and reporting duties? Because of reasons of security I've explained above. A decision was made (for better or worse) to launch the N800 immediately as it was sold. Now imagine that we had the same Bugzilla, and back in January 2006, someone used one of the Bugzilla vulnerabilities (of which there have been a few) to access private bugs, which dealt with the N800. Wouldn't really work so well. Changelogs though are fundamental, and I don't really care for Nokia bureaucracy or inefficiency. I realise that's not your fault, and I'm sorry to say that it's this Nokia bureaucracy that is going to kill the Nokia Internet Tablet project as developers move on to other projects where they don't have to bang their heads against these kind of brick walls. I'm glad to hear that you don't really care for it (you're hardly the only one), but however you word it, the procedures and rules exist, and we all have to deal with them. Ranting at the developers who take their time out to try to get involved in maemo-developers@ will hardly help this, since it's not like we can change it. But maybe that's just me. Cheers, Daniel, but a cog signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: 3.2007.10-7 - Detailed change log?
On Fri, Aug 03, 2007 at 06:32:07PM +0300, Eero Tamminen wrote: Please check what's available; kernel and X git repositories you should find with Google Actually, you can't find the X git repository. This is partially because I can't publish the one I use for actual development, as it contains a few things which cannot be made public, but the reason I haven't made a user repository on freedesktop.org with the Maemo changes is just because I'm crap and disorganised, rather than any deliberate Nokia conspiracy to keep people from finding the precious changes. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: 3.2007.10-7 - Detailed change log?
On Thu, Aug 02, 2007 at 02:05:31AM -0700, ext Andy Mulhearn wrote: On Thursday, August 02, 2007, at 09:56AM, Eero Tamminen [EMAIL PROTECTED] wrote: We certainly know what we've fixed, but the issue is that there's no reasonable way to know what part of that is relevant to you. Well publish the whole list then. Surely it can't be that hard? The whole list includes not only internal codenames etc which can't be published, but details of proprietary components. So it's not just a matter of dumping the BTS, it still requires someone to go through and make the changelog (which we should have anyway). For example I don't think you would be interested about a list of a few hundred localization issues (missing localization, typos etc) found by the localization testing while a new release is being developed, especially as none of these issues is in any release you can install to your device. They are not in the latest public release where they are fixed nor in the previous one which didn't have them. When the fixes were checked into your source repository, did you detail every single change made or the headline? 'your source repository'. Do you mean the Application Framework SVN repository, the Complementary Applications SVN repository, my X server git repository, the kernel git repository, ... ? Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sbox2 maemo
On Tue, Jul 31, 2007 at 11:56:12AM +0300, ext Marius Vollmer wrote: Then there would be a way for the user to select whether or not to make /usr/bin/perl be the armel or i386 version. I know this sounds like a trite reply, but I have actually read your entire mail. However: Sounds like you want multiarch. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Public maemo repository
On Mon, Jul 30, 2007 at 02:03:53PM +0200, ext Kees Jongenburger wrote: On 7/30/07, Daniel Stone [EMAIL PROTECTED] wrote: On Fri, Jul 27, 2007 at 09:14:09PM +0200, ext Kees Jongenburger wrote: What kind of step does a user have to take between creating it's own package and the sbuild/buildd/debuild aproach? isn't this hole open-source thingy about giving power to the user? It depends entirely on the tools. You could easily construct an improved dh_make that required no editing of any files at all. It has nothing to do with the packaging system itself, as cdbs's three-line debian/rules files have shown. I am really not trying to be annoying or anything I really am trying to understand. From my point of view as user as you call them has no access to the sbuild/buildd/debuild system, they get an sdk and that's it, Creating an improved dh_make , recompiling the package to use the thumb instruction set or not, are simply not part of the things that can be done (or am i missing the big picture?) Sorry, I completely misread your question. As for the build part, again, this is just a question of tools, and not a fundamental limitation of the packaging system. Something like pbuilder almost certainly does what you want. (That our SDK could certainly be improved is a separate issue as to whether we should use OE/BitBake or Debian packages.) If you are using dh_make you are not using the power of the existing debian packages and you are in trouble Who was saying this? Using dh_make is fine. If you want your packages to be good, then you should clean up the template a bit, yes. I guess it's fine as long as it's you own software you are packaging. I understand that one must put some effort in packaging. I was referring to the missing libs like some sdl packages or sqlite3 etc. I you run dh_make on those your a in trouble since different packagers will give the libs different names/options. Again am i missing the big picture or how do I get sqlite3 in maemo? Usually, you just take the sqlite Debian package, and build it in a Maemo SDK. Again, the problem you mention is completely independent of the build system: I could create a BitBake package called 'sqlite' and you create one called 'sqlite3', and we have exactly the same problem in another packaging system. if you don't use dh_make and try to use upstream packages + patches you are in trouble because you are creating the chaos youself, You are also prooving that the initial source packaging was not sufficient for your need I don't see what you mean here? This is again about the differences between maemo .deb packages and mainstream packages they are not the same and maemo as community does not provide a place to upload those changes/patches. When nokia chooses to create a new distro people are constantly trying binnay packages of exiting app that where ported earlyer in the hope it sill works. IMHO not an optimal solution Yes, again, we could've done a lot better on the SDK/distro side of things, but this is also a separate problem from the packaging system. Most Debian packages won't work (unless you use the new armel port), because we use EABI and Debian's arm port doesn't -- mismatching toolchains generate incompatible binaries. We should be a great deal better at giving back to Debian in general, and working to develop better-integrated support for cut-down systems (embedded and consumer devices), so you can take packages straight from Debian and build them with no changes (as opposed to the Emdebian approach). But we haven't been, and that -- like the others -- is another problem with the approach we've been using, not our packaging system. I think there is a big difference between those systems. Me as developer ,I have the same tools as you the packager (as I tend to call people who create packages) bsd ports,gentoo portage and oe contain meta packages. lets' face it what good did the packaging bring maemo until now? I don't understand I am still waisting my time with this packaging issue. The possibly to derive from an existing system, not having to invent our own packages or tools to solve problems that have already been taken care of long ago? :P I understand but just try to be on my side for a few minutes. I am experiencing the complexity of the debian packaging with the tweaks required for the maemo platform. I was not born as debian developer. I really did not care about repositories, free non-free stable unstable . I did not care about arch, I did not ask for dh_make. dpkg-xxx. All I really want is to be able to share software, and improve existing software for the arm platform (like sdl). The current packaging does not make it easy to do either. I hope that this will improve in the future. just having a public maemo repository is not enough. % dh_make % debuild -us -uc (or, if you have a broken Scratchbox: dpkg
Re: hildon dependency on modified gtk+ (was: sbox2 maemo)
On Thu, Jul 26, 2007 at 06:59:06PM +0300, ext Xan wrote: On 7/26/07, Loïc Minier [EMAIL PROTECTED] wrote: On Thu, Jul 26, 2007, Loïc Minier wrote: Would be nice if someone could add a #ifdef GDK_CLOSE_ALL_AVAILABLE etc. :) Updating my own question: this function is within #ifdef MAEMO_CHANGES; does that mean that if we start pulling some maemo changes into Gtk to build hildon (such as the filechooser API which was mentionned in the thread), then we need the full patch? The issue here is: the pc file for hildon-1 hardcodes MAEMO_CHANGES to 1, so anything you build on top of it will get that define. This wan fine by the time we did it (if you use hildon you surely want all the stuff and certainly you are using our gtk version), but now that we aim to be an upstream project it is no longer acceptable. At the very least we should add the MAEMO_CHANGES to the pc file only if hildon-1 is compiled against our gtk. More rational configuration management is badly needed here. Why not replace MAEMO_CHANGES altogether with a series of more sensible tests, e.g. 'do I have close_all_available', not 'am I running on Maemo?'. Platform tests suck; feature tests are the way forward. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Public maemo repository
On Fri, Jul 27, 2007 at 11:36:55AM -0300, ext Rodrigo Vivi wrote: I'll call by end user those developers that use the distro/SDK to develop their programs and by developer those that are coding the distro/SDK itself. OE makes developer's life easier because under OE repository there are a lot of package descriptions and tasks definitions that bitbake (that is a task executor) uses to build what you tell to build. Bitbake is too flexible. Er, how is this different from Debian, where you have a number of package descriptions and task definitions that sbuild/buildd/debuild uses to build? (Bearing in mind that debian/rules is a Makefile, and thus infinitely flexible.) OE makes the end user's life easier just when his program is ready to be packed. Instead of create a debian control dir, with a lot of complex files and rules, you just need to add a .bb file with few lines of description and use the bitbake to cross-compile, test and pack it. debian/ can be rather verbose, but most users won't need to change much from the dh_make template. I'm not telling that dpkg-buildpackage approach is bad and I know that emdebian team is doing a good work to adapt it to cross compiling. Actually, emdebian is fundamentally the wrong approach, and makes everything far worse than it could possibly be with any other technique. It's almost the worst thing I can think of. What I want to avoid is the creation of debian controls files that I believe that is to painful. Some Months ago Koen said me a truth: Hackers like to code and don't want to spend their time packing Sounds like a recipe for crap packages to me (maybe OE's are good, I don't actually know). If you want incredibly basic skeleton packages, just use the dh_make template and ignore them, and the packages won't be any good. If you want to fix them up so they conform to policy, are more generally useful, are split as they should be, etc, then you'll need to spend time on your packages. This is no different from ebuilds, spec files, or any packaging system I've ever used. The only difference is that debian/ tends to be a little more verbose for the skeleton case. But the core is the same: if you want crap packages, then you can easily create them in any packaging system. If you want good packages, then you need to spend a bit more time. Cheers, Daniel (a developer who is trying his best to ignore packaging now) signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Mozilla based browser + brief GUADEC recap
On Tue, Jul 17, 2007 at 11:49:45PM +0200, ext Hanno Zulla wrote: Just out of curiousity: Is there any word out on why Nokia chose Mozilla over Webcore this time? http://www.osnews.com/story.php/12965/An-Overview-of-Nokias-KHTMLWebCore-based-S60-Browser/ Hi, I wasn't involved in the decision-making, but S60's browser development is completely separate to ours, so that wouldn't have been much of an influencing factor. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: [maemo-users] 'Locking down' software installation
On Thu, Jul 12, 2007 at 12:03:39PM -0500, ext Paul Klapperich wrote: On 2/15/07, Levi Bard [EMAIL PROTECTED] wrote: On 2/15/07, Marius Vollmer [EMAIL PROTECTED] wrote: In the future, we hope to be able to provide official updates to the operating system itself via packages, and we need to give the end-users the confidence that when they intend to install a Nokia provided operating system update, they actually get what they think they are getting. Great! It'll be great to escape the backup-flash-restore-reinstall cycle! So, is this included in the IT OS 2007 Edition version 4.2007.26-8? It isn't, no. Will future updates be in place and not require a full flash? With any luck, yes. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Trouble setting up Scratchbox
On Tue, Jul 10, 2007 at 10:25:46PM +0300, ext Kalle Vahlman wrote: 2007/7/10, David Levine [EMAIL PROTECTED]: 2. Scratchbox uses chroot which can really confuse your view of the world! When you're inside scratchbox, you'll see a /home directory, but that (on my system) is really at /scratchbox/users/me/home .. I've not yet discovered a way out of the scratchbox environment (to see my real files). It would go around the point of chroot if you trivially could :) There are couple of mounts from the real system there though, most notably /tmp, /dev and /proc, but usually it's just simpler to copy into the scratchbox home dir what you need instead of hacking the other way round (Scratchbox is a maze of symbolic links, you get lost very quickly when trying to do funny stuff ;). Or: sudo mount --bind /home /scratchbox/users/$(whoami)/home But mind when anything tries to rm -rf /scratchbox, it'll take out your home directory too, so be careful. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Firmware 4.2007.26-8 has inferior SDHC performance than 3.2007.10-7 - why?
On Sun, Jul 08, 2007 at 12:58:43AM +0100, ext Neil MacLeod wrote: Can anyone from explain why the performance of SDHC cards is reduced when compared with the performance of the patches made available for the 3.2007.10-7 firmware? The new firmware achieves only 50% of the read performance possible with the old patched kernel (5.6MB/s when 11.99Mb/s is possible). I opened bug 1426[1] as an RFE for SDHC support and posted this question there as a comment (with timings before/after) but as this bug is now officially resolved I'm not sure anyone will read it, hence my reason for posting here. I'd be grateful if someone can comment against the bug with details explaining the need for the reduced performance. Hi, Depends which sort of card you're using. IIRC, some cards had problems running at a higher frequency, so they have to fall back to lower speeds. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Firmware 4.2007.26-8 has inferior SDHC performance than 3.2007.10-7 - why?
On Sun, Jul 08, 2007 at 01:25:01AM +0100, ext Neil MacLeod wrote: Daniel Stone wrote: Depends which sort of card you're using. IIRC, some cards had problems running at a higher frequency, so they have to fall back to lower speeds. Hi Daniel - same card before and after. The only thing that has changed is the SDHC support. The kernel has also had other changes, which IIRC include blacklisting some cards, so if you could list exactly which card you're using in the bug report, that would help. (Some cards were believed to run okay at higher speeds, but would show up data corruption et al.) signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Eclipse the IDEs
On Fri, Jun 29, 2007 at 03:50:43PM +0300, ext Arto Karppinen wrote: Kate Alhola wrote: There just happens to be many that prefer eclipse and when there is large commercial developers using it, it needs to be supported. It just happens to be a tool chosen by Nokia for Symbian development. So which one is it? The tool preferred by developers or the tool chosen by Nokia. This is actually the whole point of this thread in the end. Do developers use Eclipse because they want to, or because they have to? If developers use Eclipse because they want to, then your point about Eclipse Maemo is valid. A lot of people use Eclipse for the same I reason I use (and refuse to be parted from) vim and zsh: they like it. This discussion isn't really going anywhere. signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: 3d chipset...
On Fri, Jun 29, 2007 at 03:44:12PM +0200, ext Guard][an wrote: i'm sure someone else will be able to enlighten you better than i do but from what i can recall, it's not only a matter of providing a driver and enabling the device. there are bus and memory bandwidth considerations that somehow make the use of the 3d chipset useless on the current hardware Useless, no. Less useful than you'd think, yes. signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: 3d chipset...
On Fri, Jun 29, 2007 at 11:42:13AM -0400, ext Jesse Guardiani wrote: smooth scrolling This is a bandwidth issue. It would be nice to use with game emulators too. snes9x, xmame, etc I don't recall arcade games from the late 80's using too much 3D power. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: 3d chipset...
On Fri, Jun 29, 2007 at 11:53:32AM -0400, ext Jesse Guardiani wrote: It looks like the real issue is that the PowerVR folks haven't released a linux 2.6 driver for the chip (and reading their web page, they don't intend to). That sucks. If Nokia can't lean on PowerVR to get a 3D driver for 2.6 out of them, then I think Nokia should consider a different chipset for the n800's successor. I think 3D support is a major needed feature these days. It would also open up the door for serious gaming on the n800, and that can't be a bad thing for sales... Hi, If you dredge up past threads here, you'll see that it's not a discrete chipset, but comes as part of the TI OMAP package. That means it's not as clear-cut as saying, 'right, no open driver from you; next vendor', but it has to be considered as part of the entire package. As for the 3D support, yes, we know about it, and it's something we're interested in too, and have been for a while. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New release of Python2.5 for Maemo (r0.4-11)
On Thu, Jun 28, 2007 at 05:55:03AM -0400, ext Jason Monroe Martin wrote: There are a lot of good C developers on this list that know the C APIs and they helped me a great deal. I hope Nokia realizes Python is what makes the device for the average user, especially in a business enviroment where you need something developed quickly. Not to disparage the goal of full Python support or anything, but I daresay the average user buys the tablets for their web browsing ability et al, not for the opportunity to open up an xterm and start hacking Python. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New release of Python2.5 for Maemo (r0.4-11)
On Thu, Jun 28, 2007 at 01:54:52PM +0200, ext Antonio Orlando wrote: There are shadings, not just white and black. When the average user, not a C litterate, has some logic mind and easy ways to sit down and make that useful idea get shape on the device, without having to study fulltime for months and become a real coder for that, that sparkle in mind can happen and he/she really sits down. I have my mother in mind, who isn't even going to subscribe to maemo-developers, let alone even consider writing code. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New release of Python2.5 for Maemo (r0.4-11)
On Thu, Jun 28, 2007 at 09:13:28AM -0300, ext MoRpHeUz wrote: I have my mother in mind, who isn't even going to subscribe to maemo-developers, let alone even consider writing code. For sure, but a device is not made only by end-users. So, if developers are asking to have python on the device, so they can develop their stuff, fair enough right ? Otherwise you would be saying: no, if you want to develop anything for the device, it must be in C.. why would be that ? Please read the first few words of my first post, where I say 'Not to disparage the goal of full Python support'. Because I really would like to see full Python support there. I was just pointing out that the device is sold to a far wider audience: I suspect more people have bought it from Nokia shops and the like (one of the main telcos advertises it in newspapers here), than people from maemo-developers. That's all. End users aren't hackers. (If it was, we'd probably be shipping Sawfish.) Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Check existance of hildon header files
On Tue, Jun 26, 2007 at 02:53:44PM +0200, ext Murray Cumming wrote: On Mon, 2007-06-25 at 19:13 -0700, Ngurah wrote: Last night i trying to make some configure.in script on scratchbox.Basically i need to define when to use hildon and when to only use gtk , so in my configure.in i include this line : AC_CHECK_HEADERS([hildon-widgets/hildon-program.h],[have_hildon=yes],[have_hildon=no]) if test x$have_hildon = xyes; then You might need to use == instead of =. No, that's a bashism. signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Xephyr
On Tue, Jun 26, 2007 at 10:02:32AM -0300, ext Marcelo Lira wrote: Xephyr is part of the xserver source tree[1], and you have to download and compile all to use Xephyr. Checkout from http://cvs.freedesktop.org/xserver [1] Specifically here: http://webcvs.freedesktop.org/xserver/xserver/hw/kdrive/ephyr/ Please god no! That's ancient code. You want: git://anongit.freedesktop.org/git/xorg/xserver and xserver/hw/kdrive/ephyr within that. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Xephyr crash with segmentation fault
On Mon, Jun 18, 2007 at 10:31:23AM +0300, ext Eero Tamminen wrote: Please file a bug against your distribution that their Xephyr version is buggy and crashes. I've used some Xephyr versions and although older and latest versions work fine, there were in the meanwhile some versions that crashed. (I think they took different number of arguments to mmx and non-mmx composite fuction. AFAIK it was fixed in Xorg GIT in December.) Nope, that was just me being dumb: that patch never got merged upstream, as it needs some more work. (It turned into a few-thousand-line monster that changed the API to all video drivers.) Regardless, something's wrong with your Xephyr. I use the one from git both for our internal work, and personally at home, and it works fine. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Identifying platform in Python code
On Mon, Jun 04, 2007 at 09:49:39PM +0200, ext Frantisek Dufka wrote: Jeffrey Barish wrote: How do I determine in my code that I am running on the N800? Neither os.name nor sys.platform gets the job done. The former returns posix, the latter linux2, and I get the same strings when I run on Ubuntu. Check /etc/osso_software_version file. This is the firmware version. RX-34 on the beginning means N800. Of course this is not very portable and may fail in future but currently it work for both N770 and N800. If you're going to check the filesystem, hit up /proc/component_version. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: What's wrong with folder browsing?
On Sun, May 20, 2007 at 04:25:04PM +0200, ext Laurent GUERBY wrote: Folder approach is intuitive, shared by all reasonable apps on all platforms Except for more or less every media player ever made (cf. iTunes). signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: IT OS 2007 Hacker edition
On Thu, May 17, 2007 at 04:08:53PM +0200, ext Frantisek Dufka wrote: As for kernel few examples are - proper YUV420 support in framebuffer update ioctl, stock N770 kernel has this broken, fix is easy, would be useful for mplayer Sure, I have no problem with this; I guess the best way would be to list all the patches somewhere as part of a submission (e.g. on a wiki, not on the list). - HW rotation support in framebuffer update ioctl As I've said, this patch is conceptually broken. Fixing it so that it uses the stock standard fbdev API instead of rolling our own is possible for Hailstorm, at least, but I don't know about Tornado. I'd have to check. - maybe some things taken from newer N800 kernel, tearsync support would be nice as one example but this is currently not working for me, sadly I got no reply to http://maemo.org/pipermail/maemo-developers/2007-May/010156.html I'm not sure about this; guess we'd have to dig up the schematics to find out for sure. I guess getting wider testing would be the easiest way at this point. You might want to just port the whole omapfb back to .16, as there have been a ton of changes. I'll be on holiday more or less until the end of June, so if you've got anything about omapfb, X, or whatever, please CC me personally, so it lands in my inbox, and it won't just get lost in the flood of m-d mails. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: IT OS 2007 Hacker edition
On Thu, May 17, 2007 at 10:34:17PM +0200, ext Frantisek Dufka wrote: Daniel Stone wrote: On Thu, May 17, 2007 at 04:08:53PM +0200, ext Frantisek Dufka wrote: As for kernel few examples are - proper YUV420 support in framebuffer update ioctl, stock N770 kernel has this broken, fix is easy, would be useful for mplayer Sure, I have no problem with this; I guess the best way would be to list all the patches somewhere as part of a submission (e.g. on a wiki, not on the list). Ok, will attach to OS2007on700 tracker https://garage.maemo.org/tracker/?atid=683group_id=164 and send you a link. BTW I have also added waiting for yyc converter to yuv modes which is not there for N770 kernel with Tornado despite being documented in specs while N800 has the code when the very same bit of NDISP_CTRL_STATUS register tested there is documented as reserved and having default value 0 in my copy of S1D13745 specs (i.e no longer having yyc converter finished bit there). Thanks. I'm not at work at the moment (Ascension Day), so I can't check the specs. - HW rotation support in framebuffer update ioctl As I've said, this patch is conceptually broken. Fixing it so that it uses the stock standard fbdev API instead of rolling our own is possible for Hailstorm, at least, but I don't know about Tornado. I'd have to check. I'm not sure which patch you mean. Do you mean patch that could do this http://lemody.blogspot.com/2005/11/xrandr-o-2.html i.e. fullscreen 180 degree rotation transparent to rest of the system? This should perhaps be really hooked somehow to standard fbdev rotation API but I was thinking about something different. I was thinking about rotation of specific updated rectangle/square i.e. conceptually same thing like turning on pixel doubling flag for specific rectangle update or choosing different pixel color format for specific update. Such rotation feature could be useful and would IMO fit to same place in framebuffer code like the pixel doubling flag and is not related to fb rotation API. Or is there support for specific rectangle rotation while rest of framebuffer stays non-rotated? I guess not because even the manual update mode with rectangle updates is there because of having external video chip with own RAM which is not very common. dispc can't rotate specific regions: the rotate-on-update thing is tied to specific external controller features. As I've said, it's a bad idea because it encourages people to tie programs to the 770/N800 (assuming Hailstorm can rotate certain updates, which IIRC it can't). It's not something that's guaranteed to stay for the internet tablet series, let alone be portable to other devices. So yeah, I'd prefer to see something that just used the rotation API to rotate the whole screen, unless there's a compelling usecase for per-update rotation? We can hook xrandr up to the standard fbdev API, it's just a matter of getting around to it (it's on my TODO list). But anyway, does this mean that N770 kernel is still maintained inside Nokia so there is someone (you) who will accept patches? Of course I can submit it to linux-omap (and I probably will) but current omap tree is not very useful for us, mere mortals, who prefer initfs/rootfs with all its proprietary bits working. Not really. linux-oap is the best bet, and I'll add my Signed-off-by if it's good, but we can probably still feed patches to the ITOS2007 HE maintainer(s). I'm not sure about this; guess we'd have to dig up the schematics to find out for sure. I guess getting wider testing would be the easiest way at this point. You mean someone with different/newer N770 hardware? This would be interesting. I know there are two firmwares for wlan chips, newer N770 kernel supports two differnt LCD display panels and there is even code that suggests some devices have mmc slot capable of 4bit mode. Right. So is there someone in this list with newer HW build than 1602 (see /proc/component_version) who would share dmesg output of boot sequence and would be willing to test kernel and mplayer with tearsync feature? Good candidate is N770 device that loads 3826.arm wlan firmware on boot or have ls041y3 LCD panel (mine loads 3825.arm firmware and have lph8923 panel). There are no shipped 770s with the ls041y3, only the lph(whatever). You might want to just port the whole omapfb back to .16, as there have been a ton of changes. That's what I was trying to avoid. Are those features (framebuffer in SRAM, more planes) useful for N770 device? I guess not very much. Perhaps best for verifying that it is not my bug is booting 2.6.18 with custom rootfs instead. No, most of those features aren't really applicable to Tornado, I believe, but the internal API changed quite a bit, so it helps minimise the differences between the code I work with every day, and the code you work with every day. :) Cheers, Daniel signature.asc
Re: Xsp pixel-doubling solutions for Nokia 770?
On Thu, May 03, 2007 at 11:23:55AM -0700, ext Carl Worth wrote: 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: [spec snipped] 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? Yep, you are. 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 Sun, May 06, 2007 at 04:57:58PM +0300, ext Siarhei Siamashka wrote: On Thursday 03 May 2007 12:58, Eero Tamminen wrote: Yes, it just cannot be done safely / reliably. I can't be completely sure, but I think it is possible to do safely/reliably. At least it is worth trying in my opinion. The difference in our views is that you see xserver as the only valid Nokia 770 citizen and everything else looks like a very ugly hack to you. I see the problem from the completely different perspective. For many games xserver is irrelevant, they use SDL API and that is what they care about (xserver is just an additional extra layer). Game developers would like to have a fast and reliable SDL implementation which could make efficient use of all the hardware features that can benefit games. If xserver can provide all of this with some standard or nonstandard extensions, that's fine. We only need to estimate the amount of development resources and time needed to do these modifications to xserver and SDL to make use of these features. As games are not a primary target for Internet Tablets, I doubt that anything like this will be officially done any time soon (at least before the Nokia 770 end of life). Am I wrong? In this case tweaking SDL to use framebuffer directly may have a much lower cost. Especially considering that you have already solved this framebuffer sharing problem for DSP video playback. I did not suggest anything completely new ;) Hi, This is sort of my blanket reply to all the mails on the issue. There are two main issues here, of which the first is design. It's simple: we picked one window system, which happened to be X. We could've written our window system that simply performed arbitration for fb access, but we didn't, and for a pretty good reason. We chose X as a good abstract windowing system that solved all our problems. The framebuffer was an implementation detail, primarily based on the expertise available to us. The second, and most important, is portability. Not only are you tying your app to the internet tablets, but you're tying them to the _current generation_. We don't guarantee any APIs below X. If you want to hit the framebuffer, that's your choice, but I'm not going to guarantee that X won't be fiddling the framebuffer underneath you. It's not designed to play nice with other apps sharing the same framebuffer, and it won't be. Future releases of X may stomp the framebuffer more often. They may use acceleration, which you'll miss out on. They may not use the framebuffer at all, which will leave you high and dry. You're turning a portable app (hell, the point of SDL is portability, so you can run it anywhere), into one that's dependent on the mixture of X, an OMAP display controller supported by omapfb, and an external LCD controller also supported by omapfb. Not only is this setup quite unique to the internet tablets (due to the high resolution), but it's specific to this line of internet tablets. There are any number of changes we can make in future products (such as removing the LCD controller, moving to a purely X driver, using a different display setup, whatever) that will torpedo your app. I appreciate your zeal for faster-running games. There are certainly ways you can make it faster, but everything has an associated cost. You can bypass X and go straight to the framebuffer, but it might not work correctly, and that will be your problem. It's not guaranteed to be portable to future internet tablets, let alone other platforms. It won't even necessarily interoperate with things like dialog boxes and info popups. In short, you can do what you like, but you get to keep both pieces. 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 Thu, May 03, 2007 at 11:10:32PM +0300, ext Siarhei Siamashka wrote: On Thursday 03 May 2007 08:48, Siarhei Siamashka wrote: 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 :) Well, found what's the matter and added explanation at bugzilla: https://maemo.org/bugzilla/show_bug.cgi?id=1281 The workaround can be easily added to MPlayer, so that it will never call XvShmPutImage with top left image corner at an odd line. I'm going to release an updated MPlayer package (maybe even a bit later today), it is really fast on N800 with the optimized xserver :) Aha, that will indeed cause a fallback (x, y, width and height should all be aligned to 4px). 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?
(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: 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: 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: 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?
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: 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: 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 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: Xsp pixel-doubling solutions for Nokia 770?
On Mon, Apr 30, 2007 at 10:10:23AM +0300, ext Tapani Pälli wrote: ext Arnim Sauerbier wrote: Many of these are acceptably fast at 320x240 but too slow at 640x480 or 800x480. The problem is that some SDL applications do not maintain 2x doubling but flicker to 1x scaling - example video here: http://pupnik.de/UQM_Xsp_SDL_Doubling_Bugs.avi I could not watch this video, I guess I'm missing some codecs but I can also throw a another guess, very likely the application draws over 400x240 area. With 770 there is no clipping done for you and you have to take care to clip your drawing to 400x240 when using pixeldoubler. IIRC this is fixed for N800 (?) Yeah, it just ignores all drawing beyond 400x240 on the N800. Please note that pixeldoubler is very platform specific thing and for it to work you have to touch the code, there's no way around it. Also, it's not very 'official' feature for gaming (at least yet) so it's not very well supported. Hopefully we can build some safety around it in the future as it's very useful for gaming. Even if you take care of clipping, a system-modal dialog or infoprint popping from the UI can destroy the current view. I don't like it as it's far too ITOS-specific (I won't be satisfied until XSP no longer exists). It'll probably be replaced with RandR some time in the future, even if the fixed resolution choices are only 800x480 and 400x240. 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 Mon, Apr 30, 2007 at 10:23:37AM +0300, ext Eero Tamminen wrote: ext Tapani Pälli wrote: Please note that pixeldoubler is very platform specific thing and for it to work you have to touch the code, there's no way around it. Also, it's not very 'official' feature for gaming (at least yet) so it's not very well supported. Hopefully we can build some safety around it in the future as it's very useful for gaming. Even if you take care of clipping, a system-modal dialog or infoprint popping from the UI can destroy the current view. And if the game doesn't disable the double pixeling properly (e.g. if it crashes or freezes), user needs to reboot the device. Not very nice either... In theory, crashing should be perfectly safe on the N800. 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 Mon, Apr 30, 2007 at 09:34:38AM +0200, ext Frantisek Dufka wrote: Eero Tamminen wrote: And if the game doesn't disable the double pixeling properly (e.g. if it crashes or freezes), user needs to reboot the device. Not very nice either... So what happened to idea mentioned here year ago to modify Xsp (or whatever) API so that pixel doubling is flag of each display update separately? I.e. every update would be not pixel doubled unless told so by flag with each update. This is how it works on kernel framebuffer level anyway. You mean, modify every single drawing X request in the X protocol so it contains flags, meaning that we have to change every drawing-related function in -- on average -- ten (at least) places in the server codebase, rendering us incompatible with the standard X server codebase, as well as the X protocol? Plus, the update is done long after the drawing information has been discarded. IOW, no. (Also, bear clips in mind, which complicates things.) Daniel Stone wrote: I don't like it as it's far too ITOS-specific (I won't be satisfied until XSP no longer exists). It'll probably be replaced with RandR some time in the future, even if the fixed resolution choices are only 800x480 and 400x240. Pixel doubled resolutions would be nice and would be improvement over current situation indeed. What we will miss with this solution is having some parts of screen pixel doubled and some not like nice control area with nice static graphics and main pixel doubled game area. Sure, but that's mainly because pixel-doubling is a non-portable hack (doesn't exist in other products, doesn't exist on desktops, may not necessarily exist in future products). It's not a hack because of how it's implemented, but just by its very nature. 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 Mon, Apr 30, 2007 at 11:16:32AM +0300, Tapani Pälli wrote: Daniel Stone wrote: On Mon, Apr 30, 2007 at 09:34:38AM +0200, ext Frantisek Dufka wrote: You mean, modify every single drawing X request in the X protocol so it contains flags, meaning that we have to change every drawing-related function in -- on average -- ten (at least) places in the server codebase, rendering us incompatible with the standard X server codebase, as well as the X protocol? Plus, the update is done long after the drawing information has been discarded. IOW, no. (Also, bear clips in mind, which complicates things.) Well more likely something like this would be implemented as a additional flag in GC, right? But I think it would be nicer to just have a special call for 2x-blitting, this would be more sense. Sure, but the update is only done after the final screen pixmap has been retouched, by which time the GC is also long gone. Sure, but that's mainly because pixel-doubling is a non-portable hack (doesn't exist in other products, doesn't exist on desktops, may not necessarily exist in future products). It's not a hack because of how it's implemented, but just by its very nature. Hmm, I would not call a feature in HW a hack. It's just a feature of particular hardware which can be utilized. The entire concept is a hack around games not running quickly enough in full resolution. 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. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: creating new targets based on bora
On Mon, Apr 30, 2007 at 11:06:32AM +0300, ext Miko Nieminen wrote: It seems that when creating new targets based on bora you need to add those virtual packages afterwards. SDK install script does this behind scenes, but when creating new targets afterwards you need to create those by hand. I didn't found any existing scripts for this purposes so here is one, it's not pretty one, but does what it is supposed to do. It was modified from bora's install script. Why do you use ar and tar instead of dpkg --build? The former are not guaranteed to work: dpkg uses a certain defined set of ar functionality, whereas GNU ar has some extensions. So, a file generated with GNU ar is not guaranteed to be a valid Debian package. 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 Mon, Apr 30, 2007 at 11:26:29AM +0200, ext Frantisek Dufka wrote: Daniel Stone wrote: On Mon, Apr 30, 2007 at 09:34:38AM +0200, ext Frantisek Dufka wrote: You mean, modify every single drawing X request in the X protocol so it contains flags, meaning that we have to change every drawing-related function in -- on average -- ten (at least) places in the server codebase, rendering us incompatible with the standard X server codebase, as well as the X protocol? Well, what I meant is instead of having XSPSetPixelDoubling call in Xsp we would have XSPBlitRectangle with addition flags - i.e. something still non-standard but easier to use. If this cannot be done then it is bad luck. If hardware has useful feature which does not fit the design, using extension is not that bad. The initial drawing requests are long-forgotten, and we'd need some pretty extensive modification to all the internals to mark a particular region as being doubled. 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. We can do more or less arbitrary scaling, yes, but unfortunately with a few limitations (either we do it on the display controller and suffer the bandwidth hit, or do it on Hailstorm and suffer its horribly complicated semantics for dealing with overlays). 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? I don't know which division N-Gage is in. I can't speak for the product managers as to targeting market segments and all the other things they like to say. 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 Mon, Apr 30, 2007 at 02:26:37PM +0300, Eero Tamminen wrote: Hi, Daniel Stone wrote: On Mon, Apr 30, 2007 at 09:34:38AM +0200, ext Frantisek Dufka wrote: You mean, modify every single drawing X request in the X protocol so it contains flags, meaning that we have to change every drawing-related function in -- on average -- ten (at least) places in the server codebase, rendering us incompatible with the standard X server codebase, as well as the X protocol? Plus, the update is done long after the drawing information has been discarded. Yes, this would imply that the flag is propagated to the FB update structs (i.e. minor implementation detail compared to adding it to GC which is part of the standard X API :-)). The point is that, as it stands, the GC has no bearing on it. All drawing is done to the main screen pixmap. A timer runs to check the damage on the pixmap, and flush the affected areas: i.e. it's not strictly connected to the rendering callchain, but runs as a side-effect thereof. Sure, but that's mainly because pixel-doubling is a non-portable hack (doesn't exist in other products, doesn't exist on desktops, may not necessarily exist in future products). It's not a hack because of how it's implemented, but just by its very nature. Hmm, I would not call a feature in HW a hack. It's just a feature of particular hardware which can be utilized. Nothing says that the *API* should be limited to 2x. That's an implementation limitation, you don't need to design an API around the limitation. Hence, XRandR. The only thing worse than designing a bad API, is designing _another_ API. The entire concept is a hack around games not running quickly enough in full resolution. 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. Well, this is broken on the desktop too. There are also Desktop programs (games) which change screen resolution and when they for some reason freeze and I need to kill them, the screen is left in wrong size. It should be possible for these X clients to state that the new resolution is kept only while the client is connected and once it disconnects, the normal (default) resolution is restored. And this should be the default I think (it's easier to change settings programs to have permanent flag than change all programs using resolution changing). If you can come up with a policy that works in corner cases, you're a genius. signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 Video playback
Hi,
On Mon, Apr 30, 2007 at 02:27:49PM +0300, ext Siarhei Siamashka wrote:
On Friday 27 April 2007 04:43, Daniel Stone wrote:
I don't think Tornado supports YUV420, but I can check in the specs
tomorrow. My better C version basically does two macroblocks at a time,
ensuring all 32-bit writes (which _really_ helps over 16-bit writes,
believe me). This eliminates the branch, since your surface is
guaranteed to be word-aligned, so if you do all 32-bit writes, you can
just drop the branch as you know every write will be aligned.
This will be really fast.
Optimized YV12 - YUV420 convertor is done. The sources can be found here:
https://garage.maemo.org/plugins/scmsvn/viewcvs.php/trunk/libswscale_nokia770/?root=mplayer
Take a look at 'arm_colorconv.h' and 'arm_colorconv.S' files. Also there is a
test program ('test_colorconv') which can ensure that everything works
correctly and fast:
~ $ ./test_colorconv
[results follow]
ARMv6 optimized YV12-YUV420 convertor is about 2.5x faster
than current code used in N800 xserver. So it should provide a nice
improvement for video :)
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.
I doubt that your better C version can beat it or even get any close.
Of course not.
There are two important optimizations in this code:
1. Cache prefetch with PLD instruction (added in '_armv5' version) which
boosts performance to 70 megapixels per second. Inner loop is unrolled
to process 32 pixels per iteration (cache line size is 32 bytes on ARM, so
such unrolling is convenient). This is the most important improvement.
You can try using __builtin_prefetch() from C code to do the same
optimization.
Ah, sounds useful. From what Dan Amelang's been saying on xorg@, gcc
should coalesce four 32-bit reads into one 128-bit read, but this sounds
promising as well.
2. The use of ARMv6 instruction REV16 to do bytes swapping for high and low
16-bit register parts, this optimization was added in '_armv6' version and
boosted performance even more to 85 megapixels per second. This
optimization is highly unlikely probably impossible for C version at all.
Sounds useful.
I was a bit wrong about YUV420 format in my previous post.
Suppose we have planar YV12 image with the following data.
Y plane: Y1 Y2 Y3 Y4 ...
U plane: U1 __ U2 __ ...
Normal YUV420 (according to pictures in Epson docs) would be the following:
U1 Y1 Y2 U2 Y3 Y4 ...
But appears (most likely because of 16-bit interface and some endian
differences between ARM and Epson chip) that each pair of bytes is
swapped and we actually get the following somewhat weird layout:
Y1 U1 U2 Y2 Y4 Y3 ...
Right, hence the comment in the code is correct. ;)
As for the other possible Xv optimizations. You mentioned that fallback code
is not important at all. But imagine 640x480 video playback in windowed
mode. Decoding it will require quite a lot of resources, but additionally
scaling it down using a slow fallback code will be a finishing blow. In
addition, a solution (fast JIT accelerated YV12-YUY2 scaler) for this
problem already exists. I can also modify this scaler to support
YV12-YUV420 scaling. An interesting thing here is that this scaler
could be also used by xserver to solve graphics bus bandwidth
issues. Imagine that we have some high resolution video with high
framerate which exceeds graphics bus capabilities. In this case
this video can be downscaled in software using JIT scaler to lower
resolution before sending data to LCD controller. What do you think?
IMO this is a policy issue, and X is 'mechanism, not policy'. If you
want to adapt the scaler, I'm more than happy to include it, but I'm not
about to start doing automatic scaling.
IOW, 'ask a stupid question, get a stupid answer'.
That's fine. Now I'm waiting for further instructions :) Should I try to
prepare a complete patch for xserver? I'm really interested in getting
this optimization into xserver as it would help to play high resolution
videos. If you have any extra questions about the code or anything
else (for example I wonder what free license would be appriopriate
for it), don't hesitate to contact me.
If you wanted to prepare a complete patch for the server, that would be
great, as I don't have time to get to it right now (trying to finish off
the merge with upstream, among others). As for the license, just the
standard MIT boilerplate in hw/kdrive/omap/* is fine, but replace Nokia
Corporation/Daniel Stone with Siarhei Siamaskha, obviously.
I did not try to build xserver sources yet as I did not have enough time
for that and xserver requires quite a number of build dependencies. Can
you share some tips and tricks about maemo
Re: recompiling x server
On Mon, Apr 30, 2007 at 06:13:48PM +0200, ext Frantisek Dufka wrote: Daniel Stone wrote: It's completely safe to upgrade from a deb if it's not broken. If you set up a standard Maemo build environment and run apt-get source xorg-server and apt-get build-dep xorg-server, it should work just fine, in theory. In reality in 2.2 arm target there are unmet dependencies for flex and quilt. Flex is available in scratchbox, quilt not. I have downloaded quilt sources from http://packages.debian.org/unstable/source/quilt It needs other stuff when building. With -d the build breaks on missing hevea. Luckily make install in quilt build directory installs quilt executable. Then x-server builds fine and produce debs. What is strange that /usr/bin/Xomap on device with latest IT2006 firmware has ~600kb but my executable in debian/xserver-xomap/usr/bin/Xomap has 1.2MB. When setting export DEB_BUILD_OPTIONS=thumb before build the result has ~900kb. Tried strip just to be sure and size did not change. What other options are needed to reproduce device size? hevea is only required for docs, so you can skip that bit. (But still, the repositories should be complete. Sigh.) Did the strip succeed? file should tell you whether or not it's stripped. Aside from that, I can't think of anything else, as I build in a Scratchbox target myself, and it seems to work okay. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Continuous reboot problem with the N770 hacker edition
On Fri, Apr 27, 2007 at 12:45:41PM +0300, Kimmo Hämäläinen wrote: On Fri, 2007-04-27 at 12:36 +0300, ext Kimmo Hämäläinen wrote: I don't see any big remaining problem here... Hey, now I remember what was the issue here! The problem was that if we restart stuff for crashed X server, then we cannot use dsmetool anymore to e.g. restart sapwood if it crashed (which is what happens now). So, we would need to lose these individual restarting magic (for clipboard, sapwood, matchbox, osso-connectivity-ui, hildon-input-methods, and hildon-desktop) in favor of the X server. That is, if you want to restart these processes after the X server crashed, it's possible, but then we would never know if clipboard, sapwood, matchbox, osso- connectivity-ui, HIM, or hildon-desktop crashed. The solution could be extending DSME's magical capabilities to support groups of processes that would all be restarted if something happens (X server crashes). Wasn't there a patch for this back in April or something? Anyway, I don't see why it's not possible to do both: when the process crashes, restart it, but when the X server crashes, restart the X server, give it a couple of seconds, then restart all the desktop processes. Indeed, this arguably happens automatically. They die when they lose the connection to the display, so when the X server's gone, you don't restart them immediately; you put them on a queue and traverse the queue when the server's accepting connections again. Unless I'm missing something? Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: LED API
On Fri, Apr 27, 2007 at 10:04:18AM +0200, ext [EMAIL PROTECTED] wrote: I would like to find a documentation about the LED on n800. This API it is documented? Standard kernel LED API. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Continuous reboot problem with the N770 hacker edition
On Thu, Apr 26, 2007 at 06:56:40PM +0300, ext Eero Tamminen wrote: Hi, I still think this watchdog thing is another legacy we have from Nokia as a phone company. It makes perfect sense for dumb phone. It makes less sense for computer. Yes when device locks up you need a way to reset it. That is why you have reset button on computer and also reset hole on every PDA. I know it is internet tablet not computer or PDA but also Nokia should know that *this is not a phone* ;-) Anything with a radio (of which has the N800 has two) gets a watchdog. Honestly, I don't think this is particularly insane. With reset hole one can reset device when (s)he wants. Watchdog may not make things worse when device locks up solid (i.e. kernel bug or feature) but rebooting device when some process dies of when things take too long can make more damage than benefit. I know this is hard to detect so my solution is to provide reset hole and do not try to guess. User probably can notice this situation and act accordingly. This is improved a bit in latest release. Most things are restartable and device is rebooted only if restarting them fails too many times in a row (Desktop, window manager etc). However, without X server or D-BUS you cannot use the device at all and all your UI processes exit automatically, so it doesn't make sense to try to keep the device up if those exit/crash. The sensible solution is to pull the desktop down and restart it along with the X server, instead of panicking and rebooting the device. Unfortunately, our init system (osso-af-init) is so horribly designed that it's almost impossible to do[0] without just blowing away our init system and starting again _from scratch_. Which is arguably what we should do, anyway. Cheers, Daniel [0]: I had an ndm for exactly this internally, but due to the init scripts being so incredibly broken both by horrible design and awful implementation, the init scripts always returned failure, even if they succeeded. Go figure. 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, Apr 24, 2007 at 09:46:52AM +0300, ext Siarhei Siamashka wrote: On Friday 20 April 2007 10:39, you wrote: There's one optimisation that could be done for the YUV420 conversion (the custom planar format that Hailstorm takes), which removes a branch, ensures 32-bit writes always (instead of one 32-bit and one 16-bit per pixel), and unrolls a loop by half. Might be interesting to see what effect this has, but I think it'll still be rather small. My main performance concern is exactly about this 'omapCopyPlanarDataYUV420' function. My experience from Nokia 770 video output code optimization shows that optimization effect can be really huge (it was 1.5x improvement on Nokia 770 for unscaled YV12 - YUY2 conversion going from a simple loop in C to optimized assembly code, I provided a link to the relevant code in my previous post). But N800 code can be probably improved more because now it contains unnecessary branch in the inner loop and branches are expensive on long pipeline CPUs. Such color format conversion performance should be comparable to that of memcpy if done right (it is about half memcpy speed on Nokia 770 for unscaled YV12 - YUY2 conversion). Right, the branch is a problem, and as I said, the branch can be avoided and the writes optimised to be three 32-bit writes for two macroblocks, instead of two 32-bit writes and two 16-bit writes. However, I don't think the lessons from the 770 are necessarily _directly_ applicable to the N800: on the 770, our bottleneck is decoding speed. The bottleneck on the N800 is exactly the opposite: video output. But only benchmarks can be a real proof, any premature speculations are useless and even harmful. Do you remember the times when nobody from Nokia believed that ARM core could be good for video decoding on 770? ;-) Actually, I don't, since I've always mainly worked on the N800. ;) But still, if there's dedicated hardware we can use to remove load from the ARM and let it get on with tasks, and it can perform to an adequate level, there's no reason to avoid it. So Nokia 770, having slower CPU, slower memory and using less efficient output format (16bpp vs. 12bpp), still requires less time for video output than N800 (7,998s vs. 12,365s). Graphics bus performance is unrelated here as it is asynchronous operation and it is fast enough. Surely N800 also has some extra overhead because of interprocess communication with xserver, but looks like YV12 - YUV420 conversion is quite a bottleneck here too. Bear in mind that, unless you explicitly disable it (the Xv attribute is something like XV_OMAP_VSYNC), the X server _will_ flush all pending writes before the next frame is put through. Else you get tearing, because you can be halfway through an update, and writing the next frame to the framebuffer, so which frame is being picked up, changes halfway through. Try forcing XV_OMAP_VSYNC (or whatever it is) to 0, and comparing the results. I can make an assembly optimized code for YV12 - YUV420 conversion. Is there any chance that such optimization could be also integrated into xserver in one of the next firmware updates if it really provides a significant performance improvement? Yeah, if there's measurable benefit, I'll include it. N800 is almost able to play VGA resolution videos properly, it only needs a bit more optimizations. Color format conversion performance for video output is one of the important things that can be improved. I don't believe it's on the critical path. The optimisation I mentioned before will bring us up to the point where any improvement that we can make in that conversion will be eclipsed by the time taken to send it over the bus, I believe. But I can't prove that. Which Epson docs? The one mentioned by Frantisek. Well, it was just a comment for 'omapCopyPlanarDataYUV420' function wrong and misleading, nevermind :-) Now everything is clear. Hmm, is it? Because, unless I was _really_ tired at the time I wrote it (which is entirely possible), that's what the code does, and it works, so ... Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: x11vnc -- problems solved
On Sat, Apr 21, 2007 at 09:55:46AM -0400, ext Acadia Secure Networks wrote: do you know what if any are the side effects of disabling the use of the pressure information on the N800 as a result of implementing your workaround? In other words does this break some other functionality of the N800, or is the pressure information something that is there as a latent feature but not actually used by the N800? It breaks finger vs. stylus detection, and might well break some apps that only use extended events, instead of core (like the TN). I don't have a great solution for this at the moment, except to suggest that x11vnc should emulate extended events as well if Xi = 1.4 is detected. 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
Hi, On Fri, Apr 20, 2007 at 09:41:45AM +0300, ext Siarhei Siamashka wrote: 1. Lockups which look like cycling two sequential frames, very similar or the same problem as https://maemo.org/bugzilla/show_bug.cgi?id=991 Also keypresses are not very responsive. A fix (or workaround) required changing XFlush to XSync in screen update code, now it looks a lot better. I assume this is basically just a race condition, and it doesn't trigger on other systems, because they're a lot quicker. 2. Switching windowed/fullscreen mode generally makes mplayer terminate with the following error messages: X11 error: BadValue (integer parameter out of range for operation) Xlib: unexpected async reply (sequence 0x5db)! A workaround to make this problem less frequent was a code addition which prevents screen updates until we get Expose even notification. Ditto. I really don't know much about X11 programming and only started to learning it, so your help with some advice may be very useful. I mainly lurk on the server side, however. Looks like MPlayer code X11/Xv output code is a big mess with many tricks and workarounds added to work on different systems over time. Maybe it contains some bugs which get triggered on N800 only, but apparently this code is used for other systems without any problems. Can you try experimenting a bit with MPlayer (upstream release) yourself to check how it works with N800 xserver? Maybe it can reveal some xserver bugs which need to be fixed? Also if MPlayer has some apparently bad X11 code, preparing a clean patch and submitting it upstream maybe a good idea. Unfortunately, I don't have the time to do this. Sorry. One more strange thing with Xv on N800 can be reproduced by trying to watch standard N800 demo video in MPlayer. It has an old familiar tearing line in the bottom part of the screen and the performance is very poor. The same file plays fine in the standard video player. The only difference is that mplayer respects video aspect ratio (this video is not precisely 15:9 but slightly off) and shows some small black bands above and below picture and default video player scales it to fit the whole screen. Disabling aspect ratio in mplayer with -noaspect option also 'fixes' this problem. Using benchmark option we get the following numbers: # mplayer -benchmark -quiet Nokia_N800.avi [...] BENCHMARKs: VC: 33,271s VO: 66,768s A: 0,490s Sys: 5,703s = 106,232s BENCHMARK%: VC: 31,3189% VO: 62,8517% A: 0,4614% Sys: 5,3681% = 100,% BENCHMARKn: disp: 1732 (16,30 fps) drop: 778 (30%) total: 2510 (23,63 fps) # mplayer -benchmark -quiet -noaspect Nokia_N800.avi [...] BENCHMARKs: VC: 32,226s VO: 14,350s A: 0,456s Sys: 55,699s = 102,731s BENCHMARK%: VC: 31,3694% VO: 13,9687% A: 0,4439% Sys: 54,2180% = 100,% BENCHMARKn: disp: 2501 (24,35 fps) drop: 0 (0%) total: 2501 (24,35 fps) So when showing video with proper aspect ratio, we get tearing back and more than 4x slowdown in video output code (66,768s vs. 14,350s). This all results in 30% of frames dropped. Okay, I'll take a look at this. My guess is that the scaling we're seeing prevents us from using the LCD controller's overlay, possibly because it's done in software. These were the 'usability' problems with Xv. Now we get to performance related issues. As YV12 is not natively supported by hardware, some color format conversion and bytes shuffling in video output code is unavoidable. It is a good idea to optimize this code if we need a good performance for high resolution video playback. Color format conversion can be optimized using assembly, for example maemo port of mplayer has a patch for assembly optimized yv12- yuy2 (yuv420p - yuyv422) nonscaled conversion which provides a very noticeable ~50% improvement on Nokia 770: https://garage.maemo.org/plugins/scmsvn/viewcvs.php?root=mplayerrev=129view=rev Also here is a JIT accelerated scaler for yv12- yuy2 (yuv420p - yuyv422) conversion, it is very fast and supports pixels interpolation (good for image quality) : https://garage.maemo.org/plugins/scmsvn/viewcvs.php/trunk/libswscale_nokia770/?root=mplayer The primary conversion we do isn't planar - packed (this is a fallback for when the video is obscured), but from planar to another custom planar format. It would be good to get ARM assembly for the fallback path, but most of the problem when using packed lies in having to transfer the much larger amount of data over the bus. There's one optimisation that could be done for the YUV420 conversion (the custom planar format that Hailstorm takes), which removes a branch, ensures 32-bit writes always (instead of one 32-bit and one 16-bit per pixel), and unrolls a loop by half. Might be interesting to see what effect this has, but I think it'll still be rather small. I have seen your code in xserver which does the same job for downscaling, but in nonoptimized C and with much higher impact on quality.
Re: Insmoding g_file_storage not working
On Thu, Apr 19, 2007 at 06:45:41PM -0400, ext Chris Taylor wrote: I created my own script to load usbnetworking (borrowed heavily from Michael Mlivoncic's script: http://maemo.org/maemowiki/UsbNetworking?highlight=%28CategoryHowToNetworking%29) had to redo some of this because for some reason I was getting USB driver timeouts on the N800 :( unfortunately insmoding g_file_storage.ko fails ... and modprobe -l returns nothing doesn't matter if I use Michael's script or my own and modprobe -l returns nothing regardless of state FWIW: I've got the N800 flashed with RX-34_2007SE_3.2007.10-7_PR_COMBINED_MR0_ARM.bin any ideas? The modules are in the initfs; chroot /mnt/initfs modprobe g_file_storage Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: No more 770 bug activity?
On Tue, Apr 17, 2007 at 06:18:16PM -0700, ext Ian wrote: If the vehicle gets bogged down anywhere or can't find its way, please Nokia send all returned 770's to Brazil. We [1] will use them. I have added a section: Implement a Coherent Recycling Strategy for all Nokia Maemo Devices. This is out of our (the people hacking on the Internet Tablets) hands: Nokia as a corporation has a global recycling strategy for all their products, which includes reuse of components and materials, sensitive disposal of that which cannot be reused or recycled, et al. Can probably be found on a Nokia site somewhere. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: disabling pressure information (for x11vnc)
On Wed, Apr 18, 2007 at 04:09:17PM +0100, ext Mike Cowlishaw wrote: It doesn't completely fix the problems though .. the other big problem is still there, in that in X-terminal pressing the enter key brings up the thumb keyboard and does not enter the data. One can achieve an Enter by clicking on the window (which brings up the stylus keyboard) and then on the Enter key there, but that's terribly inconvenient. Any suggestions? Use Enter on your numpad. This is a broken UI specification and apparently isn't going to be changed. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Compiling latest kernel (from kernel.org) in n800
On Tue, Apr 17, 2007 at 02:00:22PM -0300, ext Leandro Melo de Sales wrote: if I download the kernel from kernel.org, is it possible to compile it in my scratchbox and flash it into my n800? Not from kernel.org, but you can get one from the linux-omap tree and run make n800_defconfig. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Compiling latest kernel (from kernel.org) in n800
On Tue, Apr 17, 2007 at 05:00:38PM -0300, ext Leandro Melo de Sales wrote: Do you say, linux-omap tree of kernel.org, right? I'm getting the git version of the following tree: http://www.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git Is it right? Yeah, that's the one. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: closed stuff Re: 0xFFFF: GPL-licensed flasher for n770 and n800
On Fri, Apr 13, 2007 at 09:11:34AM +0200, ext Frantisek Dufka wrote: Daniel Stone wrote: On Thu, Apr 12, 2007 at 06:59:55PM -0700, ext Carl Worth wrote: What elements go into the Nokia fiasco image that cannot be built from Free source? The bootloaders (xloader, 2nd, secondary). And the initfs too. Without it it is hard to initialize wi-fi nad bt chips properly. Ah, I thought the initfs source was public. Apparently not. Kernel is free to modify too but (closed) wi-fi modules depend on it so you can't deviate too much. Well, only umac.ko, and Kalle has a public cx3110x project, so you should be able to rebuild it to run on whichever kernel you create? It looks like you also need to have bme running in your free solution for charging to work. This is true. At boot time you also need dsme but I guess/hope it can be killed once it does its job of letting initfs stuff work and you have replacement for the dsme part that keeps the HW watchdog happy. Killing it gives you control of display brightness and blanking. What dsme manages can be guessed from names of libraries in /mnt/initfs/usr/lib/dsme/ Indeed, most of DSME can be relatively trivially reimplemented. There are very few parts which require actual reverse-engineering; the main part, I'd imagine, would be the Retu RTC. The rest (e.g. display blanking) is already publicly documented. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list [EMAIL PROTECTED] https://maemo.org/mailman/listinfo/maemo-developers
Re: Excel on Nokia N800
On Fri, Apr 13, 2007 at 01:14:05PM +0200, ext magda chelly wrote: Please could someone tell me what should I download to read excel and word files on my N800, and the give me the appropriate link. Magda, This question is definitely nothing to do with Maemo development. Many of your questions are best answered by the FAQ on maemo.org, or a quick search on Google. (We can't do everything for you. At some point, people will just start ignoring your mails -- I can tell you for a fact that some already are -- and you'll find it difficult to get help when you have a legitimate question.) In the future, please pay us some basic kind of respect by at least trying Google first, and then, if you search around for a while and fail to find an answer, please use maemo-users instead of maemo-developers: very few of your questions to date have actually been about development of the Maemo platform. Lastly, if you don't get an answer (or an answer you like), do not repost basically the same question again. It's a basic respect thing. I hope that maemo-users and Google help you find the answer to your questions, but maemo-developers is not the forum you want. ___ maemo-developers mailing list [EMAIL PROTECTED] https://maemo.org/mailman/listinfo/maemo-developers
Re: H/W 3D on the N800
On Wed, Apr 11, 2007 at 12:11:00PM +0200, ext Johannes Eickhold wrote: On Tue, 2007-04-10 at 10:56 +0300, Amit Kucheria wrote: On Sat, 2007-04-07 at 07:49 +0200, ext Daniel Wagner wrote: Seems as if H/W 3D is not open source compatible. Probably since they licensed the 3D core from PowerVR... That is one reason indeed. Could you please provide more detailed info? Like which other reasons are there and how possible solutions could look like? I.e. is it possible at all to make H/W 3D open source compatible and how? Currently, there are only three chipsets available for embedded 3D use: the PowerVR MBX/SGX, the ATI Imageon, and a 3DLabs chipset. To the best of my knowledge, none of them have any open source driver. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Maemo documentation - feedback time is now
On Wed, Mar 28, 2007 at 05:16:36PM +0300, ext Marius Gedminas wrote: On Wed, Mar 28, 2007 at 03:52:18PM +0300, Daniel Stone wrote: Enable extended events in your GTK application, and ensure that axis 2 (i.e. the third axis) is set as PRESSURE (set_axis_use) or something, and now the PRESSURE field of every event will be valid. OTOH, I think GTK might already do this for you. Thanks. Here's some source code for that as well: http://groups.google.com/group/fbreader/msg/86fceebf61e5e358 It's from FBReader. That method distinguishes stylus taps from thumb presses in all Maemo versions that do i tin three different ways. There is one bit of guesswork there. What's the pressure value threshold used to detect thumb presses in the system by such controls as the thumb-aware menus? Hi, As Tuomas posted, there's a Hildon finger API which will tell you whether or not it's a finger press, hiding all the voodoo from you. If you just want a pure pressure value, then check the pressure field. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: 3.2007.10-7 - Detailed change log?
On Tue, Mar 27, 2007 at 10:22:25AM -0500, ext Paul Klapperich wrote: I think the ideal situation would be if the public bugzilla was used by Nokia when fixing bugs submitted publicly and the internal bugzilla used when fixing bugs Nokia feels need to be hidden from public view for whatever reason. Actually, ideally the public bugzilla was the only bug listing, but I know some components can't be open sourced. However, I believe bugzilla allows access controls to particular bugs. I seem to remember the Mozilla foundation marking bugs as private such that only the title of the bug was publicly viewable as they pertained to major security holes. Perhaps down the road something like this could be done? Or maybe some sort of automated import/export between the public and private bugzilla? Products don't exist before announcement by definition, so it's very difficult to work in an environment where most every bug must be secret by default (anything pertaining to particular unannounced features). There's also the matter of managing what to report to: there would need to be some kind of permissions per-product or so. I assume the reason the public bugzilla doesn't seem to get updated is that the bugs are actually worked on using the internal bug tracker and it's inconvenient to put the same messages in the internal and external tracker. You got it. The majority of the bug work happens before product release: going by what's in the changelogs, the external database has roughly 2% of the bugs as the internal one. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Developping an application using Netbeans and Scratchbox
On Mon, Mar 26, 2007 at 03:10:15PM +0200, ext magda chelly wrote: I'm preparing a project that must use libraries in C, but the main ^rpgram will be written in JAVA. Can anyone tell me how can I create an executable from Scratchbox that use Netbeans? Or something like this? Magda, This is a Java development question, rather than Maemo development. Please seek a more appropriate forum. Cheers, Daniel ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Error building maemopad package
On Sun, Mar 25, 2007 at 03:46:05PM +0100, ext Mike Cowlishaw wrote: Hi, I am working my way through the Maemo 3.0 tutorial, and everything was working as expected until I got to step 4 of the maemopad example. This 'dpkg-buildpackage -rfakeroot -b' appears to go well, but ends with: dh_link ln: creating symbolic link `debian/tmp/etc/others-menu/extra_applications/0112_maemopad.desktop' to `/usr/share/applications/hildon/maemopad.desktop': Operation not permitted dh_link: command returned error code 256 make: *** [binary-arch] Error 1 ... which is a bit of a show-stopper. Any ideas as to what might cause this? Are you working on a filesystem which doesn't allow symbolic links? signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Asking about running an executable on the device
On Fri, Mar 23, 2007 at 06:59:49PM +0200, ext Guillem Jover wrote:
On Fri, 2007-03-23 at 14:38:59 +0100, ext magda chelly wrote:
So, I developed a simple helloworld on scratchbox, and
when I copied it to the device it doesn't show this
file!! Had I to install special things on the N800 to
make that work?
Please take a loot at this:
http://www.catb.org/~esr/faqs/smart-questions.html
Magda,
I think what Guillem is suggesting in particular is that this might be
the wrong place to ask the question. maemo-developers is meant for
people developing applications for the Maemo platform who need help with
specific Maemo issues ('how do I get the remaining battery time', etc).
Your issues seem to be focussed around the basics of programming and
development, and are probably better suited to a local Linux Users
Group, or some kind of programming tutorial.
Good luck with your efforts.
Cheers,
Daniel
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
Re: SDK_ARMEL can not work with SDK_PC code?
On Fri, Mar 23, 2007 at 06:43:51PM +0100, ext Van Vu wrote: However, my code developed in SDK_PC can not be recompiled again in ARMEL. I did as following: My application package is img1-1.0.0 Inside Scratchbox, SDK_ARMEL, changing dir to: img1-1.0.0 Then issuing 2 commands: dh_make -e [EMAIL PROTECTED] dpkg-buildpackage -rfakeroot Still, the toolbox SDK_ARMEL simply refuses to produce the .deb file. Error message: /usr/bin/python2.4 is not an executable binary I guess that i need to configure something more. Because in the SDK_PC toolbox, i can run the command python2.4 but it is impossible in the SDK_ARMEL. It sounds like your ARMEL root is broken. Make sure you've selected qemu-arm as the emulation method, for example. 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, Mar 20, 2007 at 09:31:00AM +0100, ext Klaus Rotter wrote: Daniel Stone wrote: On Sun, Mar 18, 2007 at 07:57:36PM +0200, ext Siarhei Siamashka wrote: Looks like graphics bus on N800 is 3x slower than on Nokia 770. It might be caused by inefficient framebuffer driver implementation in its initial revision. But if it is a hardware issue, getting normal video playback at native framerate may be troublesome. [...] Unfortunately, it's a hardware issue. What we can do is get the LCD The memory bandwidth to the N800 LCD framebuffer is 3 times slower that the bandwidth in the N770? Is it really _that_ big? Siarhei's calculations were correct, so, yes. What is limiting the bandwidth: The OMAP interface, the LCD controller itself or was it a design issue. a) and c). It's just not stable at higher frequencies. 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, Mar 20, 2007 at 02:03:16PM +0100, ext Klaus Rotter wrote: Daniel Stone wrote: On Tue, Mar 20, 2007 at 09:31:00AM +0100, ext Klaus Rotter wrote: The memory bandwidth to the N800 LCD framebuffer is 3 times slower that the bandwidth in the N770? Is it really _that_ big? Siarhei's calculations were correct, so, yes. Bad... the N770 interface wasn't the fasted either. So we have even a more slow down. On the N770 there was the feature (with SDL games) of doubling the pixels by hardware with a X-server extension. Will this feature be available in the new kernel / X11 server for the N800? It would be great if it would use the same API. Yes, pixel doubling has been fixed, and still uses the XSP API for now. Future releases (long-term, as I haven't implemented this yet) will use the standard XRandR API. 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
Hi,
On Sun, Mar 18, 2007 at 07:57:36PM +0200, ext Siarhei Siamashka wrote:
If we look at the framebuffer API. There are two ioctl important for screen
updates and tearing synchronization if I understand them correctly now:
[...]
You do indeed understand them correctly.
Looks like graphics bus on N800 is 3x slower than on Nokia 770. It might
be caused by inefficient framebuffer driver implementation in its initial
revision. But if it is a hardware issue, getting normal video playback at
native framerate may be troublesome. Performing software downscaling of
video before sending data to the graphics chip may be a solution, but it
sacrifices image quality. Switching to 12bit YUV format from 16bit will save
~33% of bus bandwidth, but it can't compensate 3x performance regression
and may be not enough for 30 fps fullscreen video playback.
Unfortunately, it's a hardware issue. What we can do is get the LCD
controller to perform colourspace conversion from a custom planar format
('YUV420') and the scaling as well. Unfortunately this isn't a
colourkey, but only a simple rectangle, so the semantics are actually
quite complex. But it works well enough that we've shipped an X server
and kernel with this support. We've tried jacking the RFBI frequency up
a bit, and the most we could get was a ~10% improvement, with a loss in
stability: anything above that would kill your device quick smart,
whereas this one only crashed it every day or so.
As Daniel explained, the next firmware will bring a big improvement in this
area. I'm not sure whether it is worth to release the next version of MPlayer
before that, since it will still be far from perfect on N800.
I'd hold your breath, to be honest.
A preview of the next kernel for beta testing might reduce time needed to get
MPlayer fully working on N800, but I'm not demanding or expecting anything. It
is just a matter of time anyway and I'm not so impatient :)
Unfortunately, again, it's not my call: there are various processes to
get things released (legal, in particular), and I can't really pre-empt
those.
I would be grateful for any comments and corrections. Some things are not
yet clear to me, figuring them out myself is just a waste of time that could
be spent on something more useful. Even a small hint may save a huge
amount of time.
Anything in particular? I thought my last mails on the subject would've
been reasonably exhaustive.
PS. The last 'inefficient' period of time was when I was struggling with
gstreamer API (with no prior experience with it) to get MP3 playback in
MPlayer working on DSP for a few months. Looks like the history repeats.
Once again, I'm not demanding anything, it is just a matter of 'optimizing'
development and spending scarce amounts of spare time more efficiently.
I know that Nokia developers are too busy with their primary work, and
really appreciate what they are doing. So consider this as a polite request
for a favour (not necessary to fulfil right now or fulfil at all).
Again, if there are any particular questions I can answer, don't be
subtle: ask me straight up. If I can answer them (some things I can't
necessarily say, some things I don't necessarily know), I will.
Cheers,
Daniel
signature.asc
Description: Digital signature
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
Re: Gnome-Canvas-Maemo
On Fri, Mar 16, 2007 at 02:02:54PM +, ext Alma Prlja wrote: I have created an application using glade and python. I have some gnome widgets in my application, like gnome canvas and gnome fileEntry. When I try to run the application in maemo from the scratchbox it's not working with the gnome widgets. When I remove the gnome widgets it's working fine. Is there some way to get gnome to work with maemo??? I also use the shelve to save the files that can be created by the application and it is not working in maemo eighter. Do you have any idea how to solve this? The GNOME canvas (Goo canvas, I think?) is only present in later versions of GNOME. I think. I don't work on the GNOME side. I'm forwarding your message to maemo-developers, who might actually know something about it. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: sbox2 update
On Tue, Mar 13, 2007 at 11:24:01PM +0100, ext Laurent GUERBY wrote: The exe is present in arm-lltc/bin [EMAIL PROTECTED]:~/work/maemo$ ls -l /home/guerby/work/maemo/arm-lltc/bin/arm-none-linux-gnueabi-gcc -rwxr-xr-x 2 guerby guerby 128352 2007-03-11 17:18 /home/guerby/work/maemo/arm-lltc/bin/arm-none-linux-gnueabi-gcc Any idea why it is not looking in arm-lltc/bin/ , ie what I could have screwed up? :) in buildroot/sb2.config I have: SBOX_CROSS_GCC_DIR=/home/guerby/work/maemo/arm-lltc You have to append the /bin here; the name is a bit misleading. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xephyr trouble
On Mon, Mar 12, 2007 at 03:23:41PM +0200, ext Eero Tamminen wrote: Hi, ext Claudio Scordino wrote: So, how should I set the configuration in order to make Xephyr work with a unix socket ? I do just (outside Sbox): Xephyr :1 -nolisten tcp -host-cursor -screen 800x480x16 -dpi 96 -ac (-ac disables access control for the client connections and -nolisten tcp disables inet sockets so that only local clients can be used.) And in Sbox: export DISPLAY=:1 af-sb-init.sh start Doesn't this work? Only if /tmp is bind-mounted into Scratchbox, else how is it going to find the socket? Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: OMAP 2420 / lower level hardware docs?
On Sun, Mar 11, 2007 at 10:28:01AM -0400, ext Jon Smirl wrote: On 3/11/07, Klaus Rotter [EMAIL PROTECTED] wrote: Jeff Sauer wrote: Anyone have any links to specifics on the ARM CPU and other blocks of the OMAP 2420? AFAIK you get this information (at least the interesting stuff: e.g. 3D-hardware) only if a)you sign a NDA and b)if your company will order a significant number of devices. So, I think, Nokia has that information but can not release it to the public. I hope someone there will decide that a hardware supported OpenGL driver would be a big benefit for the N800. Using a closed CPU like the TI OMAP in an open device like the N800 wasn't the best pairing. Maybe next time Nokia will use a similar but open processor like the Freescale MX31. No, it makes absolutely no difference, because both the OMAP 2420 and the i.MX31 ship with the Imagination (think: PowerVR) MBX. Imagination are the ones who control the licensing of the driver and specifications, and it's still their decision. So even if the N800 was using the i.MX31, it would make absolutely no difference at all in terms of the MBX. signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Touchscreen right scrollbar area dead-pressure zone
On Sun, Mar 11, 2007 at 06:32:23PM +, ext Neil MacLeod wrote: Kon Wilms wrote: I was wondering if anyone could shed more light on the hardware issue regarding the dead pressure zone on the right side of some N800's. Mine has been gradually deteriorating to the point that I now have to apply a lot of force to the screen to get the right scroll bar to even move. More information here: http://www.internettablettalk.com/forums/showthread.php?t=4690 This seems to be a larger issue than just one or two units exhibiting the same type of defect. As mentioned in the ITT post, this topic has been discussed in this newsgroup[1] suggesting it is a known hardware fault and there is also a bugzilla entry[2], but with no comment from Nokia (how odd). Hi, I was talking about a differen tissue, where the top right-hand corner is insensitive in some devices. Not to the degree that you've suggested, and not degrading over time, but simply that sometimes you need to tap twice to close a window or something. So, different issues. (I don't know anything about the one you're talking about here.) Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: DVD content playback possible or not? Re: Wishlist (was:Re: N800 and USB host mode)
On Fri, Mar 09, 2007 at 09:45:03AM +0100, ext Hanno Zulla wrote: Right now, the biggest bottleneck in video decoding is RFBI bandwidth (i.e. the bus between OMAP and the LCD controller we use), being too slow to push more than ~15fps through at 800x480. Beefing up the processor-side decoding doesn't help. We've been working on this and the next firmware update will give you significantly faster video (with a couple of caveats). So it's mostly just down to the large image display, which more or less suffers from the same problem. I don't think it would give us much benefit at all. So from the hardware side, it is definitely no-matter-what-you-try impossible to play DVD video content on the N800, even if there was help from the DSP? Not really. The next firmware release has gone to great lengths to improve video performance by doing scaling on the LCD controller, as well as the colourspace conversion. I think you'll be pleasantly surprised. ;) signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: DVD content playback possible or not? Re: Wishlist
On Fri, Mar 09, 2007 at 04:33:05PM +0100, ext Klaus Rotter wrote: Hanno Zulla wrote: TI is advertising the chipset used in the N800 as dvd-capable and I had the impression that the hardware was there, only the missing video acceleration and dsp drivers were stopping us from watching full-screen 30fps video on the device. I think TI is referring to the internal frame buffer of the OMAP chip and not the external one used in the N800. The limiting factor may be the bus bandwith. You're completely correct. signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: DVD content playback possible or not? Re: Wishlist (was:Re: N800 and USB host mode)
On Fri, Mar 09, 2007 at 10:34:52PM +0200, ext Siarhei Siamashka wrote: On Friday 09 March 2007 12:20, Daniel Stone wrote: Not really. The next firmware release has gone to great lengths to improve video performance by doing scaling on the LCD controller, as well as the colourspace conversion. I think you'll be pleasantly surprised. ;) Thanks, that's a very good news. We all are looking forward for this firmware update. By the way, is it possible to get an early access to the updated kernels in the future for the purpose of testing and ensuring compatibility? It's a kernel and large X server update. Unfortunately I'm not in a position to be able to release them to the public. I wonder what improvements the new framebuffer driver will bring to us. As far as I understand the situation with the current firmware, the problem is in having to do planar-packed YUV conversion at ARM core and synchronous screen update for anything involving planes. Graphics system in Nokia 770 could perform YUV screen updates asynchronously with DMA consuming only ~20% cpu resources for 640x480 24 fps video output (these ARM core resources were used for planar-packed color format conversion and scaling). N800 is a bit different with a more complicated framebuffer driver with a support for more hardware features (such as a very high quality hardware scaler), but its graphics chip does not seem to support planar YUV color formats, so something else (ARM core?) should do the conversion wasting the same ~20% of resources. By the way, did you consider trying to use DSP at least for unscaled planar-packed color format conversion? It should provide some improvement at least theoretically. The LCD controller takes in a planar format, so we indeed avoid that conversion. The bottleneck, though, isn't CPU or memory load, but the bus between the display controller and the LCD controller. So it doesn't matter where we do the conversion, we just have to minimise the load. Sending 12bpp (i.e., pre-scaled) video over instead of 16bpp post-scaled is obviously a pretty huge win. And a few questions about the future frambuffer driver. I know that the pixel doubling feature should be fixed in the next firmware. Will this driver also support YUV color format for regular screen updates (without using planes) just like N770? I would prefer some kind of stateless API that would not allow to screw up the device when something gets wrong (having some planes enabled at abnormal exit makes it impossible to work with the device and requires a reboot). Yeah, it does, but due to the way this is implemented in hardware, it's difficult to juggle. Doing any kind of scaling enables an overlay, which you have to explicitly overlay. Not doing this will leave you with a weird-looking display until you reboot, or blank the screen and unblank. The X server does all this for you -- the semantics are, uhm, 'nightmarish'; the LCD controller can't do colourkeyed video, only a single cliprect. The Xv support already has this worked out, including automatic migration of your videos when a menu gets popped out or whatever. And it quite rightfully expects that it's the only thing managing the framebuffer, so your planes may well get stomped. You really want to use it. (Is there any special reason why you want to do it directly? If so, let me know, and I'll see if I can introduce support for what you're trying to do in the X server.) And one more minor question is about YUV format constants in framebuffer. OMAPFB_COLOR_YUV422 constant for N770 specifies the same color format as OMAPFB_COLOR_YUY422 for N800, why did you have to introduce a new constant? Don't ask me. All in all, while video output issues can be solved, As much as they can with respect to the hardware, which I don't think is as much as you're making out. CPU performance for video decoding is still another bottleneck. It is even worse bottleneck than video output as you can skip displaying of some frames, but you can't skip decoding. We aren't able to hit a situation where the CPU is an absolute bottleneck, except maybe with some absurdly complicated codec. I haven't seen this arise yet. Did you try to do something about tearing in the next firmware? Yes. Is IVA really unusable on N800? What kind of cpu does it have inside? If it is done by TI, we can probably suppose that it is TMS320C64x (at least I have seen information that IVA2 is a lower clock and more power efficient version of DaVinci which uses TMS320C64x). I'm not sure, as I haven't played with the IVA. But believe me when I say that right now the bottleneck is the bus between the display controller and the LCD controller. You can do the maths on the maximum transfer rate if you don't believe me ... Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers
Re: Wishlist (was:Re: N800 and USB host mode)
On Thu, Mar 08, 2007 at 01:17:47PM -0800, ext Daniel Amelang wrote: On 3/8/07, Eero Tamminen [EMAIL PROTECTED] wrote: [1] There's a bug in Cairo bugzilla about slowness on 16-bit display when using Render though... Although the compositing code could still be better optimized for 16-bit displays, the real bug there was that they were recompositing large surfaces at each scroll step, which will probably never be fast unless compositing is hardware accelerated. Two bugs, really: a) the X server doesn't have sensible acceleration for 16-bit dest pictures. I have a preliminary patch for this which I need to get back on. b) Cairo is dumb. It could degrade to a 16-bit surface if the target is only 16, thus saving a great deal of memory and calculations. Also, last I saw, it insisted on pushing every surface as ARGB32, rather collapsing the alpha channel down to 1 bit, or removing it, if possible. a8r8g8b8 IN a8r8g8b8 OVER r5g6b5 is an incredibly expensive op ... (Note that I haven't checked this for a while.) Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Wishlist (was:Re: N800 and USB host mode)
On Thu, Mar 08, 2007 at 01:06:00PM -0800, ext Daniel Amelang wrote: On 3/7/07, Eero Tamminen [EMAIL PROTECTED] wrote: Err. Translucency means compositing and keeping the composited items in memory. Due to additional memory accesses needed for this, it would be slower (and take more memory) regardless of how accelerated it would be. Keeping the composited items in memory is not necessary. After you composite, you can (and often) just keep the final result around. The Composite extension to the X server requires a backing pixmap for every window, and a final pixmap which is essentially the fb. So, while you're right about compositing as a concept, I think Eero's talking abou the possibility of using the Composite extension. You can see this even on Desktop, just ask how many gamers are happy with integrated graphics cards which share memory with the rest of the system instead of having (hundreds of megs) of their own memory in which to store textures etc. and in where the operations can be done without loading the memory bus of the rest of the system (downside is that all this costs, adds to the computer power consumption heating). :-) I don't totally agree here either. It sounds like you're saying that the hardware acceleration won't get you much unless you have dedicated video memory. He is, and I'm willing to back him up. Here's a counter-example: the macbook uses an integrated graphics card to do all of its fancy accelerated UI effects, including translucency. Yes, the macbook is not a gaming machine, but that's not the issue, here. The issue is that hardware-accelerated graphics enable advanced user interfaces, even w/out dedicated video memory. It would be nice if we had the MacBook hardware in the N800's form factor, with the exact same power consumption. Tragically, this is not the case, and our memory bandwidth is, shall we say, not staggeringly high, limited both by raw clock speed, and memory bus design. The MacBook has PCIE, and fast main memory, meaning that it's able to push textures between the GPU and main memory at a blazing fast rate. N800 has its own 'video memory' for the final framebuffer (so your main memory isn't impacted by the load of scanning out), but the rest would have to be done in main memory, where you're in direct contention with applications for the bandwidth. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Wishlist (was:Re: N800 and USB host mode)
On Thu, Mar 08, 2007 at 03:05:12PM -0800, ext Carl Worth wrote: On Fri, 9 Mar 2007 00:53:18 +0200, Daniel Stone wrote: On 3/8/07, Eero Tamminen [EMAIL PROTECTED] wrote: [1] There's a bug in Cairo bugzilla about slowness on 16-bit display when using Render though... ... b) Cairo is dumb. It could degrade to a 16-bit surface if the target is only 16, thus saving a great deal of memory and calculations. I'd still like to see a test case for the people running into slowness here. Cairo should already be creating 16-bit surfaces when possible, (for example in _cairo_xlib_surface_create_similar when given a 16-bit surface to start with). But cairo wasn't always clever about this, no. Ah, if it's been fixed since I last checked, that'd be awesome. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: WLAN Question
On Wed, Mar 07, 2007 at 12:10:08PM -0500, ext Michael Matalon wrote: Ok.. I have compiled a simple program to read RSSI now and it works using the new driver that was inserted. Here is a new issue that I am expericeing: Everytime I reboot, the n800 reverts to the old driver that doesn't contain the Prism headers. Does anyone know why this happens? Can't seem to figure out why it would revert to the old driver. Every time I reboot I have to run the following commands again: *move compiled cx3110.ko file to device and rmmod old driver* rmmod /mnt/initfs/lib/modules/2.6.18-omap1/cx3110x.ko *install your driver:* insmod /whereeveryourdriveris/cx3110x.ko chroot /mnt/initfs /usr/bin/wlan-cal Am I doing something that doesn't stay permanent? Yes, you're inserting a module. Modules aren't permanent, by their very definition: they're out of the kernel. You can move it over the cx3110x.ko in the initfs if you want it to stay permanent. The kernel can't guess where your new one might be. signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
