Re: N800 experimental host mode patches available

[Andrew J. Barr]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Frantisek Dufka wrote:
> Larry Battraw wrote:
>>  This will of course affect battery
>> life, but your average USB key, keyboard, or mouse shouldn't draw too
>> much.
> 
> Not sure how you can get it in linux but at least in XP you can check
> usb hub properties in device manager and see power requirements reported
> by connected devices. My usb key reports 100mA, sd/mmc card reader
> 250mA. Don't have usb keyboard around to check. The values should be
> maximal, i.e. device may in fact consume less. I hope it should not
> consume more.

This information is available from /proc/bus/usb/devices in Linux.

- --
Andrew J. Barr
Thunderbird/1.5.0.10 (compatible; Icedove 1.5; X11; en-US; Linux
2.6.21-rc7 ppc) (Debian/1.5.0.10dfsg.1)

"Why must I fail at every attempt at masonry?"
-- Homer Simpson, "Mom and Pop Art" [AABF15]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGKRgahuM+Z62a52oRAjguAJ9PXsg/tSgux941fyQ5gDgCvgNaiACguAgr
BlwJi8BPn3K0QSq70EB9am0=
=LP9h
-END PGP SIGNATURE-
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: N800 experimental host mode patches available

[Frantisek Dufka]

Larry Battraw wrote:

 This will of course affect battery
life, but your average USB key, keyboard, or mouse shouldn't draw too
much.


Not sure how you can get it in linux but at least in XP you can check 
usb hub properties in device manager and see power requirements reported 
by connected devices. My usb key reports 100mA, sd/mmc card reader 
250mA. Don't have usb keyboard around to check. The values should be 
maximal, i.e. device may in fact consume less. I hope it should not 
consume more.

___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: N800 experimental host mode patches available

[Larry Battraw]

On 4/20/07, Andreas Hubel <[EMAIL PROTECTED]> wrote:

Hi,

do you or somebody else here know if the 770 also has this host
detection via the ID pin feature?

And why does the USB chip of the N800 don't need this 5V from external?
I thougt it also need it, because there is only 3V and no 3 to 5V
converter inside the device.


Actually there is 5V 100 mA charge pump included in the chipset.  It
includes native OTG support  and it's just a matter of turning on host
(OTG) mode and the 5V source on.  This will of course affect battery
life, but your average USB key, keyboard, or mouse shouldn't draw too
much.

Larry



Regards,
Andi

Tony Lindgren schrieb:
> Hi all,
>
> I've been meaning to do this for a while, but only now got into it after
> sorting out one more issue with the N800 USB DMA.
>
> I've posted some experimental N800 host mode patches to [1] for people
> to play with. Although the N800 is not built to support host or OTG mode
> and does not have a mini-B connector, you can still use it via some
> software hacks.
>
> The patches are from the linux-omap git tree at [2] with some extra
> patches to force N800 into host mode.
>
> The driver is still very much experimental and can cause file system
> corruption on USB drives, so YMMV :)
>
> Anyways, let me know of issues and fixes.
>
> Regards,
>
> Tony
>
> [1] http://muru.com/linux/n800-usb-host/
> [2] 
http://master.kernel.org/git/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=summary
> ___
> 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




___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: Continuous reboot problem with the N770 hacker edition

[Neal H. Walfield]

At Fri, 20 Apr 2007 18:26:42 +0200,
Rainer Dorsch <[EMAIL PROTECTED]> wrote:
> I used the N770 with the hacker edition of OS2007 heavily last week and it 
> broke:
> The device is rebooting constantly, even putting it into RD mode did not help 
> getting rid of this. The sequence is
> 1. blue boot progress bar
> 2. Nokia hands and sound
> 3. almost immidiately after the sound, a white stripe appears on the left of 
> the display. Looks like this is the Maemo menue bar. Then the screen becomes 
> white
> 4. after approx. 19 seconds the device reboots and continues with 1.
> 
> I interrupt the reboot cycles by removing the battery.

I'm using Gergale and this happens to me about once every week or two.
I had enough time after the device boots to run xterm and top.  The
problem was jffs2_gcd_mtd4 was taking 100% of the CPU and a fair
amount of memory.  This led me to suspect that the OOM killer was
killing an essential task and thereby causing the watchdog timer to
reset the device.  To prevent this, I simply disabled the watchdog
time.  Now when this happens, jffs2_gcd_mtd4 burns CPU (and thus is
unusable) but it is a few hours between resets.  After about day or
two, the device is happy again.

Neal

___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Application Manager not loaded on simulator

[andika]

Hi maemo's developer,

finally im able to set up an maemo development using maemo appliance 
vmware :). But  when i start af-sb-init.sh start, on the simulator nothing 
installed.Only control panel and maemo-pad sample. 
How can i make "Application Manager" show up on simulator

regards
gusti-andika

   
-
Ahhh...imagining that irresistible "new car" smell?
 Check outnew cars at Yahoo! Autos.___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Continuous reboot problem with the N770 hacker edition

[Rainer Dorsch]

Hello,

I used the N770 with the hacker edition of OS2007 heavily last week and it 
broke:
The device is rebooting constantly, even putting it into RD mode did not help 
getting rid of this. The sequence is
1. blue boot progress bar
2. Nokia hands and sound
3. almost immidiately after the sound, a white stripe appears on the left of 
the display. Looks like this is the Maemo menue bar. Then the screen becomes 
white
4. after approx. 19 seconds the device reboots and continues with 1.

I interrupt the reboot cycles by removing the battery.

I am not aware that I did something uncommon before that happend, except 
accessing via USB to the MMC card (which I do very rarely). Removing the 
cable again apparently broke the MMC and I had to run e2fsck. 

Before I flash the device, I though I ask here if somebody is interested in 
some more debug data (and knows how I get them).

Thanks,
Rainer


-- 
Rainer Dorsch
Lärchenstr. 6
D-72135 Dettenhausen
07157-734133
email: [EMAIL PROTECTED]
jabber: [EMAIL PROTECTED]
GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F  8F59 E3A8 C538 7519 141E
Full GPG key: http://pgp.mit.edu/
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: N800 & Video playback

[Tao Huang]

Siarhei Siamashka 写道:

I have seen your code in xserver which does the same job for downscaling, but
in nonoptimized C and with much higher impact on quality. Using JIT scaler
there can improve both image quality and performance a lot. The only my
concern is about instruction cache coherency. As ARM requires explicit
instructions cache flush for self modyfying or dynamically generated code, I
wonder if  using just mmap is safe (does it flush cache for allocated region
of  memory?). Maybe maemo kernel hackers/developers can help with this
information?
  

arm linux support flush icache by syscall "cacheflush",

qemu have this function:
static inline void flush_icache_range(unsigned long start, unsigned long 
stop)

{
   register unsigned long _beg __asm ("a1") = start;
   register unsigned long _end __asm ("a2") = stop;
   register unsigned long _flg __asm ("a3") = 0;
   __asm __volatile__ ("swi 0x9f0002" : : "r" (_beg), "r" (_end), "r" 
(_flg));

}

you can reference kernel source arch/arm/kernel/traps.c and 
include/asm-arm/unistd.h


___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: N800 experimental host mode patches available

[Andreas Hubel]

Hi,

do you or somebody else here know if the 770 also has this host
detection via the ID pin feature?

And why does the USB chip of the N800 don't need this 5V from external?
I thougt it also need it, because there is only 3V and no 3 to 5V
converter inside the device.

Regards,
Andi

Tony Lindgren schrieb:
> Hi all,
> 
> I've been meaning to do this for a while, but only now got into it after
> sorting out one more issue with the N800 USB DMA.
> 
> I've posted some experimental N800 host mode patches to [1] for people
> to play with. Although the N800 is not built to support host or OTG mode
> and does not have a mini-B connector, you can still use it via some
> software hacks.
> 
> The patches are from the linux-omap git tree at [2] with some extra
> patches to force N800 into host mode.
> 
> The driver is still very much experimental and can cause file system
> corruption on USB drives, so YMMV :)
> 
> Anyways, let me know of issues and fixes.
> 
> Regards,
> 
> Tony
> 
> [1] http://muru.com/linux/n800-usb-host/
> [2] 
> http://master.kernel.org/git/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=summary
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://maemo.org/mailman/listinfo/maemo-developers




signature.asc
Description: OpenPGP digital signature
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

RE: Maemo SDK and Debian 64 bits

[Dirk-Jan.Binnema]

Hi David,

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On Behalf Of ext 
>David Hautbois
>Sent: Thursday, April 19, 2007 21:46
>To: Maemo developers mailing-list
>Subject: Maemo SDK and Debian 64 bits
>
>Hi
>Does the maemo SDK work fine with a 64 bits linux distribution ?
>
>On the maemo web site, we can read :
>
>* Intel compatible x86 processor, 500 MHz or faster
>* 256 MB RAM or more
>* 2 GB free hard disk space
>* Linux OS (Debian  or Ubuntu
>   are recommended, but other fairly recent
>  distributions should also work)
>
>
>Does it include X86_64 ?

At least, I am running the SDK on my Ubuntu/Feisty AMD64 system without
any problems. I created a chroot environment to install the SDK in the 
32-bit environment.

Best wishes,
Dirk.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: Boot bora as root

[Marius Vollmer]

"ext Chris Taylor" <[EMAIL PROTECTED]> writes:

> at any rate  any ideas what might be causing the socket to fail?

Chris, did you get my private mail?  I explained a bit there.  (I
didn't see this thread until now, sorry.)

In a nutshell, the frontend starts the backend via sudo, and that
might fail when the frontend doesn't run as "user".  When sudo fails,
the frontend goes catatonic (which is a known bug that has been fixed
in Sardine).
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: N800 & Video playback

[Frantisek Dufka]

Daniel Stone wrote:



Which Epson docs?



fanoush.wz.cz/maemo/S1D13745A01SpecRev1.0.gm.zip
Got it from Epson Electronics like the one mentioned here
http://maemo.org/pipermail/maemo-developers/2006-December/006638.html

___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

trouble to disconnect from WiFi AP

[Jan Vachun]

Hi,

In my apllication I'm trying to ensure connection to specific Wifi
network Access Point AP. I'm using osso_iap_connect() call to
connect using previously configured profile and it works well when no
wifi connection is currently selected.
When N800 is already connected to another WiFi AP, calling
osso_iap_connect() blocks application until WiFi connection is
dropped using Connection manager UI.

calling osso_iap_disconnect(...) with OSSO_IAP_ANY or with realIAP
profile name as parameter returns no error but doesn't disconnect
current WiFi connection.

I have also tried to disconnect through D-BUS using
disconnect_iap_async() in following code, but it didn't work either.

Any hint will be really appreciated.



<--- begin of sample code -->

void send_message_no_reply(DBusMessage *msg);
int disconnect_iap_async(const char *iap);
DBusConnection *get_connection();

DBusConnection *get_connection()
{
static DBusConnection *connection = NULL;

if (connection == NULL) {
connection = dbus_connection_open(
DBUS_SYSTEM_BUS_DEFAULT_ADDRESS,
NULL);

if (!connection)
return NULL;

if (!dbus_bus_register(connection, NULL)) {
dbus_connection_disconnect(connection);
dbus_connection_unref(connection);
connection = NULL;
return NULL;
}
}



return connection;
}




void send_message_no_reply(DBusMessage *msg)
{
DBusConnection *conn;

conn = get_connection();
dbus_message_set_no_reply(msg, TRUE);
dbus_connection_send(conn, msg, NULL);
}



int disconnect_iap_async(const char *iap)
{
  DBusMessage *msg;
  msg = dbus_message_new_method_call(
ICD_DBUS_SERVICE,
ICD_DBUS_PATH,
ICD_DBUS_INTERFACE,
ICD_DISCONNECT_REQ);
  if (msg == NULL)
return -1;
  if (!dbus_message_append_args(msg, DBUS_TYPE_STRING, &iap,
DBUS_TYPE_INVALID))
  {
dbus_message_unref(msg);
return -1;
  }
  send_message_no_reply(msg);
  dbus_message_unref(msg);
  return 0;
}

<--- end of sample code >




-- 
Jan Vachun

Spintec s.r.l.
C.so Torino 89/A
Ferriera di Buttigliera Alta (TO), 10090
tel: +39 011 9348228
fax: +39 011 9348861
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: setting up Maemo appliance vmware

[Urho Konttori]

Hi,
The image is packed using 7-zip.

Use 7-zip program to extract the files first. Finding 7-zip should be 
easy using google. Then you'll end up with only the necessary few files. 

From there on, you'll know what to do.


I wonder why normal zip was not used instead of 7-zip.

Kind regards,
Urho Konttori

Hi maemo developers,
i just finish download the maemo appliance vmware using torrent, but 
there are so many downloaded files, and i dont know how to make up an 
virtual machine from those files.
does anyone having experience in using Maeme appliance vmware, let me 
know how to set up the virtual machine after download the files.
 
thanks



Ahhh...imagining that irresistible "new car" smell?
Check out new cars at Yahoo! Autos. 
 




___
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

setting up Maemo appliance vmware

[andika]

Hi maemo developers,
  i just finish download the maemo appliance vmware using torrent, but there 
are so many downloaded files, and i dont know how to make up an virtual machine 
from those files.
  does anyone having experience in using Maeme appliance vmware, let me know 
how to set up the virtual machine after download the files.
   
  thanks

   
-
Ahhh...imagining that irresistible "new car" smell?
 Check outnew cars at Yahoo! Autos.___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: N800 & Video playback

[Daniel Stone]

Hi,

On Fri, Apr 20, 2007 at 09:41:45AM +0300, ext Siarhei Siamashka wrote:
> 1. Lockups which look like cycling two sequential frames, very similar or the 
> same problem as https://maemo.org/bugzilla/show_bug.cgi?id=991 
> Also keypresses are not very responsive. A fix (or workaround) required
> changing XFlush to XSync in screen update code, now it looks a lot better.

I assume this is basically just a race condition, and it doesn't trigger
on other systems, because they're a lot quicker.
 
> 2. Switching windowed/fullscreen mode generally makes mplayer terminate
> with the following error messages:
> "X11 error: BadValue (integer parameter out of range for operation)"
> "Xlib: unexpected async reply (sequence 0x5db)!"
> A workaround to make this problem less frequent was a code addition which
> prevents screen updates until we get Expose even notification.

Ditto.

> I really don't know much about X11 programming and only started to learning
> it, so your help with some advice may be very useful.

I mainly lurk on the server side, however.

> Looks like MPlayer code
> X11/Xv output code is a big mess with many tricks and workarounds added to
> work on different systems over time. Maybe it contains some bugs which get
> triggered on N800 only, but apparently this code is used for other systems
> without any problems. Can you try experimenting a bit with MPlayer (upstream
> release) yourself to check how it works with N800 xserver? Maybe it can reveal
> some xserver bugs which need to be fixed? Also if MPlayer has some apparently 
> bad X11 code, preparing a clean patch and submitting it upstream maybe a 
> good idea.

Unfortunately, I don't have the time to do this.  Sorry.

> One more strange thing with Xv on N800 can be reproduced by trying to watch
> standard N800 demo video in MPlayer. It has an old familiar tearing line in
> the bottom part of the screen and the performance is very poor. The same file
> plays fine in the standard video player. The only difference is that mplayer
> respects video aspect ratio (this video is not precisely 15:9 but slightly
> off) and shows some small black bands above and below picture and 
> default video player scales it to fit the whole screen. Disabling aspect ratio
> in mplayer with -noaspect option also 'fixes' this problem.
> 
> Using benchmark option we get the following numbers:
> 
> # mplayer -benchmark -quiet Nokia_N800.avi
> [...]
> BENCHMARKs: VC:  33,271s VO:  66,768s A:   0,490s Sys:   5,703s =  106,232s
> BENCHMARK%: VC: 31,3189% VO: 62,8517% A:  0,4614% Sys:  5,3681% = 100,%
> BENCHMARKn: disp: 1732 (16,30 fps)  drop: 778 (30%)  total: 2510 (23,63 fps)
> 
> # mplayer -benchmark -quiet -noaspect Nokia_N800.avi
> [...]
> BENCHMARKs: VC:  32,226s VO:  14,350s A:   0,456s Sys:  55,699s =  102,731s
> BENCHMARK%: VC: 31,3694% VO: 13,9687% A:  0,4439% Sys: 54,2180% = 100,%
> BENCHMARKn: disp: 2501 (24,35 fps)  drop: 0 (0%)  total: 2501 (24,35 fps)
> 
> So when showing video with proper aspect ratio, we get tearing back and more
> than 4x slowdown in video output code (66,768s vs. 14,350s). This all results
> in 30% of frames dropped.

Okay, I'll take a look at this.  My guess is that the scaling we're
seeing prevents us from using the LCD controller's overlay, possibly
because it's done in software.

> These were the 'usability' problems with Xv. Now we get to performance
> related issues. As YV12 is not natively supported by hardware, some 
> color format conversion and bytes shuffling in video output code is
> unavoidable. It is a good idea to optimize this code if we need a good
> performance for high resolution video playback. Color format conversion 
> can be optimized using assembly, for example maemo port of mplayer
> has a patch for assembly optimized yv12-> yuy2 (yuv420p -> yuyv422) 
> nonscaled conversion which provides a very noticeable ~50% improvement
> on Nokia 770:
> https://garage.maemo.org/plugins/scmsvn/viewcvs.php?root=mplayer&rev=129&view=rev
> 
> Also here is a JIT accelerated scaler for yv12-> yuy2 (yuv420p -> yuyv422)
> conversion, it is very fast and supports pixels interpolation (good for image
> quality) :
> https://garage.maemo.org/plugins/scmsvn/viewcvs.php/trunk/libswscale_nokia770/?root=mplayer

The primary conversion we do isn't planar -> packed (this is a fallback
for when the video is obscured), but from planar to another custom
planar format.  It would be good to get ARM assembly for the fallback
path, but most of the problem when using packed lies in having to
transfer the much larger amount of data over the bus.

There's one optimisation that could be done for the YUV420 conversion
(the custom planar format that Hailstorm takes), which removes a branch,
ensures 32-bit writes always (instead of one 32-bit and one 16-bit per
pixel), and unrolls a loop by half.  Might be interesting to see what
effect this has, but I think it'll still be rather small.

> I have seen your code in xserver which does the same job for do

Re: [maemo-developers] How to extend Hildon Input Methods

[Mohammad Anwari]

Hi,

I've forwarded your message (again) to the Bora team. Hope they can fix
this ASAP. Sorry for the inconvinience. For the mean time, I guess you
could use the same header packages which available in Bora 3.0.

Pada hari Rabu, tanggal 18/04/2007 pukul 17:30 +0200, ext Guard][an
menulis:
> Hello Mohammad,
> 
> Since your reply to my questions, the wiki page 
> http://www.maemo.org/platform/docs/howtos/howto_him_bora.html has not 
> been updated :(
> 
> More over, 
> http://repository.maemo.org/stable/3.1/content_comparison.html indicates 
> that packages libhildon-input-method-framework-header-sdk-dev and 
> libhildon-input-method-ui-header-sdk-dev have been removed.
> 
> As a consequence, it is not possible anymore to compile the sample input 
> method plugin at 
> http://www.maemo.org//downloads/him-plugin-examples/him-plugins-sdk-example-0.0.2.tar.gz
> 
> As a workaround, I will revert to bora 3.0. However, what's the solution 
> for bora 3.1 ?
> 
> Regards,
> G.
> 
> Mohammad Anwari wrote:
> > Pada hari Senin, tanggal 15/01/2007 pukul 13:45 +0100, ext Guard][an
> > menulis:
> >> The tutorial mentions "libhildon-input-method-header-sdk-dev and 
> >> libhildon-input-method-framework-header-sdk-dev packages" but the real 
> >> name of the first package seems to be 
> >> "libhildon-input-method-ui-header-sdk-dev".
> > 
> > You are correct. I'm cc:-ing bora-feedback hoping they can fix this.
> > 
> >> Also, it would be nice to have more detailed documentation on key types 
> >> and attributes usage.
> >>
> >> For instance, the q markup seems 
> >> rather obscure to me, particularly the alpha="ALPHA" part.
> >>
> >> Also, how do you define a modifier key ?
> > 
> > Unfortunately, there is no modifier key :(
> > 
> >>  And how do you specify tabs like the "abc" "ABC" "1!+" tabs on the thumb 
> >> keyboard. In fact, having 
> > 
> > Put label attribute in the sublayout tag.
> > ...
> > 
> > 
> > ...
> > 
> >> the xml versions of the .vkb files deployed on the device would really 
> >> help understanding how to achieve the "abc/ABC click on the same tab 
> >> changes the case" behavior. 
> > 
> > Use variance index for that, so we would have:
> > ...
> > 
> > 
> > ...
> > 
> > ...
> > ...
> > 
> >> Is there any plan to make these .xml files 
> >> available ?
> > 
> > Sorry, no plan for that.
> > 
> >> Regards.
> >> G.
> > 
> 
> ___
> 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: N800 & Video playback

[Siarhei Siamashka]

On Monday 19 March 2007 22:34, you wrote:



> Again, if there are any particular questions I can answer, don't be
> subtle: ask me straight up.  If I can answer them (some things I can't
> necessarily say, some things I don't necessarily know), I will.

Thanks, here we go and sorry for a long delay with this answer.

First thanks for Xv update which makes it really usable now, MPlayer now uses
Xv video output on N800 by default. But there are still some problems. Using
unmodified upstream MPlayer code for Xv (N800 with 3.2007.10-7
firmware at the moment) does not work good. It has two at least problems:

1. Lockups which look like cycling two sequential frames, very similar or the 
same problem as https://maemo.org/bugzilla/show_bug.cgi?id=991 
Also keypresses are not very responsive. A fix (or workaround) required
changing XFlush to XSync in screen update code, now it looks a lot better.

2. Switching windowed/fullscreen mode generally makes mplayer terminate
with the following error messages:
"X11 error: BadValue (integer parameter out of range for operation)"
"Xlib: unexpected async reply (sequence 0x5db)!"
A workaround to make this problem less frequent was a code addition which
prevents screen updates until we get Expose even notification.

All these Xv patches for MPlayer code can be viewed here:
https://garage.maemo.org/plugins/scmsvn/viewcvs.php?root=mplayer&diff_format=h&view=rev&rev=166

I really don't know much about X11 programming and only started to learning
it, so your help with some advice may be very useful. Looks like MPlayer code
X11/Xv output code is a big mess with many tricks and workarounds added to
work on different systems over time. Maybe it contains some bugs which get
triggered on N800 only, but apparently this code is used for other systems
without any problems. Can you try experimenting a bit with MPlayer (upstream
release) yourself to check how it works with N800 xserver? Maybe it can reveal
some xserver bugs which need to be fixed? Also if MPlayer has some apparently 
bad X11 code, preparing a clean patch and submitting it upstream maybe a 
good idea.

One more strange thing with Xv on N800 can be reproduced by trying to watch
standard N800 demo video in MPlayer. It has an old familiar tearing line in
the bottom part of the screen and the performance is very poor. The same file
plays fine in the standard video player. The only difference is that mplayer
respects video aspect ratio (this video is not precisely 15:9 but slightly
off) and shows some small black bands above and below picture and 
default video player scales it to fit the whole screen. Disabling aspect ratio
in mplayer with -noaspect option also 'fixes' this problem.

Using benchmark option we get the following numbers:

# mplayer -benchmark -quiet Nokia_N800.avi
[...]
BENCHMARKs: VC:  33,271s VO:  66,768s A:   0,490s Sys:   5,703s =  106,232s
BENCHMARK%: VC: 31,3189% VO: 62,8517% A:  0,4614% Sys:  5,3681% = 100,%
BENCHMARKn: disp: 1732 (16,30 fps)  drop: 778 (30%)  total: 2510 (23,63 fps)

# mplayer -benchmark -quiet -noaspect Nokia_N800.avi
[...]
BENCHMARKs: VC:  32,226s VO:  14,350s A:   0,456s Sys:  55,699s =  102,731s
BENCHMARK%: VC: 31,3694% VO: 13,9687% A:  0,4439% Sys: 54,2180% = 100,%
BENCHMARKn: disp: 2501 (24,35 fps)  drop: 0 (0%)  total: 2501 (24,35 fps)

So when showing video with proper aspect ratio, we get tearing back and more
than 4x slowdown in video output code (66,768s vs. 14,350s). This all results
in 30% of frames dropped.

These were the 'usability' problems with Xv. Now we get to performance
related issues. As YV12 is not natively supported by hardware, some 
color format conversion and bytes shuffling in video output code is
unavoidable. It is a good idea to optimize this code if we need a good
performance for high resolution video playback. Color format conversion 
can be optimized using assembly, for example maemo port of mplayer
has a patch for assembly optimized yv12-> yuy2 (yuv420p -> yuyv422) 
nonscaled conversion which provides a very noticeable ~50% improvement
on Nokia 770:
https://garage.maemo.org/plugins/scmsvn/viewcvs.php?root=mplayer&rev=129&view=rev

Also here is a JIT accelerated scaler for yv12-> yuy2 (yuv420p -> yuyv422)
conversion, it is very fast and supports pixels interpolation (good for image
quality) :
https://garage.maemo.org/plugins/scmsvn/viewcvs.php/trunk/libswscale_nokia770/?root=mplayer

I have seen your code in xserver which does the same job for downscaling, but
in nonoptimized C and with much higher impact on quality. Using JIT scaler
there can improve both image quality and performance a lot. The only my
concern is about instruction cache coherency. As ARM requires explicit
instructions cache flush for self modyfying or dynamically generated code, I
wonder if  using just mmap is safe (does it flush cache for allocated region
of  memory?). Maybe maemo kernel hackers/developers can help with this
information?

It should be noted, that all this assem