Re: [maemo-developers] maemo mplayer development and its possible future use on Nokia 770
Siarhei Siamashka wrote: Surely all these problems can be fixed by implementing hybrid x11/framebuffer code where x11 is responsible for keyboard input and sets video mode so that no other application draws over a screen area used by mplayer. Yes, the result would look like video overlay works in windows or linux on PC - overlay draws over different windows when it shouldn't :-) We can live with that. As for framebuffer permissions, it may be better to relax device permissions than to run mplayer as root. I needed a confirmation that Epson chip supports only packed YUV formats and no planar formats are really available Well, the conversion is done on the fly while the data is transferred to internal epson video buffer. I guess it would be hard to do planar YUV - RGB without additional memory. I still don't understand how it is done on the fly even in those packed formats since some color information (U,V) is common for more lines. Seems like tough task. There needs to be additional memory for remembering U,V parts from previous line. Another interesting possibility is to relay video scaling and color conversion (planer - packed YUV) to DSP. I'm not sure, is there some math involved in this or it is just memory shuffling? I guess DSP would be really bad for memory shuffling. From previous discussions it looks like when you add DSP to the mix all kinds of bottlenecks appears. I wonder if gstreamer/dspfbsink could keep up with mplayer speed doing just conversion and video output. Oh BTW, it is off topic but I finally found what that cryptic 'Video hardware accelerators for DCT, iDCT, pixel interpolation, and motion estimation for video compression' feature on OMAP 1710 page means. Looks like the DSP really has some special instructions for performing those operations, google for spru098.pdf It is sad that default video player is still so bad with such features implemented in hardware. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] apt-get problem
Hi, I try and keep my 770 up to date and apparently it got me screwed ... whenever I try apt-get update (from the command line or through the Application Manager) I get a Connecapt-get: Symbol lookup error : /usr/lib/libapt-pkg-libc6.3-6.so.3.10: undefined symbol: _ZN11Globa any idea of what recent update could have updated this lib ? What version do you have ? Any idea on how I could get out of this ? Thanks Fred ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] apt-get problem
ext Fred Lefévère-Laaoide [EMAIL PROTECTED] writes: whenever I try apt-get update (from the command line or through the Application Manager) I get a Connecapt-get: Symbol lookup error : /usr/lib/libapt-pkg-libc6.3-6.so.3.10: undefined symbol: _ZN11Globa That looks more like some kind of file corruption to me since the symbol name is not complete. Or did you truncate the error message somehow? any idea of what recent update could have updated this lib ? What repositories do you use? What version do you have ? Any idea on how I could get out of this ? Try to install the apt package again with dpkg. That is, download it from mistral or scirocco directly, and use dpkg --install ... to install it. (I would have to do some digging to tell you the exact version numbers you should be using...) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] apt-get problem
Marius Vollmer wrote: ext Fred Lefévère-Laaoide [EMAIL PROTECTED] writes: whenever I try apt-get update (from the command line or through the Application Manager) I get a Connecapt-get: Symbol lookup error : /usr/lib/libapt-pkg-libc6.3-6.so.3.10: undefined symbol: _ZN11Globa That looks more like some kind of file corruption to me since the symbol name is not complete. Or did you truncate the error message somehow? I didn't truncate the message. any idea of what recent update could have updated this lib ? What repositories do you use? I copied apt-get update output at the end of this mail. What version do you have ? Any idea on how I could get out of this ? Try to install the apt package again with dpkg. That is, download it from mistral or scirocco directly, and use dpkg --install ... to install it. (I would have to do some digging to tell you the exact version numbers you should be using...) I'll have a look and try it ... Thanks O Fred apt-get update : /home/user # apt-get update Ign http://downloads.kernelconcepts.de mistral Release.gpg Get:1 http://ww.oakcourt.dyndns.org ./ Release.gpg [189B] Ign http://downloads.kernelconcepts.de mistral Release Hit http://ww.oakcourt.dyndns.org ./ Release Get:2 http://catalogue.tableteer.nokia.com mistral Release.gpg [189B] Get:3 http://catalogue.tableteer.nokia.com mistral Release.gpg [189B] Ign http://repository.maemo.org mistral Release.gpg Ign http://repository.maemo.org scirocco Release.gpg Hit http://downloads.kernelconcepts.de mistral/free Packages Ign http://jonek.hexbox.de mistral Release.gpg Ign http://hl.homelinux.org maemo/ Release.gpg Ign http://eko.one.pl mistral Release.gpg Hit http://catalogue.tableteer.nokia.com mistral Release Hit http://jonek.hexbox.de mistral Release Ign http://people.freedesktop.org mistral Release.gpg Ign http://hl.homelinux.org maemo/ Release Hit http://catalogue.tableteer.nokia.com mistral Release Hit http://eko.one.pl mistral Release Ign http://openbossa.indt.org scirocco Release.gpg Hit http://jonek.hexbox.de mistral/user Packages Hit http://repository.maemo.org mistral Release Hit http://hl.homelinux.org maemo/ Packages Hit http://eko.one.pl mistral/user Packages Ign http://people.freedesktop.org mistral Release Ign http://scriptkiller.de mistral Release.gpg Get:4 http://maemo-hackers.org mistral Release.gpg [189B] Ign http://bgran.net mistral Release.gpg Hit http://repository.maemo.org scirocco Release Ign http://openbossa.indt.org scirocco Release Ign http://www.mulliner.org maemo2 Release.gpg Hit http://people.freedesktop.org mistral/user Packages Hit http://www.mulliner.org maemo2 Release Hit http://repository.maemo.org mistral/free Packages Hit http://maemo-hackers.org mistral Release Ign http://bgran.net mistral Release Ign http://scriptkiller.de mistral Release Hit http://openbossa.indt.org scirocco/user Packages Hit http://www.mulliner.org maemo2/free Packages Hit http://repository.maemo.org mistral/non-free Packages Hit http://repository.maemo.org scirocco/free Packages Hit http://bgran.net mistral/user Packages Ign http://home.ufam.edu.br mistral/ Release.gpg Hit http://scriptkiller.de mistral/main Packages Hit http://repository.maemo.org scirocco/non-free Packages Ign http://marceloeduardo.com mistral Release.gpg Ign http://marceloeduardo.com mistral Release Hit http://marceloeduardo.com mistral/games Packages Ign http://home.ufam.edu.br mistral/ Release 99% [Release gpgv 730] [Waiting for headers] [Connecting to armin-warda.de]apt-get: symbol lookup error: /usr/lib/libapt-pkg-libc6.3-6.so.3.10: undefined symbol: _ZN11Globa ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] apt-get problem
Marius Vollmer wrote: ext Fred Lefévère-Laaoide [EMAIL PROTECTED] writes: whenever I try apt-get update (from the command line or through the Application Manager) I get a Connecapt-get: Symbol lookup error : /usr/lib/libapt-pkg-libc6.3-6.so.3.10: undefined symbol: _ZN11Globa That looks more like some kind of file corruption to me since the symbol name is not complete. Or did you truncate the error message somehow? any idea of what recent update could have updated this lib ? What repositories do you use? What version do you have ? Any idea on how I could get out of this ? Try to install the apt package again with dpkg. That is, download it from mistral or scirocco directly, and use dpkg --install ... to install it. (I would have to do some digging to tell you the exact version numbers you should be using...) Strange enough : I tried the Red Pill mode and I had no problem ... then back to Blue Pill ... and the problem disappeared ... A little bit frightening ... how long will my 770 live ... Thanks anyway Fred ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] python + osso_browser does work.
Bugzilla bug 905 closed.
I had upgraded some packages in the red pill mode and it broke some stuff.
The following code works in maemo 2.1
import dbus
bus = dbus.SessionBus()
proxy_obj = bus.get_object('com.nokia.osso_browser',
'/com/nokia/osso_browser')
dbus_iface = dbus.Interface(proxy_obj, 'com.nokia.osso_browser')
dbus_iface.load_url('http://www.google.com')
Thanks to all who looked at it.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] maemo mplayer development and its possible future use on Nokia 770
On Monday 11 December 2006 11:26, Frantisek Dufka wrote: Yes, the result would look like video overlay works in windows or linux on PC - overlay draws over different windows when it shouldn't :-) We can live with that. I thought it is actually not a problem but quite a good thing :-) Surely for mplayer as a standalone video player, supporting keboard/initializing some window is important. But if it just outputs video into some rectangular screen area (provided by some other application) and is controlled via issuing commands through a pipe, it makes possible to develop some advanced frontends which use mplayer as a video rendering engine. For example a twin of the standard Nokia 770 video player which simulates all its GUI controls could be created. My original goal of posting the previous message was an attempt to find a volunteer who would like to try developing such a frontend. I don't have that much time to devote to mplayer development myself. Up until this moment I even could not concentrate on solving some specific task but tried some bits with MP3 audio output, decoder improvements, GUI and user interface, fixing arm specific bugs, and now video output code with hardware YUV support. Also some kind of management work, integration of useful patches and support for users in the forums takes some time. I would like to concentrate on some task such as video decoder optimizations for ARM, but seeing that other parts are not in a quite good shape, distracts attention somewhat :-) As for framebuffer permissions, it may be better to relax device permissions than to run mplayer as root. The most right way to solve this issue is probably to add 'user' to 'video' group. Alternative solutions involve messing with mplayer binary ownership and suid/sgid bits. I wonder what is possible to do automatically in the least intrusive way when installing mplayer package? Well, the conversion is done on the fly while the data is transferred to internal epson video buffer. I guess it would be hard to do planar YUV - RGB without additional memory. I still don't understand how it is done on the fly even in those packed formats since some color information (U,V) is common for more lines. Seems like tough task. There needs to be additional memory for remembering U,V parts from previous line. YUV422 is a good format as it matches 16-bit RGB format quite well. Both of them use 16 bits per pixel, and YUV422 encodes each pair of pixels into a stride of 4 bytes (16-bit RGB encodes each pixel into 2 bytes, but you can also treat it as 2 pixels in 4 bytes). So we can mix YUV422 and RGB data in a framebuffer quite conveniently. Another interesting possibility is to relay video scaling and color conversion (planer - packed YUV) to DSP. I'm not sure, is there some math involved in this or it is just memory shuffling? I guess DSP would be really bad for memory shuffling. From previous discussions it looks like when you add DSP to the mix all kinds of bottlenecks appears. I wonder if gstreamer/dspfbsink could keep up with mplayer speed doing just conversion and video output. Actually DSP may be a good choice for scaling, if you check the same spru098.pdf you will find Pixel interpolation Hardware Extension part :-) Also looks like dspfbsink uses DSP for scaling as it provides a mapped memory for planar YV12 data (or its variant) and accepts a command to do the rendering. I looked through xserver sources and gst plugins to dig for information and I think I got some impression about how they work, but I think this all deserves a separate post along with some additional inquiries addressed to Nokia developers :-) ARM can perform YV12-YUV422 conversion quite fast if properly optimized, I even suspect that it can provide a throughoutput comparable to memcpy (as memory controller/write buffer performance is a limiting factor here and some data shuffling will not make much difference). The benchmarks in my previous message use standard color conversion/scaling code from mplayer which is not optimized for ARM. But just color format conversion is a special case, sometimes scaling is required and mplayer scaler is rather slow. Scaling performed by mplayer was completely unusable for RGB target colorspace with x11 driver, that's why maemo build of mplayer had fallback to SDL when playback for scaled video was required. Now with the target colorspace YUV422, it is slow but still usable and a bit better than SDL. If we want a fast scaler for ARM, using JIT is a good option (and I have some experience in developing JIT translator for x86). Anyway, I hope that by using DSP for scaling and running it asynchronously, it is possible to reduce ARM core usage to almost zero and keep all the resources for video decoding. A related interesting observation is that screen update ioctl does not seem to affect performance at all (commenting it out does not improve performace and naturally we get no picture on the
[maemo-developers] gconf notifications?
Hi,
I just wrote a very simple application that uses gconf notifications.
Unfortunately, the callback is never called. I have used gconf from a
graphical hildon app and notifications worked fine, however, when I try from
a console application it does not seem to work. I include the two simple
files I wrote: gconf_test, which registers the callback and gconf_test_set,
which sets a value. If you can pinpoint the problem I would really
appreciate it. Although there is no error checking for gconf_init, I tested
it and always returned TRUE.
GCONF_TEST
#include gconf/gconf-client.h
#define GCONF_MAEMO_PREFIX /apps/maemo
#define GCONF_KEY_OPERATION GCONF_MAEMO_PREFIX/mc/operation
static void callback(GConfClient *gconf_client, guint cnxn_id, GConfEntry
*entry, gpointer user_data)
{
char *operationName = gconf_client_get_string(gconf_client,
GCONF_KEY_OPERATION, NULL);
printf(OpName:%s\n,operationName);
}
void config_init()
{
GConfValue *value;
gchar *str;
GConfClient *gconf_client = gconf_client_get_default();
if(!gconf_client)
{
printf(Failed to initialize GConf. Quitting.);
exit(1);
}
gconf_client_add_dir(gconf_client, GCONF_KEY_OPERATION,
GCONF_CLIENT_PRELOAD_RECURSIVE, NULL);
gconf_client_notify_add(gconf_client, GCONF_KEY_OPERATION, callback,
NULL, NULL, NULL);
g_object_unref(gconf_client);
}
int main(int argc, char **argv)
{
//Initialize GConf
g_type_init();
gconf_init(argc, argv, NULL);
config_init();
while(1)
sleep(1);
}
GCONF_TEST
#include gconf/gconf-client.h
#define GCONF_MAEMO_PREFIX /apps/maemo
#define GCONF_KEY_OPERATION GCONF_MAEMO_PREFIX/mc/operation
static void
config_init()
{
GConfValue *value;
gchar *str;
GConfClient *gconf_client = gconf_client_get_default();
if(!gconf_client)
{
printf(Failed to initialize GConf. Quitting.);
exit(1);
}
printf(Setting:%s\n,GCONF_KEY_OPERATION);
gconf_client_set_string(gconf_client, GCONF_KEY_OPERATION, deactivate,
NULL);
g_object_unref(gconf_client);
}
int main(int argc, char **argv)
{
//Initialize GConf
g_type_init();
gconf_init(argc, argv, NULL);
config_init();
return 1;
}
Thanks!
Manuel
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] gconf notifications?
Manuel Roman wrote:
I just wrote a very simple application that uses gconf notifications.
Unfortunately, the callback is never called. I have used gconf from a
graphical hildon app and notifications worked fine, however, when I try
from
a console application it does not seem to work. I include the two simple
files I wrote: gconf_test, which registers the callback and gconf_test_set,
which sets a value. If you can pinpoint the problem I would really
appreciate it. Although there is no error checking for gconf_init, I tested
it and always returned TRUE.
GConf needs GMainLoop to be running to work. In normal hildon
applications Gtk+ takes care of this, as gtk_main() runs a GMainLoop.
You can alter your main() to use GMainLoop:
int main(int argc, char **argv)
{
GMainLoop *loop;
g_type_init();
config_init();
loop = g_main_loop_new(NULL, FALSE);
g_main_loop_run(loop);
return 0;
}
Do note, that unlike with Gtk+'s gtk_main_quit(), with GMainLoops, you
need to pass the loop object to g_main_loop_quit, so you'll need to
store the loop pointer and pass it everywhere it is needed. Also note
that gconf_init() is deprecated and needs not be called.
--
Santtu Lakkala
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
