[Openchrome-users] Could not lock DMA pages

[Thomas Hellström]

MagicITX wrote:

>
>
> On 1/12/06, *Thomas Hellstr?m* <unichrome at shipmail.org 
> <mailto:unichrome at shipmail.org>> wrote:
>
>     MagicITX wrote:
>
>     >>
>     >     Strange.
>     >
>     >     Tim, Can you set
>     >     XV_DEBUG
>     >     at the beginning of via_swov.h and recompile the driver,
>     rerun and
>     >     post a more verbose output?
>     >
>     >     /Thomas
>     >
>     >
>     >>     --
>     >>
>     >>     Tim
>     >>     www.magicitx.com <http://www.magicitx.com>
>     <http://www.magicitx.com <http://www.magicitx.com>>
>     >
>     >
>     >
>     > Here you go.  Thanks!
>     >
>     >
>     > --
>     >
>     > Tim
>     > www.magicitx.com <http://www.magicitx.com>
>     <http://www.magicitx.com <http://www.magicitx.com>>
>
>     OK, There are actually three different errors involved here.
>
>     1) The "Could not lock dma pages" message was due to a bug in via drm,
>     that requested the wrong direction protection on locked dma pages.
>     Apparently vlc is the only driver that marks the image memory
>     read-only.
>     This is fixed in via drm 2.9.0. Recently checked in.
>
>     2) There were some serious XV YUY2 errors in the openchrome driver.
>     These are hopefully fixed in svn revision 137, which also requests
>     drm
>     version 2.9.0 or higher to activate DMA blitting.
>
>     3) It seems that VLC doesn't format the Xv images as the X server
>     tells
>     it to do. In particular, it doesn't adhere to pitches. This makes YV12
>     produce rendering errors on widths that are not multiples of 32, but
>     YUY2 is OK for widths that are multiples of 16. (when dmablit is on,
>     otherwise the openchrome driver requests that strides and widths
>     are the
>     same). This should really be communicated to the VLC developers.
>
>     /Thomas
>
>
>
>
>
>
> That's a lot closer.  I get a good image except the bottom 6 rows or 
> so have a heavy green tint.  I can see the video in the green tint so 
> it must be a luma thing.  Here's what I did to make sure I didn't miss 
> any steps.
>
> 1. Pulled down the latest /cvs/dri from cvs.freedesktop.org 
> <http://cvs.freedesktop.org>
> 2. Built and copied drm.ko and via.ko from linux-core
> 3. Pulled down the latest /svn/trunk from svn.openchrome.org 
> <http://svn.openchrome.org>
> 4. Built and installed.
>
> I get the PCI DMA line in Xorg.0.log which I've attached (debug still 
> on in via_swov.h).
>
> Thanks
>
Hi, Tim. That's the VLC bug. (3 above). The via driver tells vlc to use
368 for chroma stride, but it uses 360. Hence there is no chroma data
for the last lines, and if you look closely the rest of the picture is
in black and white with diagonal misrendered colors on it. It works when
not using PCI DMA, because then the via driver tells VLC to use 360,
which it does anyway.

A temporary workaround for 720 width is to use YUY2, but the best thing
would be if you communicated this to VLC developers.

/Thomas




> -- 
>
> Tim
> www.magicitx.com <http://www.magicitx.com>