[Nouveau] [Bug 73358] [regression?][nv34] adobe flash + firefox -> DATA_ERROR
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Fri Jan 17 11:55:32 PST 2014
https://bugs.freedesktop.org/show_bug.cgi?id=73358
--- Comment #31 from Ronald <ronald645 at gmail.com> ---
Yes, I relocated (In reply to comment #30)
> (In reply to comment #29)
> > > > And reran the tests. Same garbled screen as in comment #23. Sorry.
> > >
> > > Blast! What about messages in dmesg? Do you still see
> > >
> > > subc 7 class 0x0697 mthd 0x0208 data 0x00000120
> >
> > Yes, (notice that the fourth line is different)
>
> Very unfortunate. I guess I'll have to look for a different cause :(
Thomas Edison
..."I have not failed 700 times. I have not failed once. I have
succeeded in proving that those 700 ways will not work. When I have
eliminated the ways that will not work, I will find the way that will
work."
> > I didn't even knew libvdpau was provided for nv34. Let me know if I can
> > help. This machine just got upgraded from 512 to 1536 megs of ram making it
> > pretty usable again. Testing is a lot easier as well, let me know when you
> > have something new.
>
> VDPAU = Video Decoding AND Presentation. What's being used is the
> presentation aspect -- it's essentially like Xv, but fancier. And I believe
> it's what's hanging stuff. Quick test -- remove any instance of
> libvdpau_nouveau.so(.*) -- does everything become better? If not, it must be
> coming in via OpenGL or something.
Yes, moving /usr/lib/vdpau away makes the kernel errors go away. Which is what
I did right now. So it's vdpau (narrows it down I hope?).
Furthermore, when I do that I get this message:
Failed to open VDPAU backend libvdpau_nouveau.so: kan gedeeld objectbestand
niet openen: Bestand of map bestaat niet
(cannot open shared library: File or directory does not exist)
Which makes me wonder why error messages like these get through, despite all
the attempts with fprintf(stderr within Emil's patch xD yielding 0 results.
> While there is video decoding HW on the NV34, it's only semi-supported; I've
> disabled this support since it appears to hang my NV34 and I haven't
> identified the cause. I believe it's actually something related to the
> NPOTness of the textures, but I don't know for sure. My plan was to create a
> standalone VPE1-supporting libXvMC library (well, the libXvMCW interface)
> that renders using the hw video overlay (available on pre-NV40 cards), but
> that requires some libdrm and possibly kernel changes to support the VPE1
> command stream. One could, conceivably, create a VPE2-using standalone
> libXvMC library that uses the hw overlay to render instead of the 3d
> hardware. However the only cards that have VPE2 and are pre-NV40 are NV31
> and NV34. The rest of the NV3x's (and NV17/NV18) have VPE1 only.
>
> If you're interested in working on this, come over to #nouveau at freenode,
> would be happy to provide some pointers.
I would love to help, but I cannot code. To this point, I have always gotten
away by reading lot's of (badly written) manpages and bash scripting. If you
bend with the system it will be nice to you. Never had the courage to touch a
line of C code. Maybe it's time ...
Is it possible to contribute after an initial phase of self study? What kind of
topics would I need to get familiair with?
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20140117/dd715cfc/attachment-0001.html>
More information about the Nouveau
mailing list