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.
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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]
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
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
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
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
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
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
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
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
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
32 matches
Mail list logo
