Re: Splitting windows vertically
On Mon, Apr 26, 2010 at 04:20:37PM +0300, Kimmo Hämäläinen wrote: > On Sun, 2010-04-25 at 03:24 +0200, ext Charles Clément wrote: > > Hello, > > > > I have an application, an input method, that doesn't need all the screen > > estate because it is not a virtual keyboard. By default in maemo, if I > > set a size for the window, it will show my application window in a > > horizontal layout, with the normal application above it and my window > > below. > > > > I would like to know if there is a way to run the two windows > > side-by-side, one being at the left of the screen and the other one > > taking the space on the right. > > You could do this with an override-redirect window, the window manager > does not resize those and lets you place them anywhere you like. You > need to set it before mapping (showing) your window. See the Xlib manual > or GTK API how to do it. Yes, thank you, I tried using an override-redirect window. The problem with that solution is that the application window is not resized and still takes the whole screen estate. The input method window will then mask part of the application window which is not really a practical because a text field can be as wide as the whole screen, e.g. when writing the body of an email. > > -Kimmo > > > > > Thanks, > > > -- Charles Clément ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Splitting windows vertically
Hello, I have an application, an input method, that doesn't need all the screen estate because it is not a virtual keyboard. By default in maemo, if I set a size for the window, it will show my application window in a horizontal layout, with the normal application above it and my window below. I would like to know if there is a way to run the two windows side-by-side, one being at the left of the screen and the other one taking the space on the right. Thanks, -- Charles Clément ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Maemo Touch Screen input capture
Hi, I am working on a OpenGL ES application (based on PowerVR framework) on Maemo and want to capture touch screen input for the application. I did not find any touch screen capture in PowerVR libs. Is there any other lib that could capture touch screen input for OpenGL ES apps? Thanks Charles ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
N900 Charging Issue
Hi all, has anyone had this kind of charging issues for N900? My problem was when I plugged in the USB cable into N900 it did not show up the mode selection dialogue and did not show any charging indication either. The same happened with the wall-charger as well. Also, when i turned the phone off and plugged in the USB cable, the front LED flashed yellow twice and nothing happens. I am so annoying by this issue as I cannot charge the phone properly. Is this something related to the Maemo software? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Bad Drawable when running hellogl_es2 example
Hi Kimmo, The source is from: http://qt.gitorious.org/qt/qt/trees/4.5/examples/opengl/hellogl_es2 Thanks Charles _ Want to be a Space Travel Agent? If it exists, you'll find it on SEEK http://clk.atdmt.com/NMN/go/157639089/direct/01/___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Bad Drawable when running hellogl_es2 example
Hi all, I am having issue when running the example hellogl_es2 from QT. The program segment fault on theN900 and showing this error message: X Error: BadDrawable (invalid Pixmap or Window Parameter) 9 Extension: 134 (unknown extension) Minor opcode: 4 (unknow request) Resource id: 0x3e9 It's an opengl es 2 example. any help? Thanks Charles ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
ESBox include paths
Hi guys, I have been working on this issue for couple of days. The problem was to add the include path in a C++ Maemo project in ESBox. I want to add the gstream lib (downloaded and installed in the scratchbox). I tried to add the path through Project->Properties->C++ Path and Symbols but when i compiled the project it says: cannot find the header files. Did i do something wrong? or is there an another way to compile a project? Thanks Charles _ Singles online now! Browse profiles for FREE http://clk.atdmt.com/NMN/go/163036679/direct/01/___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
lua and lua-wx packages for maemo
Packages for lua 5.1 and wxlua 5.1 are now available on my site ( http://tomshirro.org/lua-maemo ). Eventually I'd like to set up a maemo-garage project for this stuff, but I'm still pretty n00b at that part of the game. I'm also curious whether and how they'll install on a Nokia 770; they seem to work ok on my N810. Just in time for Brazil! I'm happy! -- CHS ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
More Autobuilder fun!
Hello All, Sorry to be a pest. But I got all the deps squared away, uploaded Roadmap and now ARM is building fine, but i386 is giving me linker errors--> `.text._ZN3agg18rasterizer_sl_clipINS_12ras_conv_intEE7line_toINS_19rasterizer_cells_aaINS_7cell_aaEvRT_ii' referenced in section `.rodata' of //usr/lib/libaggfontfreetype.a(libaggfontfreetype_la-agg_font_freetype.o): defined in discarded section `.text._ZN3agg18rasterizer_sl_clipINS_12ras_conv_intEE7line_toINS_19rasterizer_cells_aaINS_7cell_aaEvRT_ii[void agg::rasterizer_sl_clip::line_to >(agg::rasterizer_cells_aa&, int, int)]' of //usr/lib/libaggfontfreetype.a(libaggfontfreetype_la-agg_font_freetype.o) A google search on this one wasn't very helpful. 1. Why would it succeed on arm-eabi but fail on x386? 2. What can I do to fix this? Ideas anyone? cheers, Charles Werbick ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Diablo-extras repository access?
Niels, o.k. I got past the libgpsbt-dev issue. Now libagg-dev is giving me problems. Autobuilder fails on it. Looking at the logs, it compiles successfully on autobuilder but the package build fails. (see fail log below... Thanks, Charles make[2]: Entering directory `/home/builder2/maemo-diablo-armel-extras-devel/work/agg-2.5+dfsg1/examples' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/builder2/maemo-diablo-armel-extras-devel/work/agg-2.5+dfsg1/examples' make[2]: Entering directory `/home/builder2/maemo-diablo-armel-extras-devel/work/agg-2.5+dfsg1' make[2]: Nothing to be done for `all-am'. make[2]: Leaving directory `/home/builder2/maemo-diablo-armel-extras-devel/work/agg-2.5+dfsg1' make[1]: Leaving directory `/home/builder2/maemo-diablo-armel-extras-devel/work/agg-2.5+dfsg1' install -m644 ./font_freetype/.libs/libaggfontfreetype.a \ /home/builder2/maemo-diablo-armel-extras-devel/work/agg-2.5+dfsg1/debian/libagg-dev/usr/lib/libaggfontfreetype_pic.a install -m644 ./src/platform/sdl/.libs/libaggplatformsdl.a \ /home/builder2/maemo-diablo-armel-extras-devel/work/agg-2.5+dfsg1/debian/libagg-dev/usr/lib/libaggplatformsdl_pic.a install -m644 ./src/platform/X11/.libs/libaggplatformX11.a \ /home/builder2/maemo-diablo-armel-extras-devel/work/agg-2.5+dfsg1/debian/libagg-dev/usr/lib/libaggplatformX11_pic.a install: cannot stat `./src/platform/X11/.libs/libaggplatformX11.a': No such file or directory make: *** [build-stamp] Error 1 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Diablo-extras repository access?
Hello All, just a quick question here. Do I need a separate invitation to upload to diablo extras? I can upload to chinook no problem. But diablo gives me 'access denied' cheers, Charles Werbick ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: USB Host - Class 1 Bluetooth
Hello All, If I'm out of frame here let me know. But it does seem that a powered hub would resolve the issue quite nicely. There may also be a software hack also that allows the kernel to ignore the power requirements. I do remember seeing power assesment code, in the musb driver source. However, disabling that check in the kernel is a *bad* idea. Real USB OTG hardware is used to receiving signals down the +V pin. (That's how it sends host-peripheral negotiation). So a host->host hookup is unlikely to destroy OTG hardware, but non-compliant hardware could theoretically get fried. I'm unfamiliar with the 770 hardware and whether it is fully OTG compliant or not. But a hub is the safest bet. cheers, Charles Werbick On Mon, Jun 16, 2008 at 5:22 PM, Daniel Blackburn <[EMAIL PROTECTED]> wrote: > I don't think the power should be an issue as Bluetooth adapters > shouldn't be much more demanding that other USB devices that people have > got working with the 770. I am using a circuit similar to this one, > http://www.hcilab.org/projects/nokia770/nokia770.htm. I will test my > circuit with other simpler USB devices with comparable power usage but I > think the problems will be more related to software than hardware. I > don't have much experience with drivers on Linux so that is the bit were > I am worried I might have overlooked something crucial. > > Cheers, > Dan > > Allen Brown wrote: >> This is tangential to what you are asking about, but I think you >> could run into a problem with your power injector. It's been a >> few years since I read the USB specs, but as I recall the host >> knows, and makes decisions based on, what power is available. >> Also it switches that power on and off depending on what state >> the "bus" is in. There could be problems if the actual power >> doesn't match what the host thinks it is. >> > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Rebuild all chinook source packages on autobuilder
Niels, I ported/maintain Roadmap-1.1.0 for Maemo. It's not going to autobuild unless I upload the build-deps (libagg, freetype, and possibly libcurl soon) to extras. AGG and cURL are straight ports of the debian packages. freetype was compiled and installed from source as the debian package wouldn't build... I'd be happy to provide whatever's needed for autobuild to work on Diablo. But I've a couple questions. Do I need to create projects for these packages to upload them? Or should I just get *debs built and upload them as-is? (And where in the package should I note that these are un-modified debian packages?) Cheers, Charles Werbick ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
osso-gnupg and RSA support gmgme library
Hello All, I've recently started an app that uses RSA sigs to verify identity. Upon building osso-gnupg in scratchbox I've noticed it's pretty much useless for my purposes... Is there any plan to put a full version of GnuPG in Maemo for Diablo or should I just roll my own GnuPG/GPGme? Cheers, Charles Werbick ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: D-BUS service name confusion
Hello All, While we're on the subject of dbus, desktop files and bugs you might also want to look at- https://bugs.maemo.org/show_bug.cgi?id=3125 The upshot is that maemo doesn't handle extra whitespace in the desktop file well. If after creating your desktop file, your app crashes, check for spaces tabs and extra carriage returns in your desktop file first. There might not be anything wrong with your application... Cheers, Charles Werbick p.s.- It took me some time (and a few headaches) to figure this out. I hope this helps someone. On Wed, May 28, 2008 at 11:44 AM, <[EMAIL PROTECTED]> wrote: > Axel Sommerfeldt wrote: >> So in total I find the current situation very bad: >> - The Maemo 4.0 Tutorial is wrong, it must be "osso_context = >> osso_initialize( "org.maemo.example_libosso", "0.0.1", TRUE, NULL);" >> instead of "osso_context = osso_initialize( >> "example_libosso", "0.0.1", >> TRUE, NULL);", otherwise this example will simply not work. > >> - The documentation of osso_initialize() is wrong/misleading. > >> - The maemopad example is misleading: It works, but only as >> long as you >> don't change the "com.nokia" to something different, >> otherwise it stopps >> working and you simply don't know why. > > So, did you > https://bugs.maemo.org/enter_bug.cgi?product=Development%20platform file > a bug? > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Help with YV12->YUV420 converter
Simon Pickering wrote: > Hi Buck, > >> I have not looked at your code, so forgive me if I say something >> obvious. >> >> The one thing that bit me was the fact that the DSP/toolchain did not >> handle access to data objects larger than 64k, due to 16 bit >> restrictions on the DSP. My understanding is that later toolchains >> removed those limitations (although I do not know if they ever became >> freely available). I wrote very ugly workarounds to handle cases >> where pointer values crossed 16bit boundaries. I worked, but overall >> my code was horribly slow. If this is news to you, I can provide more >> details. > > > I'd be interested to see what you did. > > When I first started looking at accessing large regions of shared > memory I may have run up against that 64k limit (I certainly had some > weird errors). I was advised to never attempt to access memory as an > array (i.e. ptr[n]) but to always use pointer arithmetic directly > (i.e. *(ptr + n)) and it seems to have worked thus far. > > Cheers for the advice, > > > Simon > Hi Simon, You can find the code I wrote here: http://qstream.org/viewvc/trunk/qvid/src/video_out/maemo_dsp_yuv/ A whole bunch of DSP related documents and things I collected are here: http://qstream.org/~krasic/770/dsp/ -- Buck ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Help with YV12->YUV420 converter
Hi Simon, I did a simple DSP yuv->rgb converter a year (or two?) ago. I have not looked at your code, so forgive me if I say something obvious. The one thing that bit me was the fact that the DSP/toolchain did not handle access to data objects larger than 64k, due to 16 bit restrictions on the DSP. My understanding is that later toolchains removed those limitations (although I do not know if they ever became freely available). I wrote very ugly workarounds to handle cases where pointer values crossed 16bit boundaries. I worked, but overall my code was horribly slow. If this is news to you, I can provide more details. -- Buck ps there should be some messages about my DSP work in the maemo-developers archives. Simon Pickering wrote: >Hello everyone, > >I've been hacking together a YV12 to YUV420 converter to run on the DSP. I >have running code, but there are some artefacts on the screen. I was hoping >that some of you with more experience of video stuff might spot an obvious >error. > >If you want to run the code, you need to make some changes to your setup >(including a kernel patch). I'm happy to give instructions, but thought in >the first instance more eyes looking at the output and the code might turn >up some things I've missed. > >I have two images showing the sorts of visual artefacts I'm getting [1,2], >as you can see they are different frames but very similar. The green regions >seem to stay in those general locations. Other than that, the image looks >quite reasonable. Any thoughts on what might cause this sort of localised >glitching? > >The source video is here [3]. It was converted to a file called stream.yuv >by the following mplayer command: "mplayer -vo yuv4mpeg comet_jupiter_1.mpg" > >I have checked the resultant YV12 file and there are no glitches in any of >the planes. > >The DSP code is here [4] and ARM code is here [5]. The code is messy (read >development), and un-optimised (lots of divisions of unchanging variables >within the main loop for example). If anyone has any thoughts about >optimisation I would be interested to hear them, but the immediate problem >is getting it to output correctly. > >The ARM code takes two input arguments, a filename and a letter which >indicates how to output the data. The case we're interested in is a letter >code of "y" indicating that we want to do YUV420 output. Note that there is >a typo in the ARM code [5] on line 198 (should read 45 uchars rather than >46), however this is luckily dealt with by the code which follows so >shouldn't cause a problem. > >The general code flow is: >ARM side construct a struct to pass to the DSP to tell it the input/output >formats and the size of the frame; >ARM side read a frame's worth of data from file and place it in shared >memory; >ARM side call ioctl to trigger DSP code; >DSP side catch ioctl in yv12_convert_rcv_tctl(), call >yv12_convert_draw_buffer() which in turn calls convert_YV12_to_YUV420() in >this specific case. In this function the data are copied to the framebuffer >and converted en route. The framebuffer update is then called and it's >output to the screen. > >Any thoughts, comments, etc. gladly accepted. > >Thanks, > > >Simon > >P.S. If there's a comment/piece of code you don't understand it's probably >because I've fiddled with the code so much and it got left behind. Please >ask :). > >[1] http://people.bath.ac.uk/enpsgp/nokia770/dsp/PICT0050.JPG >[2] http://people.bath.ac.uk/enpsgp/nokia770/dsp/PICT0052.JPG >[3] >http://hubblesource.stsci.edu/sources/video/clips/details/images/comet_jupit >er_1.mpg >[4] >http://people.bath.ac.uk/enpsgp/nokia770/dsp/test-yv12-convert-and-output/N8 >x0/yv12_convert.c >[5] >http://people.bath.ac.uk/enpsgp/nokia770/dsp/test-yv12-convert-and-output/ar >m/test_yv12_output.c > >___ >maemo-developers mailing list >maemo-developers@maemo.org >https://lists.maemo.org/mailman/listinfo/maemo-developers > > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Extras Repo key reset?
Hello All, Im trying to get myself set up to upload to extras. However I'm running into the same issue reported here- http://www.gossamer-threads.com/lists/maemo/developers/15179 It would seem that either- A) I've mis-pasted my ssh key on the invitation page (It is RSA). My webbrowser line-wrapped the key in the web form and I had to backspace it to make it one line. (As an aside, uploading these keys as attachments could prevent this...) B) PGP key used to sign package must also be RSA? (Mine is DSA.) I emailed [EMAIL PROTECTED] Friday and still haven't heard back. Anyone on the list know how to reset my repo keys or whether DSA PGP keys work for signing? TIA, Charles Werbick ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Debugging Desktop Applets in Python
On Mon, Apr 7, 2008 at 6:10 AM, Eero Tamminen <[EMAIL PROTECTED]> wrote: > If you want to see output from maemo-launched applications on the > device, remove the --quit option from maemo-launcher > /etc/init.d/maemo-launcher init script. I assume you meant '--quiet'? Cheers, Charles Werbick ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Best format for SD ?
> Charles is missing a dot: "The chips have a thermal design power (TDP) > specification in 0.6-2.5 watt range and scale to 1.8GHz [...]" > > http://www.intel.com/pressroom/archive/releases/20080302comp.htm > Sorry rented fingers... I am missing a dot. (Probably more than 1 but the rest were missing from my dice ;-) Cheers, Charles Werbick ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Switching N810 to USB host mode?
On Tue, Apr 1, 2008 at 7:17 AM, Kimmo Hämäläinen <[EMAIL PROTECTED]> wrote: > Maybe that works, I haven't tested. The kernel's automatic cable > detection might fight against you. > > BR; Kimmo Yes you are right, it does. That's the problem he's having, described (with a patch) here- https://bugs.maemo.org/show_bug.cgi?id=3026 I don't know whether this is a software issue that affects all n810s or a flaw in the silicon itself. Either way, resetting the driver on state change does resolve it. The patch I provided was quick and dirty, but worked for me (and for the original poster to whom I emailed a patched zImage.) cheers, Charles Werbick ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Switching N810 to USB host mode?
On Tue, Apr 1, 2008 at 3:48 AM, Kimmo Hämäläinen <[EMAIL PROTECTED]> wrote: > ... > After connecting your stick, please check the value > of /sys/devices/platform/musb_hdrc/mode -- the kernel should switch to > the host mode automatically. > > BR, Kimmo O.K. Now I'm confused... The kernel should switch to host mode automagiacally if he's using an OTG 'A' cable. But he's not. He's setting the soft ID through sysfs and using the stock nokia OTG 'B' cable with a USB F->F adapter. So the kernel should stay in OTG mode unless he does- echo host > /sys/devices/platform/musb_hdrc/mode Or am I missing something here? Charles Werbick ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Best format for SD ?
Hello All, I've been using ext2 on the principle that journalling increases the writes to the drive, in general. Internal wear levelling probably negates that paradigm as the memory is likely to outlive the device. A dozen years before failure? I'll have upgraded by then, unless we're in 'I Am Legend' land... Anyway, ext2 or ext3 both work well. I've been using, and booting to ext2 on the external MMC (with swap also on MMC) as I'm hacking a ton, so I don't want to fry anything non-replaceable. I figure, If I jack out the MMC I can still boot to flash and buy a new card. If you're worried about fault tolerance use ext3. The worst that'll happen is your flash will last 10 years instead of 12. Honestly, no matter what file system you use, the CPU speed and power consumption (plus increased flash capacities) will obsolete the n8xx series far before the flash wears out. The Intel Atom processors are due out this spring and will kill ARM on tablets period. ARM simply cannot compete with a Pentium III CPU at 1.5 GHz and 12 watts total dissipation. I predict that the n900 series, should it reach production, will run Intel and not TI silicon. (I realize that I'm setting myself up here should I be wrong. But Intel has increased the speed of their CPU while decreasing cost, power consumption and size. I don't see TI keeping up... Just my 2 cents.) Cheers, Charles Werbick On Sun, Mar 30, 2008 at 3:08 PM, Andrew Daviel <[EMAIL PROTECTED]> wrote: > On Sun, 30 Mar 2008, Ryan Pavlik wrote: > > >> What is the best available F/S for flash ? And what options ? > >> > > >> I saw an interesting webcast by Mentor Graphics where they were talking > >> about designing a new filesystem especially for flash, which would be > > > > With regard to limited write cycles, SD cards automatically and internally > > do > > wear leveling (that is, writing to place 0 on the drive might never be the > > same place) to counter that effect, so that's why FAT works without burning > > out cards writing the FAT every time you change something. When you have a > > "memory technology device" - aka, just a flash chip directly attached some > > how, not through SD (think the internal 256), then a file system like JFFS > > (which the Nokia devices use) does compression and wear levelling at the FS > > level. > > I was just looking at JFFS2. As you say, it's designed for direct access > to flash rather than over SCSI emulation. When I re-read my notes on the > Mentor talk (they are big in electronic circuit design, and would be > providing hardware libraries for ASIC and (F)PGA design) they do mention > JFFS and YAFFS and say that their "Mentor Safe File System" would be an > improvement with 100% power fail safety and with various optimization for > NOR (fast read) NAND (fast write) hybrids etc. I think NAND support was a > relatively recent addition to JFFS2. > > I'm still interested in which of the various f/s (ext2/3, xfs, jfs, > reiser ...) might be better on SD (mounted over USB via SCSI emulation) > if I don't care about Windows compatability. Then there's the extended > attributes (used by Apple's calendar server), not that I have immediate > plans for that... > > > > > -- > Andrew Daviel, TRIUMF, Canada > Tel. +1 (604) 222-7376 (Pacific Time) > Network Security Manager > ___ > > > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Switching N810 to USB host mode?
I'm glad it works. I'm still not sure this is a kernel bug as not everyone with an n810 is having this issue. It may actually be a hardware problem with the soft ID pullup. (from what I've read, the soft ID activates a transistor with resistor internally to set the ID so that an OTG cable can override the software setting. My guess is that the pullup is getting stuck 'on'.) Whether this is hardwared or software related, I don't know. I'm just happy to have found a fix... cheers, Charles Werbick On 3/30/08, Laurent GUERBY <[EMAIL PROTECTED]> wrote: > With your image I suceeded in mounting an USB key > and using an USB keyboard (nokia cable + female female + plug). > > This confirms this is a kernel bug, let's hope it gets fixed > by Nokia: > > > https://bugs.maemo.org/show_bug.cgi?id=3026 > > > Thanks! > > > Laurent > > > On Sun, 2008-03-30 at 09:34 -0600, Charles Werbick wrote: > > > > May be there's a way to workaround it? > > > > > > Thanks in advance, > > > > > > Laurent > > > > Did you try the kernel patch I put on bugzilla? It fixed the issue for me. > > > > Charles Werbick > > > > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Switching N810 to USB host mode?
Andrew, Yes this is the same problem I had. It is simply a pain to get the n810 into host mode. It gets stuck in B_IDLE. Please vote for - the bug at- https://bugs.maemo.org/show_bug.cgi?id=3026. It shouldn't take too much effort to get it applied as I've provided a patch... The 'USB Device not supported' message is normal. It's actually a good sign as you won't see that if you're not in host mode. (there's a USB whitelist specified in the kernel driver. Unless your device is listed, the device will display as unsupported. It may still work, but you'll see the popup. Ignore it...) The main issue I had was that I couldn't get the n810 into host mode unless I was 'plugged in' in peripheral or OTG mode. If you can get into host mode from peripheral mode (i.e.- while plugged in as a USB HD) but not from scratch or boot up,then we're in the same boat. As before, I'd be happy to email you the patched kernel image for you to try. But if it works for you, please vote for bug 3026 at bugs.maemo.org so that it gets fixed in the next release... Cheers, Charles Werbick On Sun, Mar 30, 2008 at 5:52 PM, Andrew Daviel <[EMAIL PROTECTED]> wrote: > > I posted a longer version of this from the wrong address and it bounced. > In view of Charles Werbick's message & patch I've removed most of it. > > (for my N810 with 2008SE_2.2007.51-3, unpatched) > It seems I have to unplug/replug the USB cable in host mode to get the > memory stick (via F/F adapter) to be recognized. Then I get > a popup "usb device not supported" > (dmesg usb 1-1: device v058f p9382 is not supported) > but the stick shows up in lsusb and the file manager autostarts. > > In usbcontrol GUI, I don't see my device listed unless I click "host" > twice. > > > I tried "flasher-3.0 --enable-usb-host-mode" > but it did not work. Or I did something wrong. I tried the command, > then "flasher-3.0 -b" (reboot). Also tried disconnecting the USB > cable from the PC, connecting the memory stick, and clicking the > power button. The tablet booted up in perpheral mode both times. > > > -- > Andrew Daviel, TRIUMF, Canada > Tel. +1 (604) 222-7376 (Pacific Time) > Network Security Manager > > > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Switching N810 to USB host mode?
> May be there's a way to workaround it? > > Thanks in advance, > > Laurent Did you try the kernel patch I put on bugzilla? It fixed the issue for me. Charles Werbick ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Installing directly onto internal memory card
You can use the pre-install script to do what you need. But you need to make sure your post-removal script cleans it up. hope this helps, charles werbick On 2/17/08, Till Harbaum / Lists <[EMAIL PROTECTED]> wrote: > Hi, > > I'd like to install some data of a game directly onto the internal memory > card. Unfortunately the installer doesn't seem to be able to create the files > there as it's a fat file system. The installer fails with the message that it > cannot preserve the file permissions (which is true as fat cannot do this). > > Can one circumvent this? There isn't much inside a deb file that makes me > think this is possible. How can data be installed directly onto a memory > card? > > Regards, > Till > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N810 AGPS?
I've heard a lot of complaints about time to fix for GPS on the n810. If there's a way to read the raw gps data and do the initial ephemeris processing and location calculation with the ARM processor, I'm all ears! Charles Werbick On 1/30/08, Darius Jack <[EMAIL PROTECTED]> wrote: > Hi, > as Navteq's developer I developed some LBS systems and your N810 can play > GSM-AGPS, WiFi-AGPS. > Frankly speaking I have never tested any of my 2 AGPS enabled NEC 616V cell > phones for navigation as I have got 2 bt gps, 2 usb gps devices and they > work fine and fast. My another gps enabled cell phone Motorola A1000 (agps > as I suppose) never started to work fine due to gps signal loss and long fix > times. > > Darius > > > > Simon Pickering <[EMAIL PROTECTED]> wrote: > > Just wondering if AGPS is enabled, or could be enabled on the N810. We > have a chip which supports it (Ti NaviLink GPS5300). The question > (mainly aimed at Nokians) is whether or not they can release a bit > more info to make this possible. > > We could do AGPS LTO (Long term orbit) for example over Wifi (assuming > this isn't already in the pipeline and is not impossible due to > something missing from the chip, etc.). > > I see that gpsdriver creates/uses/modifies a file called > /var/lib/gsp/nvd_data which contains a few headings and lots of > numbers. I've had a quick look at these but can't work out what they > are, but the numbers certainly change (e.g. from one day to the next > at the very least in my minimal testing). Anyone with more experience > of GPS-y things have any ideas what these might represent? > > I also see there's a file called gps_last_saved_report which is > presumably fed back to the GPS to avoid a cold start (and to give it > credit, the latter starts are certainly faster, just not AGPS faster, > afai have heard they should be anyway). > > Any thoughts? > > Cheers, > > > Simon > > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > > > > Send instant messages to your online friends http://uk.messenger.yahoo.com > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N810 AGPS?
On 1/30/08, Simon Pickering <[EMAIL PROTECTED]> wrote: > > Just wondering if AGPS is enabled, or could be enabled on the N810. We > have a chip which supports it (Ti NaviLink GPS5300). The question > (mainly aimed at Nokians) is whether or not they can release a bit > more info to make this possible. > > We could do AGPS LTO (Long term orbit) for example over Wifi (assuming > this isn't already in the pipeline and is not impossible due to > something missing from the chip, etc.). > > I see that gpsdriver creates/uses/modifies a file called > /var/lib/gsp/nvd_data which contains a few headings and lots of > numbers. I've had a quick look at these but can't work out what they > are, but the numbers certainly change (e.g. from one day to the next > at the very least in my minimal testing). Anyone with more experience > of GPS-y things have any ideas what these might represent? > > I also see there's a file called gps_last_saved_report which is > presumably fed back to the GPS to avoid a cold start (and to give it > credit, the latter starts are certainly faster, just not AGPS faster, > afai have heard they should be anyway). > > Any thoughts? I've been thinking the same... Namely, can we build an agps server into the n8x0 to have the cpu assist the gps chip? (i.e.- set the agps to localhost and compute location on the ARM.) cheers, kernelpanic ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [Maemo App Dev] how to create multi-window app with only one trayicon in Task Navigator
On Jan 29, 2008 11:34 PM, 陈凯 <[EMAIL PROTECTED]> wrote: > Hi, everyone > > I am about to write an app containing multi-window and user can switch from > one and another at any time. While I show a second hildon.Window, another > icon pops up in the TaskNavigator. It looks ugly and confuses the user as > if the two window are irrelevant. > > I found Pidgin and Opera which can have multi-window but only one trayicon > in TN. I dived into Pidgin source code but in vain. I don't know how they > achieve that effect. Could anyone give me some hint or suggestion? Thanks > a lot The same executable running twice shows as one icon with a small '2' on it. Two different executables show as 2 icons. If you make your app one executable you should get only one taskbar icon. Without knowing more about your application, it's hard to say whether this'll help you though... Good Luck! cheers, Charles Werbick ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: latest RTCOMM 2008 beta makes n810 reboot
> Completely off-topic, but related: is there an easy way to get a > usb-serial console during boot? > > regards > Philipp > Philipp, Check this out- http://maemo.org/community/wiki/HowTo_EASILY_Boot_From_MMC_card (and this-) http://fanoush.wz.cz/maemo for the initfs_flasher. It's a replacement boot menu with several recovery options, I've got it running fine on my n810 with the latest flash(50-2)... It's a must have for anyone developing on their n800/n810. Right now I've got 3 OS installs on my n810- 1. The internal flash- I keep userspace programs here, but don't do any dev stuff. If I break the OS on the MMCs I can just boot from flash! 2. a 600 mb partition on the external mmc with debug versions of most libraries installed for testing. This is my main testbed for apps. I've broken it a few times, but fixing it is ridiculously easy. 3. Another 600 mb partition on the external MMC I'm trying to set up as a native development environment. (It's a work in progress.) This partition is not bootable, though ideally I'd like it to be. Right now I chroot into it. I basically cloned a fresh install, replaced busybox with bash, and installed all the development tools. I'm still working on installing all the -dev libraries. But the compiler works. With any luck, I'll soon be comiling apps natively on the n810... Anyway, booting from mmc really is a life saver. Check it out. Charles Werbick ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: roadmap maemo build -- was: Re: osso/d-bus bug?
> > Hi Charles, > > This is great news! > > I seem to be cursed by my slowness, or perhaps I should say blessed as > I was planning on doing the same thing, but am very new to my N810 and do > not yet have the build environment complete due to lack of time. > Are you planning on submitting the changes to get it "hildonified" upstream > to the roadmap project as build options? (please please please). > Um, no. Not at this time. I really like roadmap. but in order to not kill myself managing dependencies I have converted the source to GNU automake tools.and removed the map building programs. Also, d-bus services are generally declared in main() and since roadmap and roadgps share that function, significant changes to the source have been and will be required for hildonization. My goal is to make a hildonized roadmap client for maemo chinook. I do plan on converting the unmodified source to GNU automake tools and building a debian package.. If they want to upstream that big of a change, great! >. Can I help? Yes. Especially if you know libosso and/or d-bus. That's my hangup right now. Everyhing else is going well. Next step azfter that is state saving for preferences and hibernation. > Also, if you are not on the roadmap listserv, could you consider joining? maybe. > Best Regards, > Josh > right back at ya, Charles ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
osso/d-bus bug?
Hello All, This is my first post to this list. I've scoured the internet and the mailing list archives for info on this and have only found one unconfirmed bug report regarding it. So- Apologies in advance, if it's already been answered. I'm a long time linux hacker who recently got the n810 for work (rdesktop+ssh+vnc==never having to lug around a laptop again ;-) I am currently porting roadmap (http://roadmap.sourceforge.net) to maemo with great success. Hildonization and deb packaging are a breeze. But I've run into issues with d-bus service implementation using osso. Here's the thing- I am able to cause an abort to dbus from userspace when starting the app from maemo-launcher! On the device this kills then restarts the entire ui. (Minus the desktop applets which do not reload.) Note-When starting from the command line, everything works great. dbus-monitor shows the service, and once the app is started, clicking on the launch icon switches to the running app rather than start a new instance(as it should). I haven't finished the callbacks yet, which is the likely cause. However, it seems like osso and/or dbus should handle the situation more gracefully than it does. My questions- 1. Has anyone else observed this behavior? 2. Why does d-bus abort rather than just kill the app? 3. What are the minimum callbacks that I need to provide in order to prevent this? Any feedback would be appreciated. Thanks in advance, Charles Werbick ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Using available DSP tasks
On Jan 1, 2008 12:32 PM, Simon Pickering <[EMAIL PROTECTED]> wrote: > Quoting Daniel Charles <[EMAIL PROTECTED]>: > > > See the merged pipeline below > > >> Yes, this is certainly doable already. I don't have any G7.11 data to > >> hand, but have tried it by mixing ogg and mp3 data (ogg using Tuomas > >> Kulve's gstreamer plugin which uses the pcm dsp sink). > >> > >> E.g. These two commands can be run is separate terminal windows and > >> are mixed: > >> > >> gst-launch-0.10 filesrc location=20-16000HzExp5sec.mp3 ! dspmp3sink > >> > >> gst-launch-0.10 filesrc location=opensource.ogg ! application/ogg ! > >> tremor ! dsppcmsink > > > > gst-launch-0.10 filesrc location=20-16000HzExp5sec.mp3 ! dspmp3sink \ > > filesrc location=opensource.ogg ! application/ogg ! > > tremor ! dsppcmsink > > > > This way you can be sure that both pipelines are running on a single > > process. I'm not certain it is going to work as expected due to > > constraints with two audio streams running at the same time, but you > > can write as many source->filter->sink pipelines in a single > > gst-launch as you want. > > Thank you very much. Is the backslash optional? Was it there just to > indicate a line continuation (my email client has wrapped the > following line too) or is it the correct way to separate the different > parts of the pipeline? Yes it is a line continuation, normally in a command prompt you can either type (copy/paste) the entire line or with the back slash for read clarity but it is optional. > > In any case your command (with or without backslash) produces the > desired behaviour and both files play. I'm glad to hear that it worked :) Daniel > > Cheers, > > > Simon > > P.S. Just to test that the karaoke idea will work I tested MP3 and > G7.29 data (I couldn't find any G7.11 data to test) and they play > together without troubles: > > E.g. > gst-launch-0.10 filesrc location=20-16000HzExp5sec.mp3 ! dspmp3sink > filesrc location=./audio-temp/transfer.g729 ! dspg729sink > > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Using available DSP tasks
Hi, See the merged pipeline below On Dec 31, 2007 7:49 AM, Simon Pickering <[EMAIL PROTECTED]> wrote: > > > Thanks for your explanation. > > np > > > After having read the basic Gstreamer documentation, I understand > > better the sink pad concept of the mp3 task. In the application I am > > thinking about now, I don't need to look at the raw audio data decoded > > by the MP3 task as long as I can mix with it an other raw audio stream. > > I fact I need to mix a MP3 stream and a G711|G729|ILBC|AMR stream. You > > can see it as a kind of karaoke: mixing music (MP3) and voice (low > > bandwidth codec). The result should simply be available on the output > > jack. > > > > Did you think it is already doable now ? > > Yes, this is certainly doable already. I don't have any G7.11 data to > hand, but have tried it by mixing ogg and mp3 data (ogg using Tuomas > Kulve's gstreamer plugin which uses the pcm dsp sink). > > E.g. These two commands can be run is separate terminal windows and are mixed: > > gst-launch-0.10 filesrc location=20-16000HzExp5sec.mp3 ! dspmp3sink > > gst-launch-0.10 filesrc location=opensource.ogg ! application/ogg ! > tremor ! dsppcmsink gst-launch-0.10 filesrc location=20-16000HzExp5sec.mp3 ! dspmp3sink \ filesrc location=opensource.ogg ! application/ogg ! tremor ! dsppcmsink This way you can be sure that both pipelines are running on a single process. I'm not certain it is going to work as expected due to constraints with two audio streams running at the same time, but you can write as many source->filter->sink pipelines in a single gst-launch as you want. Thanks, Daniel. > > So this uses the mp3 sink and the pcm sink simultaneously. I imagine > it must be possible to start two separate sources in a single > gstreamer pipeline and then send them to separate sinks (i.e. as I've > done in the above example but all in one command). Anyone know how to > do this? > > > Simon > > > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: DSP vs. ARM endianness and struct packing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I did some experimentation a while back with DSP <-> ARM communication via mmap'ed memory, in my case I was working on using the DSP for rgb to yuv conversion. Another big gotcha to look out for is 64k boundaries. The DSP (at least in the 770) just can't naturally deal with object bigger than 64k, so you will get very bizarre results if you run into this limitation. - -- Buck -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG6tzNPrrWIMa4SMsRAkbuAJ95XfnsZicLMAs39V5CK0Dce7L62ACdF4ao ZW5B/cKDkPIQ1JG+XUcHwbA= =En3x -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Xvideo support for Nokia 770?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Siarhei Siamashka wrote: > On Tuesday 09 January 2007 20:59, Charles 'Buck' Krasic wrote: > >> Any chance the Xvideo support in the Bora 3.0 will turn up in a >> 770 OS? > > > I asked the same question on #maemo irc channel and daniels > explained that video scaling is done by gpu on N800, so probably > the same code can't be reused on 770: > https://mg.pov.lt/maemo-irclog/%23maemo.2007-01-08.log.html > > Actually I have been thinking about trying to implement Xvideo > support on 770 for some time already. Now as N800 has Xvideo > support, it would be nice to have it on 770 as well for better > consistency and software compatibility. As you may recall, I was considering this back in August/September. I tried a few things, and reported some of my findings to this list. The code for all that is still available here: http://qstream.org/~krasic/770/dsp/ > > I see the following possible options: > > 1. Implement it just using ARM core and optimize it as much as > possible (using dynamically generated code for scaling to get the > best performance). Is quite a straightforward solution and only > needs time to implement it. It is my impression that this might be the most attractive option. I noticed that TCPMP which seems to be the most performant player for the ARM uses this approach, and it is available under GPL, so it may be possible to adapt some of its code. In the long run, I would hope that integrating TCPMP scaling code into libswscale of the ffmpeg project might be the most elegant approach, since that seems to be the most performant/featureful/widel adopted open-source scaling code (but not yet on ARM). For mplayer, it works out of the box, since libswcale actually originated from mplayer, and only recently migrated to ffmpeg. > > 2. Try using dsp tasks that already exist on the device and are > used for dspfbsink. But the sources of gst plugins contain code > that limits video resolution for dspfbsink. I wonder if this check > was introduced artificially or it is the limitation of DSP scaler > and it can't handle anything larger than that. Also I wonder if > existing video scaler DSP task can support direct rendering [2]. I tried direct rendering in the above mentioned experimentation. I never got it to work exactly correctly, i.e. I could get images fragments on the screen, but they were not the whole image, and never in exactly the correct screen position. I suspected this was tied to the baroque memory addressing constraints of the DSP (e.g. 16bit data item limitations). I tried very hard to work around them but was not successful. I think the benefits of direct rendering may be a false temptation on the DSP anyway.My impression was that the DSP access to framebuffer memory slowed down the scaling algorithm tremendously, so it was actually faster to scale into DSP local memory, and then do a fast bulk copy to the FB, or to SDRAM on the ARM side.Plus you have all the AV synchronization headaches. I think these gains pale compared to the gain from just using the fb in YUV mode, and doing all the video stuff on the ARM side. Hence, option 1 seems to sound very attractive. > It would need to support arbitrary number of memory mapped buffers > for video output in order to avoid unnecessary memcpy, otherwise > performance will suffer. > > Maybe we can ask Nokia developers to provide some information about > the internals of these plugins. The most important questions are: * > What are the real capabilities of DSP based scaler, can it be used > for resolutions let's say up to 800x480? I doubt 800x480. The added quality benefit over 400x240 with pixel doubling in the fb is probably way to marginal to justify the effort. The DSP hardware doesn't seem to have any meaningful support for general scaling (beyond doubling). > * Where is the screen update performed after dsp has finished > scaling/converting video from mapped buffer to framebuffer? Is it > done on ARM side, or probably screen update can be also triggered > from DSP directly? I seem to have the rough impression from inspecting X code that ARM side does the final update (copy) to fb memory. I'm not 100% sure on that right now though. > * Is it possible to get direct rendering [2] support with existing > dsp tasks on 770? If not, would it be too hard to implement this > feature? * How are timestamps handled in dsp? Is it possible to > just send a one shot signal to dsp task for rendering video frame > from a mapped buffer as fast as possible? > > A brief dsp interface description would be welcome. Maybe some > questions may be trivial, but unfortunately I did not have much > time for a detailed walk through the sources in order to figure out > how this all works. If any
Re: [maemo-developers] Nokia's Linux-powered N800 Internet Tabletsneaks out early
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: >> Not that we're going to get one word out of a @nokia.com address >> for the time being...but they'd better not stop releasing FW >> updates and developing for the 770. Maemo isn't open enough for >> the community to maintain the software for the 770. >> > > The 770 with OS2006 is still supported by Nokia. OS2007 will not be > released for the 770. Unfortunately we are not at the point where > we can ship the same OS release for multiple hardwares, though we > are moving in that direction. > > Perhaps some kind of OS2006/OS2007 combination will turn out to be > practical for hacking on the 770, though again, an end-user ready > release is not in the cards. Herring and Sardine (Herring is synced > with OS2007/Maemo Bora) already give you Bora (and post-Bora) in > the limited context of the HAF. Let's see how much we can improve > on that. Any chance the Xvideo support in the Bora 3.0 will turn up in a 770 OS? - -- Buck -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFo+YaPrrWIMa4SMsRAsOSAKCS1pBVajOGKJQKv7gJwQIUwiyolACgpHk0 4nTDJHmB6xA67FPI3yXf09k= =zBAc -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Nokia's Linux-powered N800 Internet Tablet sneaks out early
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Great!3.0 sounds better all the time. - -- Buck Daniel Stone wrote: > > The X server now provides the standard Xv (X Video) extension, so > just use that instead, and things get a whole lot less complicated. > It's not as wildly quick as it should be at the moment, but that's > being actively worked on. > > Cheers, Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFoolMPrrWIMa4SMsRAgFDAKC/SglioSpkN2ydjdslbw9EWHBH8ACfUQUC hOD8U8dOWA3p3qU30ALW8KA= =cbiP -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Getting scratchbox CPU transparency working on the n770
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 My understanding is that it is not legal to redistribute the binary-only Nokia stuff.I base this on my read of the click-through license on http://www.maemo.org/downloads/d2.php, it quite appears clear to me that copying and redistribution are not allowed (I am not a lawyer and I do not work for Nokia). On the other hand, there is ample information about creating custom images on the maemo website, much of it provided by Nokia.This could be an indication that Nokia are at least open to the idea. Using at least some of the non-redistributable binary components would be necessary to make any custom image usable in any general sense (e.g. to use wifi).It would be interesting to get clarification from Nokia on this. I would suspect anyone who wants to deploy a custom solution based on the 770 would need to negotiate individually with Nokia to get permission for the binaries. Another approach to get at customized devices would be to write a script that starts from a device initialize to a stock image, and then both installs new code, and removes unwanted components. It's probably more hassle from a development, but maybe less pain than dealing with the lawyers. :) The overall situation between open and closed is quite mixed on the 770. Some details of how sound related stuff on the 770 work are out there, but scattered somewhat between the maemo website, mailing lists, etc. Perhaps the most salient information is as follows. The hardware side of audio is quite unconventional in the sense that it does not have a traditional separate sound chip, but instead uses the DSP in the OMAP processor to do most audio work. The lowest level details of this are handled by DSP code written by Nokia, and released in binary only (non-redistributable) fashion. My impression is that the licensing terms of this DSP code is unlikely to change anytime soon.This is certainly limiting for certain people interested in driver like development; e.g. there seems to be a lot of pent up frustration about the lack of bluetooth headset support, and this is one area where the lack of information about the DSP and hardware side of things in general makes it virtually impossible for anyone but Nokia to come up with a solution. On the brighter side, the ARM/Linux side of the sound software has undergone several transitions through the sequence of releases of the maemo platform. The most recent scirroco release is notable because it appears that most (all?) of the "linux-side" gstreamer code relating to the DSP has become open source. There has been and still is virtually no documentation to the 770 specific gstreamer elements, so the source code release is a major boon (thanks Nokia!). - -- Buck Arno Onken wrote: > Thanks for the quick reply! :) > > Yes, the wlan driver comes with the rootfs and so you can get sound > working by using binary files from the production image. But the > question was actually more about license issues, the freedom of the > software. Is it binary only or is the source available? Can you use it > for any purpose? And can you copy and redistribute (modfied) versions? > > Arno > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFdayHPrrWIMa4SMsRApIaAKC2z8uZu5ClPwJ1LZPX0N+JM63m0wCdGqxi MwVnIgiJy34ruQ4PVeuLSD0= =+6Hm -END PGP SIGNATURE- begin:vcard fn:Charles 'Buck' Krasic n:Krasic;Charles 'Buck' org:University of British Columbia;Department of Computer Science adr:;;201-2366 Main Mall;Vancouver;B.C.;V6T 1Z4;Canada email;internet:[EMAIL PROTECTED] title:Assistant Professor tel;work:(604) 822-5628 tel;fax:(604) 822-5485 tel;cell:(604) 313-9429 x-mozilla-html:FALSE url:http://www.cs.ubc.ca/~krasic/ version:2.1 end:vcard ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Getting scratchbox CPU transparency working on the n770
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The wlan does work on the developer image, so the driver must be there. :) For testing purposes, I was able to get sound working on the developer rootstrap by copying the /lib/dsp directory from the production image. There are instructions somewhere on the wiki about how to unpack the filesystem from the fiasco image, which you can use to get at that directory, or you can ssh into a 770 booted into the normal OS and copy them from there. - -- Buck Arno Onken wrote: > > I did not check it yet but I read somewhere that wlan-driver and > battery management are still non-free. Anything else? Besides sound > is not working and tons of log files are written. Any details on > attempts to run free-software only? > > Arno -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFdLBZPrrWIMa4SMsRAkyVAKCAX89zZSBSN75fC+yx3//n6u0mAwCdE6Lz 3i4XUwRWI9zLypt1qEuQVS0= =iDQB -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Suggestions for scirocco?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frantisek Dufka wrote: > Charles 'Buck' Krasic wrote: > >> Hi, >> >> I think it would be nice if in addition to a rootfs, there is a >> kernel that includes some of the extras that are useful for >> developers. The main example I am thinking of is NFS client >> support, so that the scratchbox CPU transparency feature is >> easier to setup (I think it was this way in Maemo 1.x, but I am >> not sure). >> >> - -- Buck > > > Could be solved by packaging additional modules, Familiar did this, > you can have kernel-modules-nfs package etc. Would be nice to have > most modules packaged like this and have depmod/modprobe on device > working. I'd vote against various precompiled kernels with > different combinations if it can be solved by modules. > > Or is there significant memory overhead for modules? > > Frantisek > > BTW, for precompiled NFS modules check this > http://www.internettablettalk.com/forums/showpost.php?p=25716&postcount=12 > > Sure modules would be fine too. Are those pre-compiled modules suitable for the kernel version that ships with maemo 2.1? In any case, my main concern is that the procedure for using scratchbox CPU transparency is currently severely hampered, and I have little hope that an inexperienced developer will realize that the documented procedure for enabling CPU transparency isn't working is because by default the 770 kernel does not have NFS client support. This really needs to be fixed. - -- Buck -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFbeVHPrrWIMa4SMsRArq3AKC+iKd5jtMVxthzeGR3j9CWxS8vzQCgkX5f iaJuqzshtkpTyTCzuttNL+s= =UxIC -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Suggestions for scirocco?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tran Van Hoang wrote: > Hi all, > > In an effort trying to make scirocco officially support scratchbox > apophis 1.x, we're also trying to make scirocco better if possible. > So if you would like to have any thing else supported, please say > it soon enough so we can at least try our best. > > REPOSITORY A sensible suggestion * Missing xserver-kdrive build-dep > packages like libxproto-composite libxproto-damage etc.. should be > available. > > Suggestions like "source for libosso-certman-dev should be > available" won't be supported. It's nokia-properietary code. But of > course any suggestion is welcome > > ROOTSTRAP/Rootfs * Are there any other tools/packages that you'd > like in rootstraps or rootfs? Hi, I think it would be nice if in addition to a rootfs, there is a kernel that includes some of the extras that are useful for developers. The main example I am thinking of is NFS client support, so that the scratchbox CPU transparency feature is easier to setup (I think it was this way in Maemo 1.x, but I am not sure). - -- Buck > > Thank you, BR, TranVan Hoang > > ___ maemo-developers > mailing list maemo-developers@maemo.org > https://maemo.org/mailman/listinfo/maemo-developers -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFbcgxPrrWIMa4SMsRAi7hAKCItAcmdZ78qHl+Vwbfksb/YDGUuQCeMWL9 2ex7vh1L6C1MZ7DexC7EhHQ= =3dTe -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Unresolved issues (Week 46)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 No, my dsp work was actually video related.I did reuse Siarhei Siamashka's mplayer code to decode/output mp3 directly, but that obviously doesn't help with speex. I'd suggest that the most practical approach for now would be to have an application that uses a speex dsp task to decode speex, and then takes the output from that speex task and routes it to an existing gstreamer plugin for pcm output. This may be suboptimal, as the data will cross the dsp gateway boundary twice more than necessary, but it still might retain most of the benefit of offloading speex work to the dsp.I mean were talking something like 64KB/s of extra copying in the worst case (?), which I don't think will be a very significant cost even on the 770's OMAP processor. The marginal benefit of persuing a zero copy solution (direct from dsp to sound) just probably isn't work the effort. Documentation for the software components of the 770 that use the dsp is virtually non-existent until now. Aside from the mp3 decoder, I think all of the other stuff has been basically unavailable to developers outside of those working on Nokia's closed source multimedia applications. On the bright side, the gstreamer plugins for these various pieces has been made open source in maemo 2.1. I wouldn't hold my breath on the dsp side of these plugins ever becoming open source (although I would wholeheartedly welcome it!). - -- Buck Simon Pickering wrote: > > >>> If you want something free, I'd suggest using our speex >> >> codec, which >> >>> is technically comparable, completely open, and has no known >>> patent issues. We don't have an omap dsp implementation, but it >>> has been ported to the various TI DSPs. >>> >>> http://speex.org/ >>> >>> -r >> >> I did quite a bit of experimentation with the 770 dsp back in >> late august. As a point of clarification, the dsp in the OMAP >> 1710 (used in the 770) is just a TI *C55x, *which is already >> supported by speex as far as I can tell. Thus, getting speex >> to work on the 770 should mostly be an issue of adapting the he >> exisiting speex C55x port to the build process using the free dsp >> tools, or TI's code composer; and writing appropriate wrappers to >> move data back and forth across the ARM to DSP boundary using the >> linux dsp gateway interfaces. >> > > There's still the problem of getting the DSP to output sound > directly though, is there not? Or did you work out what the > functions in the avs_kernel do (or bypass them completely)? > > > Simon > > ___ maemo-developers > mailing list maemo-developers@maemo.org > https://maemo.org/mailman/listinfo/maemo-developers -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFZgI8PrrWIMa4SMsRAtwtAKCewZZX7kvSYuXizfLAuKHcT840QACfb1p+ Ch8kmyDqxZveYbJbpPSfBC0= =ovMU -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Unresolved issues (Week 46)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralph Giles wrote: > > If you want something free, I'd suggest using our speex codec, > which is technically comparable, completely open, and has no known > patent issues. We don't have an omap dsp implementation, but it has > been ported to the various TI DSPs. > > http://speex.org/ > > -r I did quite a bit of experimentation with the 770 dsp back in late august. As a point of clarification, the dsp in the OMAP 1710 (used in the 770) is just a TI *C55x, *which is already supported by speex as far as I can tell.Thus, getting speex to work on the 770 should mostly be an issue of adapting the he exisiting speex C55x port to the build process using the free dsp tools, or TI's code composer; and writing appropriate wrappers to move data back and forth across the ARM to DSP boundary using the linux dsp gateway interfaces. I'd be happy to try and help anyone who might be interested in attempting such an endeavor. - -- Buck > ___ maemo-developers > mailing list maemo-developers@maemo.org > https://maemo.org/mailman/listinfo/maemo-developers -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFZM5PPrrWIMa4SMsRAqMOAKCq0OqKRvgXwlR/Ws8FWm1ail2JbACfVLGN gxOIllBieMtH4goXOW4sfs4= =3yoS -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Getting scratchbox CPU transparency working on the n770
Just to followup.I have CPU transparency working with 2.1 now. The
general procedure I followed was basically the same as described in my
previous message to the list back when 2.0 was released.
http://maemo.org/pipermail/maemo-developers/2006-June/004242.html
The high-level description is as follows:
1) Install v2.1 production image (did this to make sure kernel, etc.
were compatible)
2) Install v2.1 developer fs (this took me a while due to problems
with broken links on the website)
3) Rebuild the 2.6.16 kernel in order to enable NFS support needed by
CPU transparency
- generally followed the kernel compilation howto from the
maemo wiki. I've added some comments to that wiki page indicating what
adjustments I had to make to the procedure.
4) Reboot 77 and test... it worked. :)
I hope this information might be of some help to others.
-- Buck
Charles 'Buck' Krasic wrote:
> I'm a CPU transparency user too. I think I hit the same issue back
> when 2.0 was originally released.See the following post for reference:
>
> http://maemo.org/pipermail/maemo-developers/2006-June/004242.html
>
> Sounds to me like the issue remains the same in 2.1. I am about to
> give it a try with 2.1, so I guess I will see.
>
> -- Buck
>
> Carl Worth wrote:
>
> > A while back I managed to get scratchbox CPU transparency working
> > on a Nokia 770. It's extremely cool voodoo, and very handy.
>
> > I just ran through the process again tonight, and took careful
> > notes on what I had to do. Some parts of it were a bit painful,
> > (and some even got a bit worse than the last time I tried). I've
> > attached my notes to myself below, (maybe there's some good wiki
> > fodder in here, but I don't know---a lot of it is redundant with
> > other more thorough pages scattered about the wiki already).
>
> > The question I have is whether some of this couldn't be made much
> > simpler in the "standard" latest software editions. In the
> > instructions below, I start with an older "Internet Edition 2006"
> > install (to get a kernel that works) and then also drop back to a
> > "developer" root filesystem to get the check boxes for UsbNet and
> > CPU transparency.
>
> > This is really handy stuff, but it's a shame to give up all the
> > fancy new software on this gadget in order to get at it. How hard
> > would it be to be able to add this support to a recent install? For
> > example, could that be made just a matter of a couple of extra
> > packages?
>
> > As for the kernel issues, with the 2.2006.39-14 release I wasn't
> > able to get "modprobe nfs" to work. It complained about something
> > that made me think depmod needed to be run, but then depmod didn't
> > work at all. I didn't explore further at that point but instead
> > just dropped back to 1.2006.26-8 since I knew I had gotten this all
> > to work at some point in the past.
>
> > Anyway, are other people doing things like this? If so, how are you
> > going about it? Are you making custom images, etc?
>
> > -Carl
>
> > First, let's get that n770 into a known state. This requires
> > downloading a flasher binary and a software image. The flasher
> > binary (for several platforms) is available here:
>
> > http://www.maemo.org/downloads/d3.php (With annoying click-through
> > license)
>
> > I used flasher-2.0, and that may be a requirement.
>
> > Next, you'll need an image to flash. Get the following file:
>
> > SU-18_2006SE_1.2006.26-8_PR_F5_MR0_ARM.bin from:
> > http://www.maemo.org/downloads/nokia_770 (Again, with annoying
> > click-through)
>
> > Don't be tempted by the newer 2.2006.39-14 release---the kernel it
> > comes with doesn't come with the necessary kernel modules.
>
> > So, now flash that image by following these steps:
>
> > 1. Power off the n770 (hold down the power button on top for a few
> > seconds)
>
> > 2. Connect it to your host with the provided USB cable
>
> > 3. Run the following on your host using the files downloaded above:
>
>
> > sudo ./flasher-2.0 -f -R -F
> > SU-18_2006SE_1.2006.26-8_PR_F5_MR0_ARM.bin
>
> > NOTE: At this point, the command will appear to hang with what
> > looks like an error message, ("Suitable USB device not found,
> > waiting"). This is normal and expected, just keep going.
>
> > 4. Press the power button on the n770 for a second or so.
>
> > The flashing should now proceed with progress indicators on both
> > sides, and the n7
[maemo-developers] Missing maemo downloads (e.g. developer root fs)?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, The following files appear to be empty: http://maemo.org///downloads/d1.php http://maemo.org///downloads/d2.php http://maemo.org///downloads/d2.php Are Nokians aware of this?I want to try the 2.1 developer fs, but it doesn't seem available because of the above broken links. - -- Buck -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFXiqqPrrWIMa4SMsRAp5PAJ4txzF8fb7HklUhsn+sFdJQMWo0JACeKmZy ITu7ThtU0XsluS2yJ7awwlU= =lUax -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Getting scratchbox CPU transparency working on the n770
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm a CPU transparency user too. I think I hit the same issue back
when 2.0 was originally released.See the following post for reference:
http://maemo.org/pipermail/maemo-developers/2006-June/004242.html
Sounds to me like the issue remains the same in 2.1. I am about to
give it a try with 2.1, so I guess I will see.
- -- Buck
Carl Worth wrote:
> A while back I managed to get scratchbox CPU transparency working
> on a Nokia 770. It's extremely cool voodoo, and very handy.
>
> I just ran through the process again tonight, and took careful
> notes on what I had to do. Some parts of it were a bit painful,
> (and some even got a bit worse than the last time I tried). I've
> attached my notes to myself below, (maybe there's some good wiki
> fodder in here, but I don't know---a lot of it is redundant with
> other more thorough pages scattered about the wiki already).
>
> The question I have is whether some of this couldn't be made much
> simpler in the "standard" latest software editions. In the
> instructions below, I start with an older "Internet Edition 2006"
> install (to get a kernel that works) and then also drop back to a
> "developer" root filesystem to get the check boxes for UsbNet and
> CPU transparency.
>
> This is really handy stuff, but it's a shame to give up all the
> fancy new software on this gadget in order to get at it. How hard
> would it be to be able to add this support to a recent install? For
> example, could that be made just a matter of a couple of extra
> packages?
>
> As for the kernel issues, with the 2.2006.39-14 release I wasn't
> able to get "modprobe nfs" to work. It complained about something
> that made me think depmod needed to be run, but then depmod didn't
> work at all. I didn't explore further at that point but instead
> just dropped back to 1.2006.26-8 since I knew I had gotten this all
> to work at some point in the past.
>
> Anyway, are other people doing things like this? If so, how are you
> going about it? Are you making custom images, etc?
>
> -Carl
>
> First, let's get that n770 into a known state. This requires
> downloading a flasher binary and a software image. The flasher
> binary (for several platforms) is available here:
>
> http://www.maemo.org/downloads/d3.php (With annoying click-through
> license)
>
> I used flasher-2.0, and that may be a requirement.
>
> Next, you'll need an image to flash. Get the following file:
>
> SU-18_2006SE_1.2006.26-8_PR_F5_MR0_ARM.bin from:
> http://www.maemo.org/downloads/nokia_770 (Again, with annoying
> click-through)
>
> Don't be tempted by the newer 2.2006.39-14 release---the kernel it
> comes with doesn't come with the necessary kernel modules.
>
> So, now flash that image by following these steps:
>
> 1. Power off the n770 (hold down the power button on top for a few
> seconds)
>
> 2. Connect it to your host with the provided USB cable
>
> 3. Run the following on your host using the files downloaded above:
>
>
> sudo ./flasher-2.0 -f -R -F
> SU-18_2006SE_1.2006.26-8_PR_F5_MR0_ARM.bin
>
> NOTE: At this point, the command will appear to hang with what
> looks like an error message, ("Suitable USB device not found,
> waiting"). This is normal and expected, just keep going.
>
> 4. Press the power button on the n770 for a second or so.
>
> The flashing should now proceed with progress indicators on both
> sides, and the n770 should reboot when finished. You can now play
> around with the applications installed for a bit, (since the next
> step will wipe them out).
>
> The applications have a lot of polish, but this image doesn't
> include a couple of things we really want, (USB networking, and
> scratchbox CPU transparency), so we're going to install a
> "Developer Image" that misses a lot of applications and polish, but
> lets us get some work done.
>
> So, now download the following:
>
> Maemo_Dev_Platform_v2.1_armel-rootfs.jffs2 from:
> http://www.maemo.org/downloads/d1.php (A third, annoying
> click-through(!))
>
> Then repeat the flashing process, but the details of the flash
> command are different since this is just a root filesystem, not a
> "fiasco" image with kernel, initfs, rootfs, etc. So the steps once
> again are:
>
> 1. Power off n770
>
> 2. Connect it
>
> 3. Run the following command:
>
> sudo ./flasher-2.0 -f -R -r
> Maemo_Dev_Platform_v2.1_armel-rootfs.jffs2
>
> 4. Power on the n770 and watch the flashing proceed
>
> If you had played with the previous software install at all, then
> you'll probably notice a few differences. Such as a big black SDK
> when booting instead of the two hands, a drab gray theme instead of
> the flashy orange stuff, and many fewer applications installed.
>
> But the important difference is a little icon on the top of a
> wrench in front of a blue USB symbol. Click on that and make sure
> that UsbNet is selected rather than MMC and also that the "Enable
> cpu-transparency" option is selected.
>
> From here on out the n
Re: [maemo-developers] Re: Answer discovered @ http://qstream.org/viewcvs/trunk/qvid/src/video_out/maemo_dsp_yuv/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The codec is a homegrown variant of MPEG-4 I call SPEG. Basically SPEG adds fine granularity SNR scalability to MPEG-4. SPEG is part of a larger overall project on quality-adaptive video streaming. The SPEG implementation is derived from from the xvid code base. You can find all of my code, including the modified xvid, and the rest of the streaming system, along with instructions on how to build the system at http://qstream.org. For the last month or so, I have been working on porting the qstream client to the Nokia 770. The actual streaming video part of the port is working very well now. In terms of actual video/streaming, I think it already does much better than the bundled player. Before I actually cut the first release, it needs some more testing, as well as all of the hildon gui stuff (which I plan to do with PyGtk), and proper deb packaging. I hope to get that done in a few weeks. If you are actually serious about trying the codec, I'd be happy to try and help you in any way I can. - -- Buck Ed Okerson wrote: > What video codec are you trying to use? Maybe I can try my hand at > it. > > Ed > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFE+JlwPrrWIMa4SMsRAtUyAKDjitFiEyz21ukYGgvMwKN7M4bGpgCZAc7D Ri3ZbFaq7TPBPVvSGT07nbY= =rMw7 -END PGP SIGNATURE- begin:vcard fn:Charles 'Buck' Krasic n:Krasic;Charles 'Buck' org:University of British Columbia;Department of Computer Science adr:;;201-2366 Main Mall;Vancouver;B.C.;V6T 1Z4;Canada email;internet:[EMAIL PROTECTED] title:Assistant Professor tel;work:(604) 822-5628 tel;fax:(604) 822-5485 tel;cell:(604) 313-9429 x-mozilla-html:FALSE url:http://www.cs.ubc.ca/~krasic/ version:2.1 end:vcard ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Answer discovered @ http://qstream.org/viewcvs/trunk/qvid/src/video_out/maemo_dsp_yuv/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I didn't know how easy using the LCD hardware support for YUV was when I started working on this. Later on, when I did figure that out (when a Nokian finally posted something to the list), I revised my DSP code to do scaling only (YUV->YUV). Even that was too slow on the DSP. One issue I never resolved was how to get the DSP to write directly to the framebuffer memory.I got it partially working, but I think I was hitting some variant of the 64k issue (see next paragraph). So in the end, I reverted to having the DSP copy the scaled video to memory shared with the MPU, and then the MPU would copy it to the framebuffer. Although the DSP tools include a C compiler, there are issues that make porting existing C code far from trivial. For starters, the fact that byte size on the DSP is 16 bits makes for a lot of grief. The other issue that kicked me in the teeth is that the DSP can not deal with data objects > 64kbytes (1 DSP page). Actually, my impression is that this is not true anymore of the OMAP 1710 in the 770, but the free DSP tools are quite old and actually targetted to an older revision of the DSP, so the C compiler does not contain later revisions that removed that limitation. I surmise that if I purchased an up to date CCS, this would have been fixed. In hindsight, I should probably have done that. As it was, I had to write some very ugly code to work around that 64k issue.The workaround code probably is not without performance penalty either. My code is available in the maemo_dsp_yuv in case anyone wants to suggest how it might be improved.My impression is that truly peformant DSP code requires a lot of actual expertise on the DSP architecture, including the ability to hand tune DSP assembly for the critical code. I don't have the time to learn how to do that. Since I wasn't able to get a relatively simple task like YUV->YUV scaling to run with adequate speed on the DSP, I'm far from optimistic that porting my video codec to the DSP will be a fruitful exercise. - -- Buck Ed Okerson wrote: > If you have gone so far as to implement the YUV to RGB conversion, > why not go ahead and implement your codec on the DSP? You will get > much better throughput. For that matter why not send the YUV > directly to the display controller and let it do the RGB conversion > in hardware? > > Ed > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFE+IT9PrrWIMa4SMsRAuBJAJ9qcUq7LYEFEMYJqmuLAajWuUAneQCgosWr mtCyGPj8AdBJRuKIGUnMYqQ= =5qMN -END PGP SIGNATURE- begin:vcard fn:Charles 'Buck' Krasic n:Krasic;Charles 'Buck' org:University of British Columbia;Department of Computer Science adr:;;201-2366 Main Mall;Vancouver;B.C.;V6T 1Z4;Canada email;internet:[EMAIL PROTECTED] title:Assistant Professor tel;work:(604) 822-5628 tel;fax:(604) 822-5485 tel;cell:(604) 313-9429 x-mozilla-html:FALSE url:http://www.cs.ubc.ca/~krasic/ version:2.1 end:vcard ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Answer discovered [ CORRECTION ]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Doh, I hit send too fast. The correct link is: http://qstream.org/~krasic/770/dsp/ - -- Buck Charles 'Buck' Krasic wrote: > Hi, > > I spent a lot of time searching for freely available tools and > information about the dsp. > > Maybe I can help you avoid duplicating my effort. I've put together > the various bits I collected here: > > http://qstream.org/770/dsp/ > > Mind the various readme files about copyrights, I re-distribute these > only as a convenience. Note, they are all freely available from > their original sources. > > -- Buck > > To help save you the time of duplicating my effort > > Shae Matijs Erisson wrote: > > >Ok, sorry to bother you. Someone else on #maemo turned up this url > >http://qstream.org/viewcvs/trunk/qvid/src/video_out/maemo_dsp_yuv/ > >And that includes the answer to my question. > > > ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFE+GYfPrrWIMa4SMsRAoPnAJ9cG28OuiogIZSsCa7JwkufgllWwQCgzSuJ vNKvgV/Y6eH3XIOBV4LUOEQ= =4z8T -END PGP SIGNATURE- begin:vcard fn:Charles 'Buck' Krasic n:Krasic;Charles 'Buck' org:University of British Columbia;Department of Computer Science adr:;;201-2366 Main Mall;Vancouver;B.C.;V6T 1Z4;Canada email;internet:[EMAIL PROTECTED] title:Assistant Professor tel;work:(604) 822-5628 tel;fax:(604) 822-5485 tel;cell:(604) 313-9429 x-mozilla-html:FALSE url:http://www.cs.ubc.ca/~krasic/ version:2.1 end:vcard ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Re: Answer discovered @ http://qstream.org/viewcvs/trunk/qvid/src/video_out/maemo_dsp_yuv/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I spent a lot of time searching for freely available tools and information about the dsp. Maybe I can help you avoid duplicating my effort. I've put together the various bits I collected here: http://qstream.org/770/dsp/ Mind the various readme files about copyrights, I re-distribute these only as a convenience. Note, they are all freely available from their original sources. - -- Buck To help save you the time of duplicating my effort Shae Matijs Erisson wrote: > Ok, sorry to bother you. Someone else on #maemo turned up this url > http://qstream.org/viewcvs/trunk/qvid/src/video_out/maemo_dsp_yuv/ > And that includes the answer to my question. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFE+GWEPrrWIMa4SMsRAkyTAKDie4CbL59CXgN/V9MQ20JwBrT2FACfXt1C OUXKfOrLRXMv3XFnZk7QmdQ= =xzZ1 -END PGP SIGNATURE- begin:vcard fn:Charles 'Buck' Krasic n:Krasic;Charles 'Buck' org:University of British Columbia;Department of Computer Science adr:;;201-2366 Main Mall;Vancouver;B.C.;V6T 1Z4;Canada email;internet:[EMAIL PROTECTED] title:Assistant Professor tel;work:(604) 822-5628 tel;fax:(604) 822-5485 tel;cell:(604) 313-9429 x-mozilla-html:FALSE url:http://www.cs.ubc.ca/~krasic/ version:2.1 end:vcard ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] libXv and xvimagesink
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Corentin, There has been some discussion of this issue on this mailing list. You may want to search the archives. To summarize the situation briefly: There is no Xv implementation on the 770. The Xserver includes the generic Xv layer implementation, and the libxv library exists, but they do nothing for you... if your application uses the Xv API, it will find "no adapters" because the meat of an Xv implementation is completely absent. The two core functions of Xv as far as most applications are concerned are yuv->rgb conversion and scaling. For the yuv->rgb part, it is possible to allow the 770 lcd hardware to display yuv directly.This is done using the Linux fb layer, bypassing the xserver entirely.The is all on the arm side, and does not involve the DSP at all. I have done this in my code and it is a major improvement. Check out the mailing list archives, and look at the omapfb.h file for mor information on this. For the yuv scaling, your application needs to do it itself, or perhaps you can get gstreamer to help you. I investigated a solution to do it on the DSP. I got it working but the performance was far from acceptable. It was several times slower than doing it on the ARM, and more importantly, it wasn't even fast enough to achieve real time (i.e. ~ 30fps). My plan was to combine this with the YUV fb support to implement proper xv support for the xomap server, but with the very poor performance, I gave up. Hope this helps, - -- Buck Corentin BARON wrote: > Hello all, > > I'd like to know if anyone managed to install libXv and xvimagesink > on the 770 or the same with SDL. That would be very helpful for > us. > > Thx in advance, Corentin. > > > > > -- > > > ___ maemo-developers > mailing list maemo-developers@maemo.org > https://maemo.org/mailman/listinfo/maemo-developers -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFE8z1dPrrWIMa4SMsRAvicAKDlEctzdy9uGF/WwW6gY7e5nG96nwCeJ4JD DhgOBFiUZ9csY53hEjEk9vk= =YtDx -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Re: YUV formats, Re: Building xserver from source [was Bluetooth Mice]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Frantisk, Thank you for sharing that information! (Jussi too). Using 420 may bring some additional improvement over 422. I hope to integrate that into my code later today. The YUV framebuffer support has been a major progress for my player. Sadly I don't exactly have a hello world. You may look inside the following file for how I use the ioctls: http://qstream.org/viewcvs/trunk/qvid/src/video_out/qvid_video_out.c?view=markup I'd also suggest you look at the following which helped me start: http://maemo.org/lxr/source/osso-af-utils/src/fb-progress.c If you actually went to the trouble to build my whole project, this is the program I used to do most basic testing on the 770 (as close to a hello world as I have): http://qstream.org/viewcvs/trunk/qvid/src/avi_play/test_yuv.c?view=markup My enthusiasm for implementing Xvideo in xserver-omap has faded again. I have concluded that writing directly to the framebuffer from the application is the most efficient way to go. It has the least memory copies, and the least context switches. Also, as I told Siarhei, I spent a whole weekend on this stuff, and got a scaler implemented and working on the DSP, but it turned out to be many times slower than just doing the scaling on the ARM side. This may be partly do to slow memory transfers (ARM -> DSP + DSP -> ARM), but my mainly I think implementing even basic algorithms on the DSP really needs major optimization to get good performance. I only had the time to implement the algorithm using the DSP C compiler. I just don't have expertise in DSP to do assembly level optimization. I was communicating with the DSP directly from my application, and did not start any actual xserver hacking. Given that image scaling YUV->YUV on the ARM is reasonably fast, I'd suggest the most important use for the DSP is audio decoding.If somebody would just discover/reveal a little more information about the gstreamer mp3 element, it would help so much. Particularly how/if the element supports reporting an accurate time position, to allow the ARM side to keep the video in sync. Without that, I'm sticking to esound output in my player right now. If anyone is interested my DSP YUV code, they can have a look here: http://qstream.org/viewcvs/trunk/qvid/src/video_out/maemo_dsp_yuv/mmap.c?view=markup The arm side of things is in the qvid_video_out.c file above. Cheers, - -- Buck Frantisek Dufka wrote: > > Hi Buck, > > got also a mail from Siarhei Siamashka: "I have seen a user > 'buck68' at #maemo irc channel the day before yesterday and he also > tried to find information about using YUV colorspace and accessing > framebuffer from DSP (for making libxv). He said he had figured out > YUV422 maemory layout, but had troubles with YUV420." > > Looks like both persons are you so here is a piece of infromation I > got recently > > [EMAIL PROTECTED] wrote: >>> So with some packed format it is not bad. Can you say which >>> packed format it uses exactly (for both 422 and 420 modes)? >> >> Here they are: >> >> YUV422 format is packed and the memory layout is: >> >> U11 Y11 V11 Y12 U13 Y13 V13 Y14 ... U21 Y21 V21 Y22 >> U23 Y23 V23 Y24 ... >> >> YUV420 format is packed and the memory layout is: >> >> U11,12,21,22 Y11 Y12 U13,14,23,24 Y13 Y14 ... V11,12,21,22 >> Y21 Y22 V13,14,23,24 Y23 Y24 ... >> > > I hope it helps you with hacking libxv. I'll try to hack direct fb > access for YUV into mplayer but it may take a while. If you already > have some hello world working examples for testing those ioctls I > am definitely interested :-) > > Frantisek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFE60CTPrrWIMa4SMsRAvyXAKC1Zl3fDeoSzS8mL6IDdkpbbgiHkwCgmZGf F1Q2P9CaNOF000OoYK4fiik= =Yklo -END PGP SIGNATURE- begin:vcard fn:Charles 'Buck' Krasic n:Krasic;Charles 'Buck' org:University of British Columbia;Department of Computer Science adr:;;201-2366 Main Mall;Vancouver;B.C.;V6T 1Z4;Canada email;internet:[EMAIL PROTECTED] title:Assistant Professor tel;work:(604) 822-5628 tel;fax:(604) 822-5485 tel;cell:(604) 313-9429 x-mozilla-html:FALSE url:http://www.cs.ubc.ca/~krasic/ version:2.1 end:vcard ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] problem with dspmp3sink (was: problem with gstreamer and dsppcm)
Siarhei, Just in case you have not done it already, enabling swap in your device can help a lot to prevent out-of-memory errors.Maybe this will help with mplayer/gstreamer stability. I personally suspect a design flaw in the current Linux VM subsystem. I've observed that if an application allocates memory rapidly, the kernel may fail to reclaim pages quickly enough from the page and buffer caches (they are only caches after all), so it actually denies the allocation request. For example, with zero swap, on a machine with 1G of ram, and >500M of it pseudo-free (used by caches), I've seen moderate allocations fail--like when starting an application like firefox.Enabling even a small amount of swap seems to dramatically change this behaviour. -- Buck Eero Tamminen wrote: >Hi, > > > >>Also I noticed that gstreamer is not very reliable, at least when using >>it from mplayer. It can freeze or reboot the device sometimes. That's not >>something that should be expected from high level API. If I detect some >>reliable pattern in reproducing these bugs, I'll report it to bugzilla >>for sure. But right now just using mplayer and lots of seeking in video >>can cause these bugs reasonably fast. >> >> > >First I would recommend using just "top" to see whether mplayer >is either: >- Leaking memory >- Otherwise using too much memory >Either by itself or forcing gstreamer to do that. > >If that is the case, the bug is in the mplayer (or gstreamer (plugin)) >and it needs to be fixed. For debugging the leaks, I would recommend >using Valgrind on x86. > > > - Eero > >PS. The applications in the device have been done so that they integrate >into the the device memory management framework; if they have dynamic >or large memory usage, before doing large allocs, they check whether >system has enough memory for those, they react to system low memory >notifications etc. > >If an application forces the kernel to the OOM (out of memory) >situation, it will by default kill the application requesting >memory. However, if mplayer is run as root, its killing is >avoided (note most of the framework processes are run as normal >user). Also, if you're using Desktop while mplayer triggers >device OOM, it's Desktop using memory and kernel might kill it >(which reboots the device). > >FYI: Only way to handle OOM correctly is to avoid triggering it, >trying something "fancy" (in kernel) in that situation is AFAIK >wraught with deadlocks. > >_______ >maemo-developers mailing list >maemo-developers@maemo.org >https://maemo.org/mailman/listinfo/maemo-developers > > begin:vcard fn:Charles 'Buck' Krasic n:Krasic;Charles 'Buck' org:University of British Columbia;Department of Computer Science adr:;;201-2366 Main Mall;Vancouver;B.C.;V6T 1Z4;Canada email;internet:[EMAIL PROTECTED] title:Assistant Professor tel;work:(604) 822-5628 tel;fax:(604) 822-5485 tel;cell:(604) 313-9429 x-mozilla-html:FALSE url:http://www.cs.ubc.ca/~krasic/ version:2.1 end:vcard ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Building xserver from source [was Bluetooth Mice]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm very interested in the fact that you were able to rebuild the xserver and run it. I found the build instructions in your http://thelemming.org.uk/maemo/btmice/maemo_mouse_readme.txt file. Thanks! Can anyone comment on whether running such an X server on the 770 will have any significant missing features or problems relative to the official xserver-omap distributed by Nokia? I am among those that would very much like to see a working Xvideo extension on the 770.Jussi Laako's recent comments make me hopeful that this could be a feasible undertaking. A little guidance from Nokians would be immensely helpful here. Can we expect an XVideo implementation (or some other substitute) from Nokia anytime soon? If not, can you at least comment on whether you see any fundamental technical problem that would prevent using the YUV support in the fb driver to implement Xvideo in xserver-kdrive? I started to try an alternate approach, to implement a general RGB->YUV converter in the DSP, but that has been very slow going. I'm not an expert on DSP programming, and there seem to be lots tricky issues. The 16 bit byte thing is brutal.Pointer arithmetic in the DSP C compiler seems completely broken. Memory constraints are also crazy... it was nasty just being able to mmap() more than 64k using the dsp gateway.In short, it is a b**ch. I had considered attempting Xv first, but the amount of missing information dissuaded me. Given the grief associated with developing for the DSP, I'm inclined to reconsider. - -- Buck Gareth Bailey wrote: > Hello, > > I've recently been working on getting a bluetooth mouse to work > with the 770. I have somthing which now works however it's not > entirely pretty and unfortunatly needs modification to the kernel > and the xserver. For any one who's interested here's what I did to > get it working: > > Firstly it helps if you can see a cursor, the cursors on the 770 > are just themed to be transparent so commenting the line reading > 'Inherits=xcursor-transparent' in > /home/user/.icons/default/index.theme" will get them back. > > I then tried to use a bluetooth mouse straight off just doing a > "hidd --connect" with no luck. Next I had a dig arround in the > xserver source code and found that support for the either touch > screen or mouse was enabled at compile time so I switched it back > to using the mouse recompiled and tested, this worked well enough > for the mouse but the touchscreen obviouly no longer worked > correctly. > > My next step was to try to change the device driver for the touch > screen to behave more like a mouse. I took this step because at > first thought there is a problem in that the device files for the > mice are not created until they are connected to the 770 this means > that you must use /dev/input/mice to get input from the mice. > This is a problem since the touch screen also reports to > /dev/input/mice so my initial thought was to change the touch > screen to actually behave like a mouse. I got somewhere near > working with this but the driver got out of sync with the xserver > very quickly and was unuseable. > > Incidentally why does the touch screen report to a mouse file when > it doesn't behave like a mouse? This seems strange to me. Does > anyone know of a way to make it report just to a /dev/input/event* > file? Or have any infomation on how the input system reports to > the /dev/input/mouse* files so it could be disabled in the driver? > I couldn't work it out from the source and could find no > infomation/documentation regarding how evdev/mousedev work. > Anyway... > > Next I tried to modify the xserver to use Tslib for > /dev/input/event2 (the touch screen) and the mouse driver for > /dev/input/mice. I got this working but since the touchscreen also > reports to /dev/input/mice I had to disable the absolute coordiate > reporting in mousedev in the kernel. Not entirly pretty but it > works. > > Instructions and files needed for trying or building it are at > http://thelemming.org.uk/maemo/btmice/ > > Opinions, comments, feed back, sugestions on different/'nicer' > aproaches to this, are very welcome and wanted! Hope someone finds > it interesting/useful. > > Thanks for reading, ___ > maemo-developers mailing list maemo-developers@maemo.org > https://maemo.org/mailman/listinfo/maemo-developers -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFE5Jo0PrrWIMa4SMsRAkPnAJ9Y/xQY6veCMsJNKQFsmXlO7Hro7wCgsKNz fGuZ7m1arvcRC7rew1HWbTw= =Q5QF -END PGP SIGNATURE- begin:vcard fn:Charles &#
Re: [maemo-developers] Unable to get access to Nokia 770 for
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jonathan Matthews-Levine wrote: > On 05/08/06, Miklos Tomka <[EMAIL PROTECTED]> wrote: > >> Thank you for all the great ideas. >> >> Unfortunately they do not work very well. >> >> Tigerdirect does not carry the unit any more; ebay could work, >> but most units are "used" and I would like to make a demo to my >> client with a new (looking) unit... > > > How about paying for a PO Box or forwarding shipping address in the > US? > > Jonathan > Is shipping from a US vendor out of the question? outpost.com (Fry's) carries the 770, and they will ship to Canada. Dunno if you will have to pay outrageous brokerage fees though... - -- Buck -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFE1PjRPrrWIMa4SMsRAqA7AKDK8/Oa6EsYOs9pGMnY+at4ksX7QACfRq0o wAeRJu/YNXqw3np6q7f26lY= =5rLU -END PGP SIGNATURE- begin:vcard fn:Charles 'Buck' Krasic n:Krasic;Charles 'Buck' org:University of British Columbia;Department of Computer Science adr:;;201-2366 Main Mall;Vancouver;B.C.;V6T 1Z4;Canada email;internet:[EMAIL PROTECTED] title:Assistant Professor tel;work:(604) 822-5628 tel;fax:(604) 822-5485 tel;cell:(604) 313-9429 x-mozilla-html:FALSE url:http://www.cs.ubc.ca/~krasic/ version:2.1 end:vcard ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Alsa on IT2006 beta
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Look for my earlier post to the list. Summary: the 770 kernel is linux-2.6.16-omap1 which does have generic ALSA, but not specific support for the 770. There was a patch posted to the linux-omap-open-source list which was supposed to enable the AIC23 ALSA driver for the 770. I buillt a kernel with that patch and installed it on my 770.I did get it to make sound, but it was not at the right speed, so I think the driver would need some work. As far I can tell, the 2.0 beta definitely does not provide ALSA support for the built-in sound. - -- Buck Steve Landers wrote: > G'day, > > I'm currently porting a Fluidsynth based program to the n770 and > notice that the Alsa driver appears to be missing from IT2006 beta. > > > No big deal, except I can't seem to regress my n770 to the previous > OS release - Nokia_770_SE2005_5_2006_13_7, which does have the > Alsa drivers. When flashing I get a message "Unsupported board (id > = 0x)" > > So, I have a few questions - are the plans for alsa support to be > re-added to IT2006? - does anyone have the alsa driver built as a > module that can be added to IT2006? - can anyone offer insight as > to why I can no-longer reflash the n770? > > Many thanks > > Steve > > -- Steve Landers Software Design Solutions > Digital Smarties [EMAIL PROTECTED] Perth, > Western Australia DigitalSmarties.com > > ___ maemo-developers > mailing list maemo-developers@maemo.org > https://maemo.org/mailman/listinfo/maemo-developers -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEms3HPrrWIMa4SMsRAkYWAJ4uhBaFn7eMQv19XPD/tryNMnD3pwCgpwo4 sJy4St1irtGvn85nCsNs+kc= =i6Fz -END PGP SIGNATURE- begin:vcard fn:Charles 'Buck' Krasic n:Krasic;Charles 'Buck' org:University of British Columbia;Department of Computer Science adr:;;201-2366 Main Mall;Vancouver;B.C.;V6T 1Z4;Canada email;internet:[EMAIL PROTECTED] title:Assistant Professor tel;work:(604) 822-5628 tel;fax:(604) 822-5485 tel;cell:(604) 313-9429 x-mozilla-html:FALSE url:http://www.cs.ubc.ca/~krasic/ version:2.1 end:vcard ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] [PATCH] board-nokia-770.c: Add missing alsa platform driver code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I checked the mailing list archive, and I do not see any answer regarding Mika's alsa patch for alsa and the 770. Since Nokia released the 2.0 beta for 770, I hoped Nokia would have ALSA support enabled, but it seems not. So I went ahead and rebuilt the Nokia 2.6.16-omap1 kernel with Mika's ALSA patch (http://linux.omap.com/pipermail/linux-omap-open-source/2006-April/006868.html), installed the kernel, and booted. Low and behold the OMAP_ALSA card appears in /proc/asound/cards on the 770! After this, I build the libasound2 package in scratchbox (using ubuntu breezy package) and alsa-utils. libasound2 built and installed ok on the 770. alsa-utils would build, but not install because of package dependencies. So anyway, I just copied the aplay binary to the 770. So, it seems to play some wav files, but not at the correct speed; i.e. a 44100 Hz .wav file sounds very slow on the 770. I found a 22 KHz wav and it sounded almost right. So I'm guessing the 770 is playing at 16KHz. Can any Nokia people comment, will we have ALSA in 2.0? I for one would be really happy to see it. - -- Buck -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEkgrZPrrWIMa4SMsRAtY7AJ91hyW6s9uulFna70h9vUx/J5eeygCgrt02 lL87GqV5242tn5CaS3a1xgs= =HJqg -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] WLAN reciever and battery.
I've read several research papers that claim that WLAN power consumption makes the biggest jump from completely off to online, and that the incremental power consumption between passive online (mainly receiving) and active online (transmitting) is not nearly as large. This is why TDMA schemes may have major advantages for power consumption, they have more opportunity to turn the radio completely off. -- Buck George Farris wrote: Has anyone information about battery capacity/current draw and WLAN connectivity when your presence is set to online? I would think that only the receiver would be active and so battery life would be much longer than when browsing. Or is it the case with the 770 that as soon as the WLAN interface is enabled, it draws much more current, regardless of transmission? I suppose if I had an ammeter I could measure it, however, I don't have one. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] CPU transparency: no NFS support in 2.6.15-omap1? (resolved)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It turns out I made a mistake when I reconfigured the kernel to support NFS, I enabled NFS but I didn't enable NFS v3 client support. So final summary, in case this might help anyone else: 1 - the v2.0 beta kernel does not have NFS client support enabled, which means that using CPU transparency with scratchbox will not work. Maybe there should be a temporary note in the CPU transparency howto to indicate this? 2 - by following/adapting the instructions in the KernelCompilation howto of the maemo wiki, you can build and install a new kernel that does have NFS enabled.In my case, I built the nfs support as modules, four in total: sunrpc.ko, lockd.ko, nfs_acl.ko, nfs.ko. I installed the new kernel using the flasher (as per the howto) and I copied the modules into the /root directory on the 770, and installed them manually using insmod. 3 - with the NFS modules loaded, the rest of the CPU transparency howto worked. I was able to build the helloworld example and verified that sbrsh is working correctly. - -- Buck Charles 'Buck' Krasic wrote: > To follow up my own post, I realized that I needed to load sunrpc > and lockd modules first. I'm still not there yet, when I try to > mount I get a "Protocol not supported" error that I am still trying > to figure out. Gotta love NFS when it works, but diagnosing it > when it doesn't is a pain. > > -- Buck ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEizsLPrrWIMa4SMsRAuHYAKC0+kZXy2kXxw6u1lO8qAopUy3R7ACdFfxV xPhMv8ruLz8SqI3roT6QI/U= =BoLq -END PGP SIGNATURE- begin:vcard fn:Charles 'Buck' Krasic n:Krasic;Charles 'Buck' org:University of British Columbia;Department of Computer Science adr:;;201-2366 Main Mall;Vancouver;B.C.;V6T 1Z4;Canada email;internet:[EMAIL PROTECTED] title:Assistant Professor tel;work:(604) 822-5628 tel;fax:(604) 822-5485 tel;cell:(604) 313-9429 x-mozilla-html:FALSE url:http://www.cs.ubc.ca/~krasic/ version:2.1 end:vcard ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] CPU transparency: no NFS support in 2.6.15-omap1?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 To follow up my own post, I realized that I needed to load sunrpc and lockd modules first. I'm still not there yet, when I try to mount I get a "Protocol not supported" error that I am still trying to figure out. Gotta love NFS when it works, but diagnosing it when it doesn't is a pain. - -- Buck -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEiwvnPrrWIMa4SMsRAgZgAKCKLqX9m9ggvqMIjPakleDGHr+eowCg4Rqx 6eAo5wzxZ4AawScFov4OGLQ= =vCcb -END PGP SIGNATURE- begin:vcard fn:Charles 'Buck' Krasic n:Krasic;Charles 'Buck' org:University of British Columbia;Department of Computer Science adr:;;201-2366 Main Mall;Vancouver;B.C.;V6T 1Z4;Canada email;internet:[EMAIL PROTECTED] title:Assistant Professor tel;work:(604) 822-5628 tel;fax:(604) 822-5485 tel;cell:(604) 313-9429 x-mozilla-html:FALSE url:http://www.cs.ubc.ca/~krasic/ version:2.1 end:vcard ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] CPU transparency: no NFS support in 2.6.15-omap1?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I didn't think to check /proc/filesystems.I did just now, and I do not see nfs. What I did do was follow the HowTo KernelCompilation page on the wiki that outlines how to modify the kernel and install it, doing my best guesses at adapting the parts that refer to 1.1 to 2.0 beta versions.This also possibly confirms that NFS is not there, because I find that the n770_defconfig file in the su-18-kernel-2.6.16 package has NFS completely disabled. So I enabled NFS client support and rebuild the kernel and package as per the howto. I flashed the kernel image to my 770, and copied the nfs.ko file to /root on the device.The new kernel seems to work, and uname -a seems to verify that it is indeed my build of the kernel that is running (based on the date), but if I try to insmod the nfs.ko file it does not work. I get the following: > Nokia770-23:~# insmod ./nfs.ko Using ./nfs.ko insmod: cannot insert > `./nfs.ko': Unknown symbol in module (-1): No such file or > directory I'm experienced with Linux and kernel development, but I'm still new to the 770 (also to debian flavor of linux), so I'm not sure what is going on here yet. - -- Buck Adrian Neumaier wrote: > Am Samstag, 10. Juni 2006 02:12 schrieb Charles 'Buck' Krasic: > >> I'm trying to follow the steps to get CPU transparency with the >> 2.0 developer image, but sbrsh reports NFS mount failures with >> 'No such device' errors. I believe this means the 770 kernel >> doesn't have NFS client support? Has anyone else tried it yet? >> >> >> -- Buck > > > Hmm the 1.1 release does contain nfs support in the Kernel. You can > check by do a cat /proc/filesystems. If you find a "nodev nfs" > then you have nfs client support in the kernel. > > Cheers Adrian > > > -- > > > ___ maemo-developers > mailing list maemo-developers@maemo.org > https://maemo.org/mailman/listinfo/maemo-developers -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEiwIrPrrWIMa4SMsRArWVAKCRU2mmskk/JapNHQdu0v0BO/sq2QCglgvI 773XB2b6ZMOlPBDK5mc3Tfc= =TdW/ -END PGP SIGNATURE- begin:vcard fn:Charles 'Buck' Krasic n:Krasic;Charles 'Buck' org:University of British Columbia;Department of Computer Science adr:;;201-2366 Main Mall;Vancouver;B.C.;V6T 1Z4;Canada email;internet:[EMAIL PROTECTED] title:Assistant Professor tel;work:(604) 822-5628 tel;fax:(604) 822-5485 tel;cell:(604) 313-9429 x-mozilla-html:FALSE url:http://www.cs.ubc.ca/~krasic/ version:2.1 end:vcard ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] CPU transparency: no NFS support in 2.6.15-omap1?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm trying to follow the steps to get CPU transparency with the 2.0 developer image, but sbrsh reports NFS mount failures with 'No such device' errors. I believe this means the 770 kernel doesn't have NFS client support?Has anyone else tried it yet? - -- Buck -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEig51PrrWIMa4SMsRAoLwAKCjYFQYrwt7vJBYtFFeS8ZeVL862wCeL/mo oSlU9F/3yJ64+EmmclyDMJ0= =0ZCu -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Play MP3
On Wed, 2005-07-20 at 16:46 +0700, rh wrote: > Does anyone know howto make program to play MP3 or other sound files > in Nokia 770 ? (maybe with Maemo SDK ?) I'm doubting it, unless Nokia is willing to pay royalties. However, ogg should work :) (and then again, I'm sure there will be heaps of 3rd party players out there) -- Colin Charles, http://www.bytebot.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] MacOS X Developer tools, Mac Syncing?
On Mon, 2005-07-18 at 19:23 +0200, Laurent Lieben wrote: > > are there MacOS X compatible developer tools already available? > > I'm looking for a way to make Xcode 2.0 as my default crosscompiling > tools. i.e. are you doing this with scratchbox? I heard that sbox can't run on freebsd/osx (currently at least) -- Colin Charles, http://www.bytebot.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Hello world!
On Mon, 2005-05-30 at 12:28 +0800, Avdpro Pang wrote: > 1> Can I use Redhat Linux? Yes you can. And depending on which version you have, you might want to make sure exec_shield/vdso is disabled (generally the latter, say for FC-4). List archives, ought to have more information with regards to this -- Colin Charles, http://www.bytebot.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Scratchbox rpm scriptlet failure
On Thu, 2005-06-16 at 08:49 +1000, Colin Charles wrote: > even when: > cat /proc/sys/kernel/exec-shield > 0 > So the real solution to those running FC-4 is to make sure you do: echo 0 > /proc/sys/kernel/vdso exec-shield can remain at 1, that's fine, its just vdso that needs to be turned off. Virtual .so (vdso) in FC-4 seems to be the issue Regards -- Colin Charles, http://www.bytebot.net/ FUDCon II @ LinuxTag June 24-25, 2005 in Karlsruhe, Germany http://fedoraproject.com/fudcon/ ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Scratchbox rpm scriptlet failure
On Thu, 2005-06-09 at 07:24 -0700, Colin Charles wrote: > On Thu, 2005-06-09 at 09:14 +0200, Niels wrote: > > Are you using the (not yet releast due to problems, but expected > > 13.june) FC4, or are you using a test 3 FC4 ? > > The only real problem was the lack of naming ;-) > > I am using the not-yet-publically-released FC-4 (admitedly, that'd be > kernel revision 1369, fwiw)... And now, after FC-4 is released publically, with uname -r 2.6.11-1.1369_FC4 I still get: ./run_me_first.sh Inconsistency detected by ld.so: rtld.c: 1192: dl_main: Assertion `(void *) ph->p_vaddr == _rtld_local._dl_sysinfo_dso' failed! even when: cat /proc/sys/kernel/exec-shield 0 So this is most certainly not working with FC-4. However, with FC-2, I've managed to get this going without any issue (and I've tried both with the RPM and just untarring into /scratchbox as per the instructions) Thanks -- Colin Charles, http://www.bytebot.net/ FUDCon II @ LinuxTag June 24-25, 2005 in Karlsruhe, Germany http://fedoraproject.com/fudcon/ ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Scratchbox rpm scriptlet failure
On Thu, 2005-06-09 at 09:14 +0200, Niels wrote: > Are you using the (not yet releast due to problems, but expected > 13.june) FC4, or are you using a test 3 FC4 ? The only real problem was the lack of naming ;-) I am using the not-yet-publically-released FC-4 (admitedly, that'd be kernel revision 1369, fwiw)... -- Colin Charles, http://www.bytebot.net/ FUDCon II @ LinuxTag June 24-25, 2005 in Karlsruhe, Germany http://fedoraproject.com/fudcon/ ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Airport Express
On Tue, 2005-06-07 at 14:24 -0700, dean blackketter wrote: > Unfortunately, the Airport Express is a closed bit of hardware (it > only works with iTunes officially, although its encryption appears > to > have been cracked.) And seeing that the encryption has been cracked, doing so would probably be okay. Of course, not legal in countries that recognise the DMCA... A non-US kind of repository might be handy in this case... -- Colin Charles, http://www.bytebot.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Scratchbox rpm scriptlet failure
On Wed, 2005-06-08 at 17:48 +0300, Timo Savola wrote: > > ./run_me_first.sh > > Inconsistency detected by ld.so: rtld.c: 1192: dl_main: Assertion > `(void > > *) ph->p_vaddr == _rtld_local._dl_sysinfo_dso' failed! > > > > Anyone else seen this? > > Take a look at these mails: > http://lists.scratchbox.org/pipermail/scratchbox-users/2004-August/ Performed: echo 0 > /proc/sys/kernel/exec-shield [EMAIL PROTECTED] ~]# cat /proc/sys/kernel/exec-shield 0 ./run_me_first.sh Inconsistency detected by ld.so: rtld.c: 1192: dl_main: Assertion `(void *) ph->p_vaddr == _rtld_local._dl_sysinfo_dso' failed! This time I tried it with tarballs too... 2.6.11-1.1363_FC4 is the kernel version. I'd gladly provide more information if required... -- Colin Charles, http://www.bytebot.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Scratchbox rpm scriptlet failure
So, anyone go around and install the scratchbox rpms? I got this: 2:scratchbox-core### [100%] Inconsistency detected by ld.so: rtld.c: 1192: dl_main: Assertion `(void *) ph->p_vaddr == _rtld_local._dl_sysinfo_dso' failed! error: %post(scratchbox-core-0.9.8.4-1.i386) scriptlet failed, exit status 127 System is Fedora Core 4, with SELinux enabled. Then when I go on to /scratchbox to perform run_me_first.sh, I get the same error: ./run_me_first.sh Inconsistency detected by ld.so: rtld.c: 1192: dl_main: Assertion `(void *) ph->p_vaddr == _rtld_local._dl_sysinfo_dso' failed! Anyone else seen this? Regards -- Colin Charles, http://www.bytebot.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
