But, the real problem is here...Consider this.
void update() {
unsigned int bwidth, tdepth;
int dx1, dy1;
Window rootwindow;
unsigned int _w, _h;
XGetGeometry(theDisplay, window, &rootwindow,
&dx1, &dy1, &_w, &_h,
&bwidth, &tdepth);
XvShmPutImage(theDisplay, xv_port, window,
gc, yuv_image,
ulx, uly, brx-ulx, bry-uly,
0, 0, _w, _h,true);
}; // put cropped image in the (possibly resized) window
The update() method runs thru the first iteration but fails on the second
time thru at the XGetGeometry() call. The error is
X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 140 (XVideo)
Minor opcode of failed request: 19 ()
Serial number of failed request: 22
Current serial number in output stream: 23
Why would Xvideo throw a BadMatch on a simple GetGeometry call? If my
xv_port, Display, or window variables are wrong I would have expected the
program to abort on the first iteration, instead of seeing the window
mapped, then it going thru the first iteration of update() correctly.
...using "xorg-x11-server-Xorg-1.1.1-47.6.fc6" and nvidia driver
"1.0-9746".
-Rob Prowel
> I need a reference for REAL online documentation of the Xvideo extension.
>
> But, the real problem is here...Consider this.
>
> void update() {
> unsigned int bwidth, tdepth;
> int dx1, dy1;
> Window rootwindow;
> unsigned int _w, _h;
> XGetGeometry(theDisplay, window, &rootwindow,
> &dx1, &dy1, &_w, &_h,
> &bwidth, &tdepth);
> XvShmPutImage(theDisplay, xv_port, window,
> gc, yuv_image,
> ulx, uly, brx-ulx, bry-uly,
> 0, 0, _w, _h,true);
> }; // put cropped image in the (possibly resized) window
>
> The update() method runs thru the first iteration but fails on the second
> time thru at the XGetGeometry() call. The error is
>
> X Error of failed request: BadMatch (invalid parameter attributes)
> Major opcode of failed request: 140 (XVideo)
> Minor opcode of failed request: 19 ()
> Serial number of failed request: 22
> Current serial number in output stream: 23
>
> Why would Xvideo throw a BadMatch on a simple GetGeometry call?
It's not the XGetGeometry call that is failing. The error message
tells you that it is the XvShmPutImage call that generates the error.
I suggest printing all the values you are passing to XvShmPutImage.
I'm guessing some with or height is zero or negative.
--
Måns Rullgård
ma...@mansr.com
That doesn't mean anything. Xlib is asynchronous. It sends requests and
returns as quickly as possible, without waiting for a reply. Eventually the
error arrives, sometimes much later than the request that caused it. That's
why you have to read what the error tells you:
>X Error of failed request: BadMatch (invalid parameter attributes)
> Major opcode of failed request: 140 (XVideo)
> Minor opcode of failed request: 19 ()
> Serial number of failed request: 22
> Current serial number in output stream: 23
The XGetGeometry was the 23rd request. The 22nd request was the one that
failed. It was an XVideo request, minor 19, which is:
X11/extensions/Xvproto.h:#define xv_ShmPutImage 19
If you use XSync() after your XvShmPutImage, you'll find that it dies there.
--
Alan Curry
pac...@world.std.com
I suggest you look at this test program that I wrote:
http://www.xmission.com/~georgeps/engineering/prototype/Xv_prototype-8.tar.bz2
The little documentation on Xv that I could find, was inadequate. I
hacked together that prototype from various sources, and studying actual
drivers.
I've written a widget that uses Xv, that prototype above, and most
recently I'm writing a new window system that also has an Xv driver for
running on top of X. The window system driver runs as a separate
process that mmap()s a window's file (in /nexx a tmpfs/mfs), so it's
pretty easy to understand. It also has a test mode. ./nx_xv_driver -t
-m 1 or ./nx_xv_driver -t -m 2 (if you want 1024x768). no arguments
lists the modes.
One important thing I later learned that is lacking from the
Xv_prototype is XV_SET_DEFAULTS. Some programs and/or video drivers are
buggy, so they leave the Xv port in a bad state. XV_SET_DEFAULTS seems
to fix this.
This is the latest tarball of my new window system (NetBSD-only at the
moment, because it uses the wscons subsystem).
http://www.xmission.com/~georgeps/implementation/software/NexX/NexX-173.tar.bz2
It's nice to have X11 drivers around for me to get design ideas from so
that I can build new drivers for NexX. One of my goals is to modify
Xvfb so that it will allow running some X11 apps in a window within
NexX. That may be weeks, months, or years from now. :)
-George
> Rob wrote:
>> I need a reference for REAL online documentation of the Xvideo
>> extension.
>>
>>
> I suggest you look at this test program that I wrote:
> http://www.xmission.com/~georgeps/engineering/prototype/
Xv_prototype-8.tar.bz2
>
> The little documentation on Xv that I could find, was inadequate. I
> hacked together that prototype from various sources, and studying actual
> drivers.
Hey. Thanks for the followup. Based on other responses I double checked
my code and found that I was trying to use a 32bpp depth that wasn't
supported. It created the window just fine but the putimage would fail.
Yes, the available documentation for the Xvideo extension is woefully
inadequate. I pulled an example from a link on wikipedia and merged it
with the xvid_decraw example from the xvid mpeg4 codec with good results.