If I set the "NoAccel" flag in X then everything worked fine. And it seems to have the same speed for the tasks I tested (= where it is needed). Yes, that does make me feel silly.
Feedback anyways (and a LTSP patch request): > I've attached a tarball with the cx5530 audio driver that I add to the > ltsp kernels. > > I've also attached an X.org patch that should apply to X.org 6.8.0. > > We've been having some trouble with the video on the 5530's. it will > lock up occasionally. After some trouble getting X.org 6.8.0 compiled (syntax errors in xdm, was using GCC 3.4, of course I didn't need that so I'm fine) it turned out that it didn't do any better. The geode driver that you sent the patch for locked up the client completely when used (same as LTSP 4.1's X.org 6.7.0 geode driver, I should better change the geode reference to nsc in my /etc/vidlist). And while the nsc driver worked fine, it had the same won't-initialize-40%-of-the-time problem as the old one. Which brings me to: As you already have a downstream patching system, could you patch the nsc driver there? I found the patch in X.org's CVS, but it seems it isn't included in 6.8.0 so who knows when it will be around... I don't have the LTSP X.org sources so you'll have to get it verbally (or you can send me your LTSP 4.1 xc/programs/Xserver/hw/xfree86/drivers/nsc/gfx/disp_gu1.c and I can make it): In gfx/disp_gu1.c there are calls to gfx_reset_video. After the first one there is a gfx_delay_milliseconds (because it must wait for the cx5530 to catch up). The patch is to do the same on the other gfx_delay_milliseconds there. There is also one in disp_gu2.c, I guess it can't hurt to patch it (?) but it never caused problems for me. If you do then of course I'll test it. Audio driver: No options available to change the behaviour. And getting it compiled seems to much work to make it worth it for the debug messages. I tried installing the demo version of 4Front's OSS, but had to give up (it naturally required a kernel-version-dependant wrapper module, which would be more work than it is worth). More wierdities: Turns out that the problems are specific to GTK widgets being displayed on the rightmost 40 pixels. (And one QT widget, the horizontal splitter in K3b when moved). So I guess the problem is: Some certain accelerated X commands overwrite the sb16 emulation layer's memory if used in the rightmost 40 pixels (and vice versa, the emulation layer does overwrite X memory too). Next stop is the Kino source to enable sound over the network in it, then I'll have a LTSP video editing studio! // Dag Sverre ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php _____________________________________________________________________ Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: https://lists.sourceforge.net/lists/listinfo/ltsp-discuss For additional LTSP help, try #ltsp channel on irc.freenode.net
