From: Darren S. <li...@yo...> - 2006-05-30 23:05:57
|
I demand that Matthias Hopf may or may not have written... > Darren, > On May 30, 06 00:33:06 +0100, Darren Salt wrote: >> Software: >> gxine i386 CVS HEAD >> xine-lib i386 1.1.1 + patches (see .sig) >> X client libs i386 Debian unstable as of 28/5, i.e. X.org 7.0 >> X server amd64 ditto >> kernel amd64 2.6.17-rc5 >> Relevant hardware: Radeon 9200SE (RV280) >> Problem: sometimes lirc/irexec (reading from cx88 IR) cause two copies of >> gxine to be started, being passed an MRL for VDR. This causes one copy to >> use Xv and the other to use OpenGL - and the latter hangs, freezing the >> whole desktop until it's killed. Starting it on its own, adding '-V >> opengl', also causes this. (As a result, gxine has gained a watchdog >> function...) > If the whole system freezes with -V opengl, it's a driver bug. Presumably by "whole system", you mean at least X. Killing gxine is enough to allow things to continue, though the first time that I saw this problem, it looked worse since (a) X wasn't responding to the likes of NumLock and (b) remote login needed another machine to be available... > That should never ever happen. 32bit -> 64bit interfaces in DRI had been > buggy for quite a while, Egbert Eich submitted a patch some time ago that > should have fixed this. Hmm. Looks like this was applied, at least to the kernel. > I assume opengl is selected automatically, because the X driver only allows > for a single xv surface to be present at the same time. opengl is typically > the next best choice, if you don't like that change the priority in > src/video_out/video_out_opengl.c:1986 to a lower value. I could, but that isn't really ideal since I'm using the same source tree for building .debs for local use and for my apt repository. > Unfortunately I don't see a way to dynamically decide whether to use the > OpenGL plugin or not, I would love to add a switch. That /would/ be nice, yes... >> The OpenGL output plugin works fine if I use 64-bit builds of gxine & >> xine-lib (except that the video widget tends to be blanked - probably my >> fault), which makes me suspect either the kernel or X; it also seems to >> work fine with xine-ui (32-bit), which makes me wonder exactly what it's >> doing differently and what I should be doing to gxine to get it to work >> properly. > Hm. I think this points to the right direction (that xine is working). See > below. Once I'm happy with some xine-lib fixups which I've been playing with this evening, I'll have a look at that. One fixup is related to Ubuntu bug 47357; the other I'll post about separately. > I also had this with xine-ui with the radeon driver, but I assume it was a > driver bug (never showed up with fglrx or nvidia, and I cannot reproduce). Probably fixed, then... >> I recall the OpenGL plugin from 1.0.x working with gxine. I've tried older > Then you were probably the only one. [...] That or I'm misremembering :-) >> builds of gxine with the current plugin and all fail in the same way >> (except that 0.3.3 doesn't even manage to open the main window before >> hanging). > The gui must send a XINE_GUI_SEND_SELECT_VISUAL before creating the window, > and it must use the visual that is returned by this call. That's missing. > The opengl output driver is the only plugin that uses this message, and it > absolutely, desperately, needs it. It also relies on > XINE_GUI_SEND_WILL_DESTROY_DRAWABLE and XINE_GUI_SEND_DRAWABLE_CHANGED > being sent by the gui. They were used when gxine used separate windowed-mode and full-screen drawables, and were discarded when I rewrote the full-screen code for 0.5.0. It's possible that I still need WILL_DESTROY_DRAWABLE when gxine shuts down, although I don't think so. > Maybe you find a difference in behavior here between xine-ui and gxine. Could be :-) >> Note that a 32-bit X server isn't an option without also using a 32-bit >> kernel since that messes up OpenGL in other ways: >> <URL:http://www.youmustbejoking.demon.co.uk/glxgears.png> > I thought this had been fixed recently as well, but I can be wrong, of > course. Possibly. Or maybe it got broken again :-| -- | Darren Salt | linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | <URL:http://www.youmustbejoking.demon.co.uk/progs.packages.html> It's sweet to be remembered, but it's often cheaper to be forgotten. |