[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#469295: marked as done (xserver-xorg-video-i810: do not fail to set XV_PIPE if not in clone mode)



Your message dated Sun, 16 Mar 2008 14:08:39 +0100
with message-id <47DD1BD7.5020107@ens-lyon.org>
and subject line Re: Bug#469295: xserver-xorg-video-i810: do not fail to set XV_PIPE if not in clone mode
has caused the Debian Bug report #469295,
regarding xserver-xorg-video-i810: do not fail to set XV_PIPE if not in clone mode
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
469295: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=469295
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: xserver-xorg-video-i810
Version: 2:1.7.2-4
Severity: normal
Tags: patch

While working with xine-lib, I encountered an issue only in etch with i810 :
Calling xine_close_video_driver while using an XV output raises a BadMatch
error.

This is easily shown using the muxine reference implementation[1] and playing
a video till the end.
X Error of failed request:  BadMatch (invalid parameter attributes)
 Major opcode of failed request:  140 (XVideo)
 Minor opcode of failed request:  13 ()
 Serial number of failed request:  88
 Current serial number in output stream:  95

[1] http://xinehq.de/index.php/samplecode

Minor opcode 13 is XvSetPortAttribute :
$ grep 13 /usr/include/X11/extensions/Xvproto.h
#define xv_SetPortAttribute               13

Playing a bit with gdb, using XSynchronize() and a breakpoint on
XvSetPortAttribute, I found out that the offending port attribute was XV_PIPE.

Xine, upon closing the video driver, restores all the port attributes value to
the state in which they were before Xine video driver was started. But
setting XV_PIPE to its default value '0' does not work if clone mode is
disabled in i810. Here is a simple program that shows the issue. The program
simply tries to restore the XV_PIPE attribute to 0.

--
#include <stdio.h>
#include "X11/Xlib.h"
#include "X11/extensions/Xvlib.h"

// Compile with :
// $ gcc -lXv -o test_spa test_spa.c

int main(int argc, char **argv){
    Display *display;
    XvPortID port = 57; // Find this in the output of xvinfo | grep 'port base'
    char *attr_name = "XV_PIPE";
    Atom attr;
    int p_value;

    display = XOpenDisplay(":0.0");
    XSynchronize(display, True);

    attr = XInternAtom(display, attr_name, False);
    printf("%s is %d\n", attr_name, (int)attr);

    XvGetPortAttribute(display, port, attr, &p_value);
    printf("%s has value %d\n", attr_name, p_value);

    printf("Trying to set %s to %d...\n", attr_name, p_value);
    if( XvSetPortAttribute(display, port, attr, p_value) == Success ){
        printf(" success.\n");
    }else{
        printf(" failed!\n");
    }

    XCloseDisplay(display);

    return 0;
}
--

Output is :
$ ./test_spa
XV_PIPE is 77
XV_PIPE has value 0
Trying to set XV_PIPE to 0...
X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  140 (XVideo)
  Minor opcode of failed request:  13 ()
  Serial number of failed request:  13
  Current serial number in output stream:  14

I really do not understand all this video driver stuff, but here is a simple
patch that fixes the problem for me.

diff -rN -u old/debian/patches/12-set_xv_pipe.patch new/debian/patches/12-set_xv_pipe.patch
--- old/debian/patches/12-set_xv_pipe.patch      1970-01-01 01:00:00.000000000 +0100
+++ new/debian/patches/12-set_xv_pipe.patch      2008-03-04 14:19:02.000000000 +0100
@@ -0,0 +1,21 @@
+Tue Mar  4 13:42:17 CET 2008  Alexandre Rossi <alexandre.rossi@gmail.com>
+  * success if setting XV_PIPE to same value
+diff -rN -u old/src/i830_video.c new/src/i830_video.c
+--- old/src/i830_video.c       2008-03-04 13:44:52.000000000 +0100
++++ new/src/i830_video.c       2008-03-04 13:44:52.000000000 +0100
+@@ -945,7 +945,13 @@
+       ErrorF("CONTRAST\n");
+       if (*pI830->overlayOn)
+          OVERLAY_UPDATE;
+-   } else if (pI830->Clone && attribute == xvPipe) {
++   } else if (attribute == xvPipe) {
++      if (!pI830->Clone) {
++         if (value == pPriv->pipe)
++            return Success;
++         else
++            return BadMatch;
++      }
+       if ((value < 0) || (value > 1))
+          return BadValue;
+       pPriv->pipe = value;
+
diff -rN -u old/debian/patches/series new-xserver-xorg-video-i810-1.7.2-4+xvpipebadmatch/debian/patches/series
--- old/debian/patches/series   2008-03-04 14:19:01.000000000 +0100
+++ new/debian/patches/series   2008-03-04 14:19:02.000000000 +0100
@@ -1,3 +1,4 @@
 10-overlay_fix_lockup.patch
 11-xv_lockup.patch
+12-set_xv_pipe.patch
 20-i915_bios.patch

(it's crappy because the patch overlaps 10-overlay_fix_lockup.patch)

Upstream should not be interested because it seems that clone mode has
completely been rewritten since. The new implementation is not affected by this
issue (i.e. no problem in lenny or sid).

Anyway, I do not know if this should be fixed or not, but I wanted to share
what I had found out, and I do not have a blog ;)

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6-vserver-amd64
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)

Versions of packages xserver-xorg-video-i810 depends on:
ii  libc6                  2.3.6.ds1-13etch5 GNU C Library: Shared libraries
ii  xserver-xorg-core      2:1.1.1-21etch4   X.Org X server -- core server

xserver-xorg-video-i810 recommends no packages.

-- no debconf information



--- End Message ---
--- Begin Message ---
Alexandre Rossi wrote:
> Anyway, I do not know if this should be fixed or not, but I wanted to share
> what I had found out, and I do not have a blog ;)
>   


Right, at least the patch is archived now. But we need to mark the bug
as fixed properly now.

Brice



--- End Message ---

Reply to: