On Tuesday 01 May 2007 20:49, Siarhei Siamashka wrote:
Looks like I have to reply to myself.
On Tuesday 01 May 2007 17:49, Kalle Vahlman wrote:
Applied and build without problems for me.
Thanks a lot for building the package and putting it for download,
everything seems to be fine, but
On Monday 30 April 2007 12:26, Frantisek Dufka wrote:
Daniel Stone wrote:
Specifying that pixels must be exactly _doubled_ is a
hack around both the performance issues and a lack of resolution
independence. Apparently an important one, if you happen to like SDL
games, but a hack
Kalle Vahlman wrote:
I put the deb up at:
http://iki.fi/zuh/xserver-xomap_1.1.99.3-0.zuh2_armel.deb
until I get it to the repository. This version also has the composite
extension enabled, but AFAIK it does not depend on the libs or change
server behaviour if composite is not specifically
Hi,
ext nati dobkin wrote:
hi, thanks for replaying
I will try to explain what is happening. when i start the device it
shutdown
after 6 secs, if i connect it to a charger then it starts a rstart loop and
restart every 6 secs.
I cant set the RD mode because the device is not stay on more
ext Mike Cowlishaw [EMAIL PROTECTED] writes:
While trying to test this on an aeroplane at the weekend -- with Wi-Fi
offline, of course -- the browser would not connect to the server. I've
since experimented further and find a similar (or the same) problem occurs
online if no Wi-Fi connection
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 :)
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
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
On Wed, 2007-05-02 at 11:11 +0300, Kalle Valo wrote:
ext Mike Cowlishaw [EMAIL PROTECTED] writes:
While trying to test this on an aeroplane at the weekend -- with Wi-Fi
offline, of course -- the browser would not connect to the server. I've
since experimented further and find a similar
On Wed, 2007-05-02 at 14:48 +0300, Kalle Valo wrote:
It would take modifications to the kernel - ideally some sort of DBUS
message when a packet needs to be routed - but this would remove the
need to hook into applications, and allow ANY app to generate a request
for connection.
Sounds
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
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
As for pixel doubling, a practical solution would be just to support
400x240 fullscreen resolution in SDL so that no extra hack would be
required when porting each game or emulator in particular.
+1 to this, as a user. 400x240 is a truely good resolution for a display
size like that of a
Daniel Stone wrote:
If there's anything you want to know directly, just ask on the list. I
tend to deal with email when I'm not actively coding/building/etc, which
is how I justify it. A wiki would require me to sit down for a while
and really think about stuff, and I don't really have huge
maybe same discussion at
http://maemo.org/pipermail/maemo-developers/2007-February/007762.html ?
On 5/1/07, Mike Cowlishaw [EMAIL PROTECTED] wrote:
Hi, I have a Wiki running on my N800 using the usual configuration (for
many
applications) of a TCP/IP server running on the local host address
One year ago I found a security hole in the wifi applet. Which interprets
incorrectly the ESSID of the associated accesspoint. This is
sprintf(buf, access_point_name);
and should be
snprintf(buf, BUFSIZE, %s, access_point_name);
Well these lines are in my mind (not in the maemo code), but
Hmm, yes, same discussion - thanks. Unfortunately that thread just faded
out with no real solution for how to connect to running server on N800 when
offline. One suggestion 'rewrite the application' definitely not an
option (especially as I've spent two months porting it to N800.).
mfc
Hi,
ext Siarhei Siamashka wrote:
By the way, do you have any plans for upgrading toolchain? Either I'm
extremely unlucky, or current toolchain is really very buggy.
You can see the known issues from the GCC bugzilla.
There are a few bugs in C++ support which have been fixed
in gcc 3.4.6
On May 2, 2007, at 11:26, Mike Cowlishaw wrote:
Hmm, yes, same discussion – thanks. Unfortunately that thread just
faded out with no real solution for how to connect to running
server on N800 when offline. One suggestion ‘rewrite the
application’ definitely not an option (especially as
Hi;
On 5/2/07, Eero Tamminen [EMAIL PROTECTED] wrote:
It's evil that games change screen resolution, system changes
should be controlled by system software instead of random apps.
If it's enough that the whole screen is scaled instead of a window or
specific update, for Maemo the XRandR
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
allan,
what minimo maemo port version are you running ?
On 5/2/07, Allan Doyle [EMAIL PROTECTED] wrote:
On May 2, 2007, at 11:26, Mike Cowlishaw wrote:
Hmm, yes, same discussion – thanks. Unfortunately that thread just
faded out with no real solution for how to connect to running
server
On 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
On May 2, 2007, at 13:37, Antonio Gomes wrote:
allan,
what minimo maemo port version are you running ?
That's the funny thing. I was blitzing through a number of things,
then reflashed, and wound up not getting back to it before I realized
I don't know where I had found the Minimo. If I
On Wednesday 02 May 2007 20:40, Daniel Stone wrote:
For the use case which is being described here - namely always full
screen applications which need exclusive access to the display at a
lower resolution Why not do something like switch to another VT and do
it directly on the framebuffer
Guillerm,
thanks for your reply. So, about the use of --force-vermagic with
busybox modprobe... What should I have to do to make busybox modprobe
support --force-vermagic? get modprobe source code, and...?
How about to use n770? The WLAN interface driver source code is
available or it is like
Leandro Melo de Sales wrote:
Guillerm,
thanks for your reply. So, about the use of --force-vermagic with
busybox modprobe... What should I have to do to make busybox modprobe
support --force-vermagic? get modprobe source code, and...?
How about to use n770?
There is slightly quicker/easier
On Wednesday 02 May 2007 18:48, Eero Tamminen wrote:
On x86 I prefer valgrind/cachegrind/callgrind/kcachegrind as
that way one can browse the source code interactively with
the profiling information. Getting to know how the source
really works is sometimes more useful than knowing the exact
--- Siarhei Siamashka [EMAIL PROTECTED] wrote:
Siarhei Siamashka wrote:
This is what works for MPlayer on Nokia 770. It creates x11 window just
to reserve some screen space and prevent other applications from using
it. After that, it renders data directly to framebuffer and uses x11 for
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
On Wednesday 02 May 2007 23:01, Arnim Sauerbier wrote:
If the memcpy on 770 is something like 190MB/s, pushing 800x480 at 30fps
would use only 12 percent of that bandwidth
I'm sorry, I was the source of this misleading information, I forgot that
you are a Nokia 770 user and mentioned some
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
On Wednesday 02 May 2007 12:54, Daniel Stone wrote:
The 'framebuffer' is just the ordinary system memory, converting color
format and copying data to framebuffer will be done with the same
performance as simulated in this test. RFBI performance is only critical
for asynchronous DMA data
Don't kill the messenger!
But yeah, always happy to answer direct questions.
Disadvantage is that it becomes lost in the list archive.
This is an old problem communication science solved centuries ago:
generally you have those generating information and those collecting it.
Asking the sources
On Wednesday 02 May 2007 12:39, Daniel Stone wrote:
On Wed, May 02, 2007 at 09:16:01AM +0300, ext Siarhei Siamashka wrote:
On Tuesday 01 May 2007 20:49, Siarhei Siamashka wrote:
Results with unpatched xserver and some more explanations can be found
in [3].
Yes, now N800 is faster than
2007/5/1, Siarhei Siamashka [EMAIL PROTECTED]:
On Tuesday 01 May 2007 17:49, Kalle Vahlman wrote:
OK, here is this untested a patch for xserver to add ARMv6 optimized
YUV420 color format conversion. Theoretically it should compile
(I did not try to build xserver myself though) and work. If
36 matches
Mail list logo
