Re: Why is MAXRESOURCES 400?
Yoshihiro Takahashi wrote: > Why is MAXRESOURCES 400? > I want to get of Resources more than 400 in XtGetApplicationResources. I doubt anyone knows since no one has really worked on Xt in a decade. Most developers moved on to Gtk+, Qt, or other non-Xt toolkits many years ago. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Why is MAXRESOURCES 400?
Hi. Why is MAXRESOURCES 400? I want to get of Resources more than 400 in XtGetApplicationResources. libXt-1.0.2/src/Resources.c and libXt-1.0.5/src/Resources.c #define MAXRESOURCES 400 Best regards, -- ytakaha...@miraclelinux.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
How to set modeline under xorg server 1.8.0
Hi I have a setup which I've just upgraded to Fedora 13 with Xorg server 1.8.0. The setup has a Quadro FX 3400 card with an IBM T221 3840 x 2400 monitor. Under previous iterations of xorg i've output to the monitor as a dualhead setup using 1920x2400 + 1920x2400 and it's worked pretty well. However under the new version of Fedora the xorg.conf file now gets re-generated every reboot using udev to detect devices if I've understood the docs properly. Unfortunately the display is getting detected as a 3840x2400 screen and is being output to at the wrong refresh rate, 50 hz rather then 25 hz, at least according to xrandr -q, and as a result the screen is blank. The xorg session is running however as I can vnc into it and it's running fine. I am using the nvidia driver from rpmfusion. Given that xorg.conf is re-written every reboot how can I add both a modeline and dualhead type config so that it 'sticks' after a reboot? Thanks in advance. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: xorg can't load qxl driver
Well, that was a nice idea, but even after using the regular patch process, ie patch -p1 < the patched drivers still crash my system with a segmentation fault. So I guess the patch has a few issues still to be worked out. I'm not sure what else to do but try to find an alternative to spice since these drivers won't work. Somebody mentioned they had qxl working with Fedora 13 I recall. Care to mention what version of the driver you were working with and whether there were any special tweaks required? > This link gets you a patch: > > http://cgit.freedesktop.org/xorg/driver/xf86-video-qxl/patch/?id=563f31ad081038ece8b5a5b525dd516fcd6ad0fd > > Or you can just clone the driver from git and build it using > ./autogen.sh. There are very few differences from the tarball. > > -- > Dan > ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: EXA classic problem with Xv
On Thu, Jun 10, 2010 at 8:56 PM, Corbin Simpson wrote: > 2010/6/10 Yves De Muyter : >> Is there any documentation available about the differences between >> exa_mixed and exa_driver ? Is exa_driver like complete handover of >> pixmap migration to the driver ? > > The three flavors: > ~ Classic. EXA handles offscreen pixmaps itself. Simple, except when it > breaks. > ~ Driver. EXA lets the driver control pixmap allocation and placement. > Great if you have a memory manager. > ~ Mixed. Like driver, but certain things have been tweaked to optimize > certain kinds of acceleration in a way that was never really explained > to me. mixed has parts from classic that avoid touching driver pixmaps directly for fallbacks (vram is slow to access from the cpu). Xorg's unique access patterns are not well suited to modern gpu's IMO. That's why mixed was made. Mixed would be useless if our world was 100% gpu accelerated, but unfortunately it's not. For mixed you can also fail prepare access on the frontbuffer, which allows you to make a driver that doesn't allow mapping of vram, provided you have a UTS and DFS hook that always works. For igp'ish hardware without dedicated memory and a decent memory manager, exa driver is preferred because it's the simplest driver mode and avoids overhead that is unneeded for such hardware. > > To go from driver to mixed is pretty simple; here's an example commit: > http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=577ff3ce922e457cc32f80d4365cb1da81552e72 > > ~ C. > > -- > When the facts change, I change my mind. What do you do, sir? ~ Keynes > > Corbin Simpson > > ___ > xorg@lists.freedesktop.org: X.Org support > Archives: http://lists.freedesktop.org/archives/xorg > Info: http://lists.freedesktop.org/mailman/listinfo/xorg > Your subscription address: madman2...@gmail.com > -- Life spent, a precious moment, in the wink of an eye we live and we die. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: EXA classic problem with Xv
2010/6/10 Maarten Maathuis : > On Thu, Jun 10, 2010 at 8:56 PM, Corbin Simpson > wrote: >> 2010/6/10 Yves De Muyter : >>> Is there any documentation available about the differences between >>> exa_mixed and exa_driver ? Is exa_driver like complete handover of >>> pixmap migration to the driver ? >> >> The three flavors: >> ~ Classic. EXA handles offscreen pixmaps itself. Simple, except when it >> breaks. >> ~ Driver. EXA lets the driver control pixmap allocation and placement. >> Great if you have a memory manager. >> ~ Mixed. Like driver, but certain things have been tweaked to optimize >> certain kinds of acceleration in a way that was never really explained >> to me. > > mixed has parts from classic that avoid touching driver pixmaps > directly for fallbacks (vram is slow to access from the cpu). Xorg's > unique access patterns are not well suited to modern gpu's IMO. That's > why mixed was made. Mixed would be useless if our world was 100% gpu > accelerated, but unfortunately it's not. > > For mixed you can also fail prepare access on the frontbuffer, which > allows you to make a driver that doesn't allow mapping of vram, > provided you have a UTS and DFS hook that always works. > > For igp'ish hardware without dedicated memory and a decent memory > manager, exa driver is preferred because it's the simplest driver mode > and avoids overhead that is unneeded for such hardware. That should read: and with a decent memory manager > >> >> To go from driver to mixed is pretty simple; here's an example commit: >> http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=577ff3ce922e457cc32f80d4365cb1da81552e72 >> >> ~ C. >> >> -- >> When the facts change, I change my mind. What do you do, sir? ~ Keynes >> >> Corbin Simpson >> >> ___ >> xorg@lists.freedesktop.org: X.Org support >> Archives: http://lists.freedesktop.org/archives/xorg >> Info: http://lists.freedesktop.org/mailman/listinfo/xorg >> Your subscription address: madman2...@gmail.com >> > > > > -- > Life spent, a precious moment, in the wink of an eye we live and we die. > -- Life spent, a precious moment, in the wink of an eye we live and we die. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: EXA classic problem with Xv
2010/6/10 Yves De Muyter : > Is there any documentation available about the differences between > exa_mixed and exa_driver ? Is exa_driver like complete handover of > pixmap migration to the driver ? The three flavors: ~ Classic. EXA handles offscreen pixmaps itself. Simple, except when it breaks. ~ Driver. EXA lets the driver control pixmap allocation and placement. Great if you have a memory manager. ~ Mixed. Like driver, but certain things have been tweaked to optimize certain kinds of acceleration in a way that was never really explained to me. To go from driver to mixed is pretty simple; here's an example commit: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=577ff3ce922e457cc32f80d4365cb1da81552e72 ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] libdrm 2.4.21
On Thursday 10 of June 2010, Eric Anholt wrote: Unresolved symbols found in: /usr/lib64/libkms.so.1.0.0 drmIoctl drmCommandWriteRead drmCommandWrite and the patch http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/libdrm/libdrm- kms.patch?rev=1.1 -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: EXA classic problem with Xv
I just made a test and indeed it looks like it is using the fullscreen pixmap. I'll fix the enless loop for now and look into migrating to one of the other schemes. Is there any documentation available about the differences between exa_mixed and exa_driver ? Is exa_driver like complete handover of pixmap migration to the driver ? What whas the initial idea about the switch to exa_mixed ? Is there any record about this discussion? A webpage? A mail? (google doesnt know much about it...) -Yves On Thu, Jun 10, 2010 at 01:16:00PM +0200, Michel Dänzer wrote: > On Don, 2010-06-10 at 12:54 +0200, Yves De Muyter wrote: > > Here you find the code: > > > > http://code.google.com/p/gma500/source/browse/trunk/xserver-xorg-video-psb/xserver-xorg-video-psb-0.32.1/src/psb_video.c > > > > The problem is on line 688. > > > > The code tries to find the pointer to the buffer and the offset, and if > > it doesnt find it, it calls exaMoveInPixmap(). > > > > I don't like the 'while' thing personally but I didn't write that code > > and are willing to change it, that's not the problem. > > FWIW I don't think it makes sense to try exaMoveInPixmap more than once. > > > The problem is that exaMoveInPixmap() doesnt do anything if the pixmap > > has a score that is 'PINNED', and that's the case here... > > As the pixmap was retrieved from a window, I *think* the only way it can > be pinned is if it's the screen pixmap (i.e. you're not using a > compositing manager, or it unredirected the fullscreen window). In that > case I think the problem is actually a spurious failure of > psbExaGetSuperOffset(), possibly due to an issue in exaGetPixmapOffset() > - there's recently been some discussion about that with drivers like psb > or geode. > > Of course these issues should be fixed, but in the long term it might > make sense for the psb driver to use the EXA 'mixed' or 'driver' pixmap > memory allocation scheme rather than the 'classic' one in rather special > ways prone to breakage. > > > -- > Earthling Michel Dänzer |http://www.vmware.com > Libre software enthusiast | Debian, X and DRI developer > ___ > xorg@lists.freedesktop.org: X.Org support > Archives: http://lists.freedesktop.org/archives/xorg > Info: http://lists.freedesktop.org/mailman/listinfo/xorg > Your subscription address: y...@connected.be ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: EXA classic problem with Xv
I just made a test and indeed it looks like it is using the fullscreen pixmap. I'll fix the enless loop for now and look into migrating to one of the other schemes. Is there any documentation available about the differences between exa_mixed and exa_driver ? Is exa_driver like complete handover of pixmap migration to the driver ? What whas the initial idea about the switch to exa_mixed ? Is there any record about this discussion? A webpage? A mail? (google doesnt know much about it...) -Yves On Thu, Jun 10, 2010 at 01:16:00PM +0200, Michel Dänzer wrote: > On Don, 2010-06-10 at 12:54 +0200, Yves De Muyter wrote: > > Here you find the code: > > > > http://code.google.com/p/gma500/source/browse/trunk/xserver-xorg-video-psb/xserver-xorg-video-psb-0.32.1/src/psb_video.c > > > > The problem is on line 688. > > > > The code tries to find the pointer to the buffer and the offset, and if > > it doesnt find it, it calls exaMoveInPixmap(). > > > > I don't like the 'while' thing personally but I didn't write that code > > and are willing to change it, that's not the problem. > > FWIW I don't think it makes sense to try exaMoveInPixmap more than once. > > > The problem is that exaMoveInPixmap() doesnt do anything if the pixmap > > has a score that is 'PINNED', and that's the case here... > > As the pixmap was retrieved from a window, I *think* the only way it can > be pinned is if it's the screen pixmap (i.e. you're not using a > compositing manager, or it unredirected the fullscreen window). In that > case I think the problem is actually a spurious failure of > psbExaGetSuperOffset(), possibly due to an issue in exaGetPixmapOffset() > - there's recently been some discussion about that with drivers like psb > or geode. > > Of course these issues should be fixed, but in the long term it might > make sense for the psb driver to use the EXA 'mixed' or 'driver' pixmap > memory allocation scheme rather than the 'classic' one in rather special > ways prone to breakage. > > > -- > Earthling Michel Dänzer |http://www.vmware.com > Libre software enthusiast | Debian, X and DRI developer > ___ > xorg@lists.freedesktop.org: X.Org support > Archives: http://lists.freedesktop.org/archives/xorg > Info: http://lists.freedesktop.org/mailman/listinfo/xorg > Your subscription address: y...@connected.be ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: xorg can't load qxl driver
On Thu, Jun 10, 2010 at 8:48 AM, Brian Milliron wrote: > Liang, > > I got my x windows back. I had to delete the qxl driver and copy over a > backup of the xorg.conf file I made, but I have restored my system to a > working state. > > However, it seems manually editing the source code for that driver is a > bad idea. :) If I were going to apply the patch as it is intended, > would that be done through git? I don't see a .patch file in that > archive so I don't think I can use the patch command to do it. Or would > I use diff to create a .patch file? This link gets you a patch: http://cgit.freedesktop.org/xorg/driver/xf86-video-qxl/patch/?id=563f31ad081038ece8b5a5b525dd516fcd6ad0fd Or you can just clone the driver from git and build it using ./autogen.sh. There are very few differences from the tarball. -- Dan ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: xorg can't load qxl driver
Liang, I got my x windows back. I had to delete the qxl driver and copy over a backup of the xorg.conf file I made, but I have restored my system to a working state. However, it seems manually editing the source code for that driver is a bad idea. :) If I were going to apply the patch as it is intended, would that be done through git? I don't see a .patch file in that archive so I don't think I can use the patch command to do it. Or would I use diff to create a .patch file? Brian > > 2010/6/10 Brian Milliron >> Thanks Robert, that is good info on spice, but not particularly relevant >> to my problems with qxl. They don't discuss qxl drivers at all on that >> wiki and I already have spice working with vga drivers, just not qxl. >> Maybe you can help me with the 2 puzzles Liang left behind? >> >> 1) This git link: http://cgit.freedesktop.org/xorg/driver/xf86-video- >> qxl/commit/?id=563f31ad081038ece8b5a5b525dd516fcd6ad0fd >> >> Unfortunately I'm too green to know what to do with this. The gzip >> archive contains some source files but no make or configure files. Do I >> overwrite the previous source files with the new git source files and >> use the old configure and make files? > > if you don't know how to apply a patch, you may just delete following line > in src/qxl_driver.c line 1234, then recompile it > > assert (((struct qxl_mode *)p->Private)->x_res == p->HDisplay); > assert (((struct qxl_mode *)p->Private)->y_res == p->VDisplay); > > > >> 2) His statement that "QXL Driver is included in debian unstable, you >> may build it for you ubuntu." >> >> Does he mean these drivers are unstable? >> http://xorg.freedesktop.org/releases/individual/driver/xf86-video- > qxl-0.0.12.tar.gz >> Because those are the ones I currently have installed. >> I tried using the ones he linked to here: >> http://ftp.de.debian.org/debian/pool/main/x/xserver-xorg-video- >> qxl/xserver-xorg-video-qxl_0.0.12-1.dsc >> But they require xserver-xorg-dev version 1.7.6.901 which I don't know >> where to get. > you have not install xserver-xorg-dev, so you may not compile the dpkg > package. if the first methord works, please forgot this one. > > Thanks, > -- > Liang Guo > http://bluestone.cublog.cn ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: EXA classic problem with Xv
On Don, 2010-06-10 at 12:54 +0200, Yves De Muyter wrote: > Here you find the code: > > http://code.google.com/p/gma500/source/browse/trunk/xserver-xorg-video-psb/xserver-xorg-video-psb-0.32.1/src/psb_video.c > > The problem is on line 688. > > The code tries to find the pointer to the buffer and the offset, and if > it doesnt find it, it calls exaMoveInPixmap(). > > I don't like the 'while' thing personally but I didn't write that code > and are willing to change it, that's not the problem. FWIW I don't think it makes sense to try exaMoveInPixmap more than once. > The problem is that exaMoveInPixmap() doesnt do anything if the pixmap > has a score that is 'PINNED', and that's the case here... As the pixmap was retrieved from a window, I *think* the only way it can be pinned is if it's the screen pixmap (i.e. you're not using a compositing manager, or it unredirected the fullscreen window). In that case I think the problem is actually a spurious failure of psbExaGetSuperOffset(), possibly due to an issue in exaGetPixmapOffset() - there's recently been some discussion about that with drivers like psb or geode. Of course these issues should be fixed, but in the long term it might make sense for the psb driver to use the EXA 'mixed' or 'driver' pixmap memory allocation scheme rather than the 'classic' one in rather special ways prone to breakage. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: EXA classic problem with Xv
Here you find the code: http://code.google.com/p/gma500/source/browse/trunk/xserver-xorg-video-psb/xserver-xorg-video-psb-0.32.1/src/psb_video.c The problem is on line 688. The code tries to find the pointer to the buffer and the offset, and if it doesnt find it, it calls exaMoveInPixmap(). I don't like the 'while' thing personally but I didn't write that code and are willing to change it, that's not the problem. The problem is that exaMoveInPixmap() doesnt do anything if the pixmap has a score that is 'PINNED', and that's the case here... Could it be mplayer that is creating the window region the wrong way? I can imagine alot of drivers don't touch the pixmap and simply overlay their video... -Yves On Thu, Jun 10, 2010 at 12:38:27PM +0200, Michel Dänzer wrote: > On Don, 2010-06-10 at 12:34 +0200, Yves De Muyter wrote: > > OK so i'm porting the 'poulsbo' driver to Xorg 1.7. What I'm working on > > right now is to make Xv work in the driver. What the Xv-code does is to > > get the address of the drawable, map it into SHM and ask the hardware to > > blit the videoframe onto that drawable. > > > > The problem is that the address of the drawable is not within our region > > of SHM pixmap memory, so we need to call exaMoveInPixmap, but that one > > doesnt work when the pixmap is pinned... > > It would probably help if you could point to the code in question along > with a specific example of a window being passed in and where exactly > the problem arises. > > > -- > Earthling Michel Dänzer |http://www.vmware.com > Libre software enthusiast | Debian, X and DRI developer > ___ > xorg@lists.freedesktop.org: X.Org support > Archives: http://lists.freedesktop.org/archives/xorg > Info: http://lists.freedesktop.org/mailman/listinfo/xorg > Your subscription address: y...@connected.be ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: EXA classic problem with Xv
On Don, 2010-06-10 at 12:34 +0200, Yves De Muyter wrote: > OK so i'm porting the 'poulsbo' driver to Xorg 1.7. What I'm working on > right now is to make Xv work in the driver. What the Xv-code does is to > get the address of the drawable, map it into SHM and ask the hardware to > blit the videoframe onto that drawable. > > The problem is that the address of the drawable is not within our region > of SHM pixmap memory, so we need to call exaMoveInPixmap, but that one > doesnt work when the pixmap is pinned... It would probably help if you could point to the code in question along with a specific example of a window being passed in and where exactly the problem arises. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: EXA classic problem with Xv
OK so i'm porting the 'poulsbo' driver to Xorg 1.7. What I'm working on right now is to make Xv work in the driver. What the Xv-code does is to get the address of the drawable, map it into SHM and ask the hardware to blit the videoframe onto that drawable. The problem is that the address of the drawable is not within our region of SHM pixmap memory, so we need to call exaMoveInPixmap, but that one doesnt work when the pixmap is pinned... I'm testing this using one of the latest mplayer -vo xv testfile.mkv -Yves On Thu, Jun 10, 2010 at 10:39:40AM +0200, Michel Dänzer wrote: > On Mit, 2010-06-09 at 22:18 +0200, Yves De Muyter wrote: > > > > I'm trying to port an older driver to XFree 1.7 and I'm facing an > > issue with EXA (classic). It seems that Xv's "PutImage" is calling our > > PutImage handler with a Drawable that is PINNED ? > > > > That means we cannot ever draw to it since exaMoveInPixmap() doesnt > > work on pinned pixmaps... > > The drawable passed to the PutImage hook is up to the client, not the > XVideo layer. Please provide more information about the problem. > > > -- > Earthling Michel Dänzer |http://www.vmware.com > Libre software enthusiast | Debian, X and DRI developer > ___ > xorg@lists.freedesktop.org: X.Org support > Archives: http://lists.freedesktop.org/archives/xorg > Info: http://lists.freedesktop.org/mailman/listinfo/xorg > Your subscription address: y...@connected.be ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: EXA classic problem with Xv
OK so i'm porting the 'poulsbo' driver to Xorg 1.7. What I'm working on right now is to make Xv work in the driver. What the Xv-code does is to get the address of the drawable, map it into SHM and ask the hardware to blit the videoframe onto that drawable. The problem is that the address of the drawable is not within our region of SHM pixmap memory, so we need to call exaMoveInPixmap, but that one doesnt work when the pixmap is pinned... I'm testing this using one of the latest mplayer -vo xv testfile.mkv -Yves On Thu, Jun 10, 2010 at 10:39:40AM +0200, Michel Dänzer wrote: > On Mit, 2010-06-09 at 22:18 +0200, Yves De Muyter wrote: > > > > I'm trying to port an older driver to XFree 1.7 and I'm facing an > > issue with EXA (classic). It seems that Xv's "PutImage" is calling our > > PutImage handler with a Drawable that is PINNED ? > > > > That means we cannot ever draw to it since exaMoveInPixmap() doesnt > > work on pinned pixmaps... > > The drawable passed to the PutImage hook is up to the client, not the > XVideo layer. Please provide more information about the problem. > > > -- > Earthling Michel Dänzer |http://www.vmware.com > Libre software enthusiast | Debian, X and DRI developer > ___ > xorg@lists.freedesktop.org: X.Org support > Archives: http://lists.freedesktop.org/archives/xorg > Info: http://lists.freedesktop.org/mailman/listinfo/xorg > Your subscription address: y...@connected.be ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: EXA classic problem with Xv
On Mit, 2010-06-09 at 22:18 +0200, Yves De Muyter wrote: > > I'm trying to port an older driver to XFree 1.7 and I'm facing an > issue with EXA (classic). It seems that Xv's "PutImage" is calling our > PutImage handler with a Drawable that is PINNED ? > > That means we cannot ever draw to it since exaMoveInPixmap() doesnt > work on pinned pixmaps... The drawable passed to the PutImage hook is up to the client, not the XVideo layer. Please provide more information about the problem. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
