Re: Xsp pixel-doubling solutions for Nokia 770?
If new Xomap doesn't work on the 770, I'd like to know about it. (I don't have time to constantly test it, but I can -- and will -- fix it.) I have found what triggers the Xsp disabling from SDL for IT 2005, 2006, and 2007 hacker ed. Doubling gets disabled whenever we update less than the full 320x240 screen. this breaks: SDL_UpdateRect (SDL_Video, updated.x, updated.y, updated.w, updated.h); this works: SDL_UpdateRect (SDL_Video, 0, 0, 320, 240); The same problem occurs in other SDL programs that do not update a full 320x240 screen each frame. I have prepared a simple SDL demo that illustrates this. It should be easier to understand and modify than the Ur-Quan Masters sources. Grab it here: http://pupnik.de/aliens-1.0.2_Nokia.tgz This contains a binary tgz for testing, as well as the source. Untar to home directory and use F6 button (top left on device) to toggle xsp doubling. To verify that updates outside of the doubled window are not affecting the doubling, change #define VIDWIN_X800 to #define VIDWIN_X640 and disable my onscreen buttons by commenting out these lines SDL_BlitSurface(buttonsurface,buttsrc,screen,buttdest); SDL_UpdateRect(screen, 0, 0, 0, 0); I would appreciate anyone interested in SDL and pixel doubling taking time to look it over. This is about as simple a 'real world' test case as you're going to get. Arnim Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/ ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 Video playback
On Thursday 03 May 2007 10:21, Frantisek Dufka wrote:
Siarhei Siamashka wrote:
If decoding time for
each frame will never exceed 28-29ms (which is a tough limitation, cpu
usage is not uniform), video playback without dropping any frames will be
possible even with tearsync enabled.
Would a double or multiple buffering help with this?
Yes, most likely it will. N800 has 800x480 virtual size for framebuffer and a
new enhanced screen update ioctl. Now it should be possible (did not try yet,
but will have some results very soon) to specify output position and size for
the rectangle as it gets displayed on the screen.
struct omapfb_update_window {
__u32 x, y;
__u32 width, height;
__u32 format;
__u32 out_x, out_y;
__u32 out_width, out_height;
__u32 reserved[8];
};
This theoretically allows us to use some kind of double buffering, we can
split framebuffer into two 400x480 parts and while one part is being
displayed, another one can be freely filled with the data for the next frame.
This will effectively remove the need for OMAPFB_SYNC_GFX, improving
peak framerate.
But this solution will require support for arbitrary downscaling in YUV420
format for each video frame to fit 400x480 box. The quality will be also
reduced a bit, but on the other hand, graphics bus should have no
performance problems with sending 400x480 through it.
If virtual framebuffer size could be extended to 800x960, this would allow us
to use doublebuffering without sacrificing resolution. Anyway, I'll try to
fix MPlayer framebuffer output module to properly work with the latest
version of N800 firmware and implement this form of doublebuffering. It
should provide the fastest video output performance that is possible.
Regarding Nokia 770, now it uses 800x600 framebuffer virtual size (some
extra waste of RAM?). Anyway, if hwa742 kernel driver could be extended to
support this improved screen update API and respect 'out_x' and 'out_y'
arguments, we could have four video pages in framebufer memory for
400x240 pixel doubled video output. It could allow to implement a very
efficient double buffering for accelerated Nokia 770 SDL project if it ever
takes off the ground :)
Does mplayer use different threads for displaying and decoding and decode
frames in advance?
No, it doesn't have any extra threads now. But video playback on Nokia 770
is already parallel, splitting tasks between the following pieces of hardware
each working simultaneously:
1. ARM core (demuxing and decoding video into framebuffer)
2. DMA + graphics controller (screen update transferring data from framebuffer
into videomemory and performaing YUV-RGB conversion on the fly)
3. C55x DSP core (mp3 audio decoding and playback)
There is not much point in creating many threads on ARM, as we only have a
single ARM core and splitting work into several threads will not accelerate
overall performance. Threads could be useful for doing something extra while
waiting for other hardware components to finish their work (waiting for screen
update for example), but decoding ahead will also require storing the decoded
data somewhere. This place for storing decoded ahead frames could be only
some extra space in framebuffer memory, otherwise we would lose some
performance on moving this data to framebuffer later (and increasing battery
power consumption). As framebuffer space is limited, we would not be able to
store many frames ahead, and decoding cpu usage most likely varies not
between frames but more like between different scenes (complicated action
scene will make us run out of decode ahead buffer pretty fast). Anyway,
probably this may be worth trying later, there even exists some threads based
MPlayer fork: http://mplayerxp.sourceforge.net/
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
Nokia 770 Video playback
On Monday 30 April 2007 14:27, Siarhei Siamashka wrote:
I also tried to use YUV420 on Nokia 770, but it did not work well.
According to Epson, this format should be supported by hardware. Also there
is a constant OMAPFB_COLOR_YUV420 defined in omapfb.h in Nokia 770 kernel
sources. But actually using YUV420 was not very successful. Full screen
update 800x480 in YUV420 seems to deadlock Nokia 770. Playback of centered
640x480 video in YUV420 format was a bit better, at least I could decipher
what's on the screen. But anyway, it looked like an old broken TV :) Image
was not fixed but floating up and down, there were mirrors, tearings, some
color distortion, etc. After video playback finished, the screen remained
in inconsistent state with a striped garbage displayed on it. Starting
video playback with YUY2 output fixed it. But anyway, looks like YUV420 is
not supported properly in the framebuffer driver from the latest OS2006
kernel. That's bad, it could provide ~30% improvement in video output
perfrmance for Nokia 770. Maybe upgrading framebuffer driver can fix this
issue (and add tearsync support).
By doing a quick kernel framebuffer code review, looks like the problem may
reside in the following fragment from hwa742.c:
switch (color_mode) {
...
case OMAPFB_COLOR_YUV420:
bpp = 12;
conv = 0x09;
transl = 0x25;
break;
...
}
...
set_window_regs(x, y, x + w, y + h);
offset = (scr_width * y + x) * bpp / 8;
hwa742.int_ctrl-setup_plane(OMAPFB_PLANE_GFX,
OMAPFB_CHANNEL_OUT_LCD, offset, scr_width, 0, 0, w, h,
color_mode);
hwa742.extif-set_bits_per_cycle(16);
hwa742.int_ctrl-enable_plane(OMAPFB_PLANE_GFX, 1);
hwa742.extif-transfer_area(w, h, request_complete, req);
As far as understand it, this code notifies the graphics chip about what
screen area it is going to update and starts DMA transfer to fill it with
data. But a similar code from 'blizzard.c' also does width correction before
'transfer_area' by doing 'w = (w + 1) * 3 / 4;'. Looks like code from hwa742.c
attempts to transfer more data than the graphics chip expects for YUV420
format. This can explain vertical image drift observed in my previous
experiments (for 640x480 area starting at 0,80), also excess data may
deadlock the graphics chip (for the test with 800x480 area starting at 0,0).
Also the 'offset' may be calculated wrong, see [1] for some bits of
information about YUV420 framebuffer layout on N800. Starting location
should be probably always calculated assuming 16bpp framebuffer layout.
Now I wonder who can be considered upstream for this kernel framebuffer
driver? I guess reporting a bug at maemo bugzilla is pointless as there are
no official updates for Nokia 770 planned. I wonder why this driver is still
getting some updates in newer versions of linux omap kernel and what
hardware is used to verify that it works? Is it still tested on Nokia 770?
1. http://maemo.org/pipermail/maemo-developers/2007-May/010039.html
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 Video playback
On Friday 04 May 2007 10:49, Daniel Stone wrote:
On Thu, May 03, 2007 at 11:10:32PM +0300, ext Siarhei Siamashka wrote:
Well, found what's the matter and added explanation at bugzilla:
https://maemo.org/bugzilla/show_bug.cgi?id=1281
The workaround can be easily added to MPlayer, so that it will
never call XvShmPutImage with top left image corner at an odd line.
I'm going to release an updated MPlayer package (maybe even
a bit later today), it is really fast on N800 with the optimized xserver
:)
Aha, that will indeed cause a fallback (x, y, width and height should
all be aligned to 4px).
Could you clarify this information? The code from kernel framebuffer
driver (blizzard.c) suggests that only width should be 4px aligned:
switch (color_mode) {
case OMAPFB_COLOR_YUV420:
/* Embedded window with different color mode */
bpp = 12;
/* X, Y, height must be aligned at 2, width at 4 pixels */
x = ~1;
y = ~1;
height = yspan = height ~1;
width = width ~3;
break;
Does xserver introduce additional limitations?
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
On Thursday 03 May 2007 12:58, Eero Tamminen wrote: ext Siarhei Siamashka wrote: What problem with using framebuffer directly? Everything should be fine, you can get notifications from xserver when your window becomes obscured, so you can stop drawing. I suggest you to try MPlayer on Nokia 770 to check how it interacts with xserver. The worst thing that can happen is some garbage data left on screen on fast applications switching. That can happen because there is no support to synchronize access to framebuffer in a reliable way (application using framebuffer directly may get notification from the xserver about getting inactive too late and overwrite some other application window). Adding support to xserver for proper synchronization with direct framebuffer access applications should be quite possible. It already synchronizes access to framebuffer with DSP (Xsp API for registering DSP area). Almost all the necessary changes will probably have to be added at the same places in xserver which support interaction with DSP. AFAIK Xserver requests waits DSP to stop updating the framebuffer before proceeding. This works with HW, but you cannot expect it to work reliably with misc X clients as there are no guarantees about what they do. If client is not processing X events, the response would be waited forever and device freezes. If X server has some timeout for the client reply, then the server and client can be updating the framebuffer at the same time and that was what we wanted to avoid in the first place. Timeout is a perfectly valid solution in my opinion. It just requires that xserver and some thin wrapper library used by misc clients (SDL) both interact correctly. Interface of this wrapper library should be designed in such a way, that it is safe and hard to be misused (special timeout code which automatically terminates the process which refuses to give framebuffer back to xserver). I may provide some extra details about my vision of implementation details if anybody is interested. I guess it can't be helped and I will make an example application for using framebuffer directly and some kind of tutorial. Don't know when I will have enough free time to do this though. I'm pretty much confident that direct framebuffer access (also with pixel doubling support) is quite possible for SDL. I don't care much if you believe me or not :) Someone just needs to do the dirty work and implement all this stuff. Yes, it just cannot be done safely / reliably. I can't be completely sure, but I think it is possible to do safely/reliably. At least it is worth trying in my opinion. The difference in our views is that you see xserver as the only valid Nokia 770 citizen and everything else looks like a very ugly hack to you. I see the problem from the completely different perspective. For many games xserver is irrelevant, they use SDL API and that is what they care about (xserver is just an additional extra layer). Game developers would like to have a fast and reliable SDL implementation which could make efficient use of all the hardware features that can benefit games. If xserver can provide all of this with some standard or nonstandard extensions, that's fine. We only need to estimate the amount of development resources and time needed to do these modifications to xserver and SDL to make use of these features. As games are not a primary target for Internet Tablets, I doubt that anything like this will be officially done any time soon (at least before the Nokia 770 end of life). Am I wrong? In this case tweaking SDL to use framebuffer directly may have a much lower cost. Especially considering that you have already solved this framebuffer sharing problem for DSP video playback. I did not suggest anything completely new ;) It is not quite related, but games also need a reliable and low latency method to play sounds. Current esd daemon solution is not very good for games. Maybe modifying SDL to deal with dsp tasks directly can provide some improvement. Also it would be very nice if SDL_Mixer could use dsp codecs transparently without any extra hacks to play mp3 music. But for hackers it's enough that it works when it works I guess. :-) I'm not sure if I can consider myself a hacker :) Something that just works is perfectly enough for a prototype. But a production system needs a reliable solution, hence I'm trying to start discussing the implementation details. SDL optimization for Nokia 770 might be an interesting task for some student with lots of free time. In any case, trying alternative solutions is a good thing, it drives the progress, allows us to improve our skills and gain experience. We get the best solution (whatever it would be) and everyone benefits as a result :) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Timer function
hi, I work on a whole music composer [1] built on gstreamer and there you can use gst-controller to trigger notes or change sound-parameters. GStreamer cares about the timing, you just schedule changes with a timestamp. Come to #gstreamer irc on freenode.org if you have questions. Stefan [1] http://www.buzztard.org Fred Lefévère-Laoide wrote: Hi, I plan to write a software metronome and I wonder what would be the best way to get a timer precise enough for that purpose ? The other problem is what's the best way to make a short sound (eventually corresponding to a note ...) Thanks for your help. Fred ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Research on Maemo
Hi Ramon Am Freitag, den 04.05.2007, 12:15 +0300 schrieb Quim Gil: And Matthias Stuermer and his team at http://www.smi.ethz.ch/ are also working on something although I'm not sure if they have published anything yet. Indeed we haven't published yet anything but are currently improving our working paper on the development process of the Nokia Internet Tablet. So far we conducted 23 interviews with Nokia members, contractors and volunteers of the Maemo community investigating the impact for a previously closed-source enterprise entering agile open source communities and creating one on their own. If you're interested in the current version of the paper I can send it you. Regards, Matthias Stuermer -- Matthias Stuermer | +41 44 632 89 13 | +41 76 368 81 65 [EMAIL PROTECTED] | http://www.smi.ethz.ch ETH Zurich | D-MTEC | Strategic Management and Innovation KPL G 13 | Kreuzplatz 5 | CH-8032 Zurich | Switzerland ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
