Re: Soft and hard float
On Sat, 08 Sep 2012 17:48:01 +0200, Marcin Mielniczuk wrote: Thanks, Is the lib Adobe-written or is it something public? You cannot really write a generic soft-hardfp (without PLT trickery) bridge unless you plan to pre-specify the set of functions your hardfp binaries will call. Personally, I think that it would be easier for you to, instead of contaminating Fremantle with lots of Harmattan-ABI-compatible libraries, to just create a Harmattan chroot. How can we check whether an app is hardfp/softfp? You'll find some pretty good explanations if you google a bit about readelf and hardfp/softfp. Javier. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Soft and hard float
2012/9/10 Marcin Mielniczuk marmis...@linux.pl: Hardfp seems to not be the problem. I checked two apps segfaulting on 0x and 2 apps running ok. readelf -A gives the same output (attatched) for all of them The apps were: segfaulting MeegoQQ and AccuWeather (wxapp), working allegro and QToDo. What may cause the segfaults? filebox for N9 causes this kind of fault too. I'm using cssu testing (not thumb flavor) Note that the dynamic loader will happily link two binaries using hard and softfp. Therefore, problems of this nature will seemingly appear randomly, depending on where and when an app does floating point calls. It does not matter if you link hard with softfp if neither is doing any function call containing floating point parameters / return types. As soon as one such call is made, then things MAY go wrong, and in ways you'd never expect. As usual when you approach the undefined behavior area, whatever you experience might be caused by this, or might be caused by the phase of the moon (aka something entirely different, unrelated, and often totally unexpected :) ). Javier. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [Fremantle] Compositing is disabled in fullscreen
Luca Donaggio wrote: I know that compositing is disabled in fullscreen, as some composited widget (for example the fullscreen button in hildon-extras) are shown with a black background instead of a semi-transparent one. But I noticed one thing: if a hildon-banner appears in fullscreen when one of such widgets is on the screen, the window manager turns compositing on (the translucid background of the other widget is shown), just to turn it off when the banner disappears. Is there a way to trick the window manager to act the same for arbitrary widgets as for hildon-banners? The window manager will keep compositing if it finds certain window types present when entering full screen mode. For example, the banner window, or a Hildon Animation Actor. Since you can easily create the latter (hildon_animation_actor_*), I would use that to keep the window manager from switching. On the other side, you should check if you really need to keep compositing enabled if you're not using any window needing it. AFAIK, the fullscreen hildon-extras is not actually using composition but some other strategy. Javier. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Non-experimental QT versioning in Autobuilder (was: QT Packages, Repositories and PR1.2)
Attila Csipa wrote: A single #ifdef can break such a setup, and these things might not be apparent at first (as some of the changes involve property names and values, so might even compile with the wrong version, but will simply not work as desired - the most common case exhibiting this problem IMO being finger scrolling, for example). You mean a #define being X in 4.5 and Y in 4.6, with X != Y? This is probably the cause for the missing guarantees in current Maemo Qt versions ABI compatibility. As for runtime stuff (for ex. a flag that does nothing in 4.5 but is implemented in 4.6) packager would need to add forced depedencies on 4.6 if he does not want 4.5 users to install the package (much like the current problem I have with certain hildon-desktop atoms only implemented in PR1.1/PR1.2 but the package being marked as PR1.0 compatible by autobuilder -- because of course atom names are not symbols). Javier. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Non-experimental QT versioning in Autobuilder (was: QT Packages, Repositories and PR1.2)
Attila Csipa wrote: In theory you just depend on the proper version of libqt4-dev, but it's tricky as you might indirectly reference libs that are also newer in the SDK/new PR so end up with a 4.6 dependency (or broken build) Seems that we need to follow on this, as it is clearly desirable that developers could make use of Qt 4.5 on Extras packages _now_. (And Qt 4.6 if we ever update again the autobuilder to 4.7; not that I am saying we should). Basically, these are the problems I've heard that happen when targeting libqt4-dev and submitting to the autobuilder: 1. Even though your application does not use Qt 4.6 API, autobuilder creates a dependency to Qt 4.6 instead of Qt 4.5. A possible explanation is that some macros, templates, MOC, etc. when using QT 4.6 headers expand to Qt 4.6 newly introduced symbols thus causing the final binary to have dependencies to Qt 4.6 libs. 2. There's at least one package that uses only 4.5 functions save for one single network-related function which comes from 4.6. Thus the final dependencies are detected as: libqt4-core = 4.5, libqt4-gui = 4.5, ... libqt4-network = _4.6_ . This could cause potential problems with certain very Maemo specific ;) package manager's algorithms. 3. Qt Desktop guarantees that an application built under Qt 4.5 headers is binary compatible with Qt 4.6 libs. I'd like to know if we can guarantee that an application built under Qt 4.6 headers but using no Qt 4.5 introduced APIs would work under Qt 4.5 libs. If we can find fixes for all the above problems, we could use the same system we currently use for versioning Gtk+ packages dependencies for Qt applications (aka squeeze devkit .symbols files). Problem 2 at least seems to have a relatively easy workaround. Comments? Extra problems? WORKSFORME? Rants? Everything welcome. Javier. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Howto grab all Maemo5 zoom key events in SDL/SDL_gles app?
Frantisek Dufka wrote: I am not sure why there are three X windows in info.info.x11 structure (fswindow, wmwindow and window). From brief look into SDL sources it seems to me like the 'window' is used when SDL is initialized with not owned pre-created window passed to SDL via SDL_WINDOWID variable, otherwise wmwindow and fswindow are used depending of full screen state. In case you are not using SDL_WINDOWID maybe setting wmwindow and fswindow would help you with volume keys? WMwindow and FSwindow are containers for window (aka gfxwindow) which is the one where images are pushed into. On the Fremantle SDL, WMwindow and FSwindow are alternatively mapped when changing from windowed to fullscreen mode and viceversa -- on a normal SDL, WMwindow is always mapped. Also, gfxdisplay - window (gfxwindow) display - wmwindow,fswindow Else you will get permission errors when you start trying to do more complicated things. -- Javier ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Garage project takeover
Sorry for bumping this again, but... Niels Breet wrote: The project is completely empty and doesn't seem to be used since it has been created on 2007-12-08. I can set you as admin for that project as you seem to be a lot more active than the current admin. I'd like to get an OK from the council so we all agree on this. If there had been data in the project it was a more difficult decision, but now it seems completely empty. Two months have passed -- time for takeover? If the original admin comes back, I'll give him the project. It's not like I am 100% active either. -- Javier ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Squeeze devkit to be installed to autobuilder
Niels can confirm that it is in fact one of my primary directives ;) to allow for all stuff we deploy on the autobuilder to be replicated on local SDK setups (including official and SDK+). In fact my initial post (last paragraph) included instructions for Scratchbox 1 setups (not step by step, though). Marcin Juszkiewicz wrote: 1. Setup 2. FREMANTLE_ARMEL 3. cs2007q3-glibc2.5-arm7 4. debian-squeeze 5. none (as CPU-transparency method) 6. do not extract rootstrap 7. installed default set of files to target You should configure the _ARMEL target this way: Compiler: cs2007q3-glibc2.5-arm7 Devkits: perl doctools git qemu svn debian-squeeze CPU-transparency: /scratchbox/devkits/qemu/bin/qemu-arm-sb (do not extract rootstrap; no need to install files) Also, inside the target, you need to install: maemo-sdk-symbols, dh-make, cdbs, and quilt (if you used them; you most probably did). -- Javier ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Squeeze devkit to be installed to autobuilder
Aniello Del Sorbo wrote: Of all the updated only Mapper is not installable due to hildon1 = 2.2.10 (and libpixman-1-0 = 0.15.16) dependencies... Because it seems to be overloaded, I cannot fetch the package from the repository atm; however, the package was built succesfully under the test autobuilder ([1]) with the more accurate libhildon1 (= 2.2.0-1~rc8+0m5) dependency (~PR1.0). I have also rebuilt it in my local machine with same results. So I guess it's a temporary problem... [1] https://garage.maemo.org/builder/.fremantletest/maemo-mapper_3.0+beta4/results/ -- Javier ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Squeeze devkit to be installed to autobuilder
Graham Cobb wrote: By the way, has the change been well tested? With real packages built with the modified SDK and installed on all existing firmware releases? We don't want to do all this and discover it doesn't fix the problem. We built quite a lot of packages [1], checked sanity of dependencies and I also tested a few on my device (1.1.1). It fixes the problem. Feel free to test some of them :) We expect most of the issues to appear in the building stage, and testing seems to prove this. [1] https://garage.maemo.org/builder/.fremantletest/__packages__/ -- Javier ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Squeeze devkit to be installed to autobuilder
Hello all, As part of the plan to fix the PR1.2 SDK dependency issues in the autobuilder [1], we plan to upgrade the Debian devkit in the Fremantle autobuilder to the Squeeze version [2] (from the current etch one), and start using improved shlibdeps [3] (a.k.a. .symbols files) to version dependencies on a much more granular basis (minimal required version of libraries will be calculated per symbol instead of per library). We plan to ship .symbols files for most of the SDK libraries [4]. This means that packages built in the PR1.2 SDK using no PR1.2-introduced functions will work on a PR1.1 device and even on a 1.0 device. Unfortunately, this approach doesn't include Qt packages as there are more problems to that, but we hope the Qt API to be more stable in future releases. Of course, upgrading to Squeeze _will_ cause compatibility problems to some packages. We have been rebuilding many of them in a test environment [5, 6] and analyzed the common issues -- in fact, we have talked to a few maintainers about those. If your package doesn't build when we move the autobuilder to Squeeze and you don't know how to fix it, don't hesitate to ask. We find that most of the compatibility problems are caused by stricter checks, and that is always a Good Thing (TM). If you want to swap your local SDK to squeeze, you have to 1. Install the squeeze devkit from [2] 2. Replace debian-etch devkit with debian-squeeze in scratchbox target 3. Inside target, apt-get install maemo-sdk-symbols cdbs man-db dpatch [1] http://wiki.maemo.org/Task:PR1.2_autobuilder [2] http://scratchbox.org/debian/dists/stable/main/binary-i386/scratchbox-devkit-debian-squeeze_1.0.3_i386.deb [3] http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps [4] http://maemo.org/packages/view/maemo-sdk-symbols/ [5] https://garage.maemo.org/builder/.fremantletest/ [6] https://garage.maemo.org/builder/.fremantletest/__packages__/ -- Javier ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PR1.2 SDK for Extras-devel: how to solve?
Andrew Flegg wrote: Hi, The number of issues being caused by the deployment of PR1.2 SDK to the fremantle autobuilder is becoming critical. It doesn't even matter when PR1.2 is released, as we should have a way of dealing with this in-place for the next upgrade. I've copied the contents of your message to the wiki: http://wiki.maemo.org/Task:PR1.2_autobuilder I have also added some stuff about dpkg-shlibdeps that we have been discussing on IRC a few minutes ago. Feel free to add any extra options or cons of existing ones. -- Javier ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
GSoC2010 proposal: Gtk+ Input Method Plugin for the Harmattan Input Method Framework
After much deliberation, I've finally decided to present my GSoC proposal. I've decided to develop mdamt's idea about a Gtk+ IM plugin for the Harmattan Qt based input framework. I think it's basically a _must_ for MeeGo, I haven't seen much activity around it, and also feel that I'm now an experienced person for this project, having played with the Hildon Input Method framework quite a lot while doing SDL_him (an API to use HIM from SDL 1.2 apps). You can see my full proposal here: http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/javispedro/t127051361417 I will be thankful for any comment, opinion, or rant you have about it. :) -- Javier ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Howto configure borderless 4:3 tv-out on n900?
Till Harbaum / Lists wrote: The problem is the horizontal stretch. You can't write to /sys/devices/platform/omapdss/overlay2/input_size and by checking what the media player does i found out that it actually changes this to 640x480 when playing a 4:3 video. Unfortunately the /sys interface doesn't allow to write these, so i'll have a look at the ioctls next. Yes, the ioctls will allow you to change the fb size, thus implicitly change the associated overlays' input_size. There's a nice cmd line utility (fbset) to do this (which is not packaged but I plan to do), and we've been toying with this for emus (see IRC). Unfortunately, I doubt you can change the SGX framebuffer size without restarting the SGX or crashing hildon-desktop at least. So this is limited to programs that have the extra framebuffer device in mind. -- Javier ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: promote libs in user/* cathegory
Till Harbaum / Lists wrote: although Javier already removed zeemote support from DrNokSnes to avoid this issue to have an influence on its promotion. I did it because you asked me :) When you think it's ready, (no hurries here) ping me and I'll reenable it. -- Javier ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Howto configure borderless 4:3 tv-out on n900?
Attila Csipa wrote: Can you (or anyone with intimate knowledge) chip in with some comments of how playing with these can (not) affect the devices (or what gets attached to them) ? I would like to play with this a bit, but don't want to burn down my DDP N900 with some weird video sync setting (been bitten by some unrelated hardware happily setting parameters that burned the video out down :) Curiously enough, this very Monday I discovered that we could use the dispc for scaling (in emulators, etc) and have been doing tests for the entire week. You can do weird things like cloning the fb0 (the fb where the sgx renders) to multiple overlays while resizing one of them, and up so far everything still works normally after reboot. I wouldn't touch the lcd timings, and, as fanoush said, you can only write pal or ntsc to the tv-out device timings field. Now that the topic has been raised, I'd like to share what I've been considering for usage of the dispc in 2d games: - The system seems to use fb0 for sgx, and fb1 for xv surfaces. - The system seems to use overlay0 as the base overlay, overlay1 for xv apps: camera, media player (still have to check what happens when a single app has more than one xv surface, if that's even possible), and overlay2 for resizing the tv output. - Thus, when the system is not connected to tv-out, an app could potentially use some ioctls to initialize fb2, then use sysfs to connect it to overlay2 and draw it scaled on the lcd (and also, much like xv, use a special transparent color key on fb0). When the system is connected to tv-out, this app could save overlay2 state and push his own settings when foregrounded, then restore the previous ovly2 state when backgrounded. It could even work :), or so I think. -- Javier ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GSoC project - aGLESory
2010/3/19 Thomas Perl th.p...@gmail.com I *think* the idea behind aGLESory is to make it easier to start creating projects utilizing OpenGL ES for Maemo/MeeGo. Right now, if one was to use Xlib to create a Hello World-ish GL ES app, it would look like this: http://wiki.maemo.org/SimpleGL_example There's too much boilerplate code (setting up the X window, etc..) which makes it hard (or a copy'n'paste job) to start a new project utilitzing OpenGL ES. Shameless promotion: SDL-gles, which removes quite a lot of the boilerplate and doesn't require patches to the upstream SDL nor the maemo one. It's already in -devel and in use by at least one game. 2010/3/19 Valerio Valerio wrote: These idea came from TMO, but I've already contacted the author. My understanding of the idea is a bit different, I think is basically a wrapper from OpenGL to OpenGL ES, in order to easily port OpenGL games/apps to Maemo. I agree, the wording makes it sound that way. -- Javier ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Garage project takeover
Graham Cobb wrote: I suggest a formal email from Niels, in the name of the council, notifying him that someone else wants to take over his project and that the council agrees. As the project is currently empty, and so nothing will be lost, I would give him 1 more week to respond to that email. Note that I clicked Garage's be a maintainer link a few months ago, as any Garage admin would be able to tell (I guess ;P). But I agree with the general idea -- the first email could get lost in some spam filter. Garage has no ability to resend it, so I sent him an email from my own mail address but he may be ignoring that (spambox account with aggressive filtering?). Ideally, could we send him a mail from some official @maemo.org address? -- Javier ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Garage project takeover
Hello, I am currently doing some maintainance work on DOSBox for Maemo (and I am the author of the current package in -devel). In order to fulfill the extras QA bugtracker requeriment and my own need for a VCS repo, I considered registering a new project in Garage, but found that the project was already registered. Quite a few months ago I contacted the maintainer, but he hasn't answered yet, and the Garage interface won't let me spam him again until he accepts or declines the current request. So, a week ago, I sent him an email, with still no reply. I could register a dosbox2 project, or just ignore Garage and go straight to a b.m.o component and a gitorius project, but since the Garage project already exists and is virtually empty, I'd like to know if there's any policy about takeover of empty/abandoned Garage projects by new maintainers, or to kickstart discussions about one if it does not exist yet. DOSBox garage link: https://garage.maemo.org/projects/dosbox -- Javier ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Problem on INotify
Torello Querci wrote: I'm trying to compile mono for MAEMO. Thanks for the effort! Any suggestion is welcome. I'd say try to guess what inotify is used for in Mono (my guess is some obscure part of System.IO), and if it's not really needed for building a bootstrapping capable toolchain, then just write the required empty inotify stubs. If that's not acceptable, you may also want to implement the syscall wrappers yourself (see the glibc code). If you patch sbox's glibc, distributing it will be a nightmare. Javier. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Problem on INotify
Torello Querci wrote: The source C code compile well on X86 and ARMEL target but on HOST environment get this error: undefined reference to `inotify_rm_watch' Remember that HOST target doesn't use the host GNU C Library, but scratchbox's own, which is rather outdated and most probably doesn't contain the inotify syscalls. I suggest you reconsider if you really need to create your own devkit. Most if not all software development for Maemo doesn't need custom devkits, and they are not supported in the autobuilder. If you _really_ need to create a devkit, you can patch scratchbox's glibc but it's not going to be a quick job. Javier ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo5 SDK slow performance
Ville M. Vainio wrote: Yeah, Xephyr is using software rendering. In fact I've assume since forever that Xephyr with the Mesa libraries as shipped with the SDKs are just incapable of any indirect acceleration. On the other side it seems to work for some people I just use VMGl. A pain to install, but works flawlessly and fast (well, save for the background blurry, which doesn't work due to missing extensions). -- Javier ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Build Server Configuration
Marcin Juszkiewicz wrote: Is there something needed other then rebuilding all lib packages to generate such informations? According to this [1], it seems so. Then again you could generate the first version automatically, but for subsequent versions we need some work from the packager. [1] http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps -- Javier ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Where are the N900 too much time at 600Mhz safeguards?
When I got my N900, one of the first things I noticed is that (as measured by powertop) I could never get a 100% ratio at 600 Mhz, but more like 95%. I quickly assumed this was the safeguard for the issue Igor Stoppa talked about at the Maemo Summit. However, I've noticed today (as suggested by a tmo post) that the above is not caused by any special modification in the kernel, but rather because of the CPU idling while waiting for the SGX / some other hw (so, testing methodology failure on my part :) ). Thus, given any task bounded by raw CPU throughput, the device will happily clock itself at 600Mhz, even for hours. Doesn't that contradict what Igor said at the summit? -- Javier ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Build Server Configuration
Marcin Juszkiewicz wrote:debehlp Can you look at how Debian uses library symbols to handle versioned dependencies? Having this in autobuilder should solve this app require pr1.1 just because we upgraded sdk problems. Will probably also help to chinook/diablo packagers. This is more a source packages issue than an autobuilder one. The autobuilder needs only updated debhelper; but all lib source packages need package.symbols file with each symbol and version. -- Javier ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
HildonRemoteTexture tearing/flicker
Hi all, I am doing some experiments on using HildonRemoteTexture from a bare X11/SDL app -- basically to get sgx accelerated scaling in apps that wouldn't otherwise use the sgx for anything else. It works, but there seems to be some race condition where the compositor is reading the shared memory area _before_ I send the damage client event to the remote texture X window. This of course cause visible tearing or even flicker if the texture is drawn while (for example) the SNES emulator is just in the middle of rendering any of the background layers, which tends to happen often depending on CPU load / framerate. Note I'm using HildonRemoteTexture instead of AnimationActor because I need no rotation nor any of the actor features and using H-R-T is slightly simpler -- no need to use any of the MIT-SHM functions. But I have to wonder, seeing how the H-R-T API is falling behind if it is going to be deprecated in the future. Feel free to comment on whether this is a good approach or not, too. Eero wrote: hildon-desktop automatically switches to composited mode when needed. Hopefully this includes having a child animation actor / remote texture :) Javier. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Bad Xephyr OpenGL performance
I opened a t.m.o thread asking a similar question a few days ago: http://talk.maemo.org/showthread.php?t=35790 I believe _no one_ is really getting accelerated GL in Xephyr+SDK. I'm not getting any acceleration (unless I use VMGL). No one I asked to in the Barcelona Long Weekend had accelerated GL in Xephyr+SDK either. I'd say the shipped libGL is the mesa sw-only one. Though, someone in that tmo thread just said he has accelerated GL, so... maybe only super-recent builds of Xephyr get indirect accelerated GLX? Btw, 1500fps in glxgears is hardly accelerated OpenGL these days, which only adds to my suspicions. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: git push problem at git.maemo.org
Please let me know if you experienced problems (except speed) when pushing code changes to git.maemo.org. Also please let me know if you read or heard about workarounds in case git (or actually curl) returns with error code 18 [2] following push. Hi, Since a few days, I've not been able to push to drnoksnes repo in git.m.o due to the that same error code 18. Unfortunately, I don't remember doing anything special to break it, so I guess I can't help with debugging the issue. Thanks for the work, though. :) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Jazelle working (was: Java acceleration/Jazelle)
Hi everyone, as Simon correctly deduced, mostly all that is missing from his experiments is actually enabling Jazelle. This can be done by setting the JE bit in the Jazelle Main Control Register, aka: mov r0, #1 mcr p14, 7, r0, c2, c0 This part is now fully documented in the ARM Architecture Manual. No need to mess with the automated Japanese translation and its Java Hypothetical Machine ;) The other missing part to make Jazelle work is the register assignment; up so far I've discovered that: r0-r4: stack top cache. r5: pointer to handlers table. r5's lower 5 bits: some internal Jazelle status. might indicate which registers are being used as stack top cache. r6: stack pointer. grows downwards. r14: before invoking bxj, this must contain pointer to first opcode I've discovered this mostly by experimentation. As for the rest of registers, I can only make wild guesses so far. As you can see, r0-r4 are used for stack and not only r0-r3 as previously said. The BXJ instruction takes an argument which is the absolute address of the instruction to branch to if, for any reason, Jazelle is not enabled. So, again, as Simon deduced, BXJ acts like a plain BX if the JE bit is not set. If JE is enabled, I'm yet to see what this parameter is used for (I believe nothing at all). The handlers table must contain 256 pointers to handler functions. Each unhandled opcode will bx to the corresponding handler (1:1 mapping). Opcode 255 incredibly enough seems to be actually handled, and just hangs indefinitely (gdb will say $pc is the one with 255 opcode and loop forever). The only handler I've written so far is for the breakpoint opcode, which successfully halts the execution. The breakpoint opcode has the nice added benefit that somehow flushes the stack to memory, so, fortunately, there's no need to fiddle with r0-r4 and r5's lower bits (which I still don't understand, even though there are only 2^5 possible combinations so it should be easy to hardcode). Here is some code that successfully runs the following Java program: iconst_4 iconst_4 iconst_4 iconst_4 iconst_4 iconst_4 iadd (breakpoint) then prints the resulting stack, which of course is 8,4,4,4,4 (right = oldest) Source code and binary: http://cosas.javispedro.com/jaz/ Specially read http://cosas.javispedro.com/jaz/jas.s since it is the one containing the main logic (GNU assembler file), and I've tried to at least comment it a bit. I know I'm being a bit late (2 years :P and with the N900 not having full Jazelle DBX this may be not that useful) but either way I did this as fun project (and to get familiarized with arm assembly, since I knew x86 only). Check IRC's log for today http://mg.pov.lt/maemo-irclog/%23maemo.2009-07-14.log.html . A teaser: :D $ ./j r5 (statehandlers): 36864=0x9000 r6 (stack): 70960=0x11530 r7 (vars?): 70992=0x11550 r8 (cpool?): 71024=0x11570 r12 (not enabled handler): 34156=0x856c r14 (next opcode): 35840=0x8c00 stack: (at 0x11530, size=8) 0=0x0 0=0x0 0=0x0 0=0x0 0=0x0 0=0x0 0=0x0 0=0x0 r5 (statehandlers): 36864=0x9000 r6 (stack): 70980=0x11544 r7 (vars?): 70992=0x11550 r8 (cpool?): 71024=0x11570 r12 (not enabled handler): 0=0x0 r14 (next opcode): 33712=0x83b0 stack: (at 0x11530, size=8) 4=0x4 4=0x4 4=0x4 4=0x4 8=0x8 0=0x0 0=0x0 0=0x0 Thank you all for your research. Javier. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: libicd-network-wpa
2009/3/12 Patrik Flykt patrik.fl...@nokia.com: Hmm, interesting. They should request icd2 once a second for the updated status, which would make icd2 query your network module. Maybe there's a bug/feature when the network has a different type from WLAN_*... Some built-in apps are doing just that (strcmping network_type with WLAN_). That's not a problem (I can choose a new network_type easily) but applications explicitly looking for WLAN_INFRA are (e.g. 'grep WLAN_INFRA /usr/bin/modest.launch' matches). I will later try switching the module's network_type to WLAN_WPA or something like that, and get a full list of applications with hardcoded WLAN_INFRA/WLAN_ADHOC. Thanks again. Putting sane values there fixed a problem I had with icd retrying the connection forever. Also interesting. Those should not have anything to do with retrying a connection. Could you file a hopefully detailed bug report to Bugzilla? My fault -- I originally put some _really_ large timeout there, so even after having been disconnected, icd thought the network was still there, and tried to connect again. I believe this is reasonable icd behavior according to the description you gave me. Thank you all for your answers -- the NIT is now a much more useful device for me :) . I will open an ITT thread with install/usage instructions for this someday. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: libicd-network-wpa
2009/3/3 Patrik Flykt patrik.fl...@nokia.com: One thing you should add to the code: if you already have a WLAN connection ongoing and icd2 calls the link up function again, make the module reply with the ICD_NW_TOO_MANY_CONNECTIONS icd network status in the callback. Hey, thanks! icd2 never tried to call link_up while the connection was up during my so far two week field test, but good to be on the safe side. and I'm having problems with the link_status callback. May I ask for better documentation on this? Please tell what more information you need. I noticed the problem is that the UI is not calling the status function upon clicking on the icd status bar icon. The connection status application does indeed call my status function, but neither the status bar tooltip nor the connection status application show the signal bar. Minor problem tough. Search lifetime is the time in seconds the network is kept cached by icd2, search interval is the time in seconds after which a new network scan is to be triggered by icd2. Thanks again. Putting sane values there fixed a problem I had with icd retrying the connection forever. Right now the whole thing seems to work (I've been using it for two weeks -- my biggest gripe is modest not autodownloading mail) but It's difficult to distribute/install, as it requires replacing cx3110x.ko a.k.a. flashing the initfs. I guess it would be possible to hack wpa_supplicant (yet again) so that it works with the pristine cx3110.ko, but I'm not a wireless-extensions guru. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
libicd-network-wpa
Long story short: I'm releasing under the GPL an alpha-quality icd network plugin which uses wpa_supplicant. Code is at http://svn.javispedro.com/libicd-network-wpa/trunk/ . After having bought a N810, I got hit very hard with #1635 ( https://bugs.maemo.org/show_bug.cgi?id=1635 , Eduroam (EAP-TTLS+PAP) WiFi auth; apologies for my desperate message there) -- seeing it was a low priority request by then, I decided I would try and fix this by myself. Searching through this list, I found a cx3110x patch which made it compatible with wpa_supplicant, and some GPL-released icd headers which made it possible to write a icd module. What the module is doing: - It replaces libicd-network-wlan libicd-network-eap (I've defined a new network_type, WPA, whose only modules are wpa, ipv4 and ipv6) . It does not replace wlancond though, I'm using it for powersaving. - While searching, it initiates a wlancond-managed active ssid scan to each of the configured networks. - On link_up, it calls wlancond 'settings_and_connect' d-bus method to initialize the interface and enable powersaving features. - On post_link_up, it spawns wpa_supplicant, then uses settings from gconf to configure it via D-Bus, then waits for it to enter state COMPLETED (aka connected). - On pre_link_down, it kills wpa_supplicant. - On link_down, it calls wlancond's 'disconnect'. - If It gets a DISCONNECTED event from wpa_supplicant, It sets up a 100 second timeout. If wpa_supplicant goes up again (roaming?) then the timeout is removed. If it doesn't, then it tells icd to close the connection. How: -Patched cx3110x. It is only partially patched so that it does still work with libicd-network-wlan. -Patched/borked wpa_supplicant. It now works with the partially patched cx3110x, and also does active ssid scans OK. -Patched wlancond. I needed a I'm already reading wireless events by myself, no need to bother me with d-bus events and no need to take down the wireless interface for me, just set powersave mode, which I implemented. - libicd-network-wpa.so . Right now the code is on my private repository, at http://svn.javispedro.com/libicd-network-wpa/trunk/ , but I might later create a garage project for it. I'm new to Maemo (and glib, d-bus) development, with my previous coding experience being mostly PalmOS development, so please pardon me if my code is a mess. It was also born as (and it still mostly is) a hack. Now, the questions: - Does this design seem OK to you? - Some maemo applications seem to have WLAN_ADHOC WLAN_INFRA network_types hardcoded, and won't auto-download on connect event if the current network_type is not one of those. The built-in mail application comes to mind. - I've yet to come with the right rssi - signal formula, and I'm having problems with the link_status callback. May I ask for better documentation on this? I also don't understand what search_lifetime and search_interval on network_api.h are for. And I guess that's all I wanted to ask for. Thank you for your time. Hope I didn't botch anything, and sorry for grammar issues. And thanks Quim for looking at #1635 (at least Harmattan will get PAP support out of the box!). ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
