glxgears lock up MDK9.2 with radeon 9200

2003-10-28 Thread Emmanuel Allaud
Hi all, I just installed a MDK 9.2, and as the agpgart module seems OK with my nForce2 chipset, I also loaded DRI. All logs are OK, the dri modules load correctly; but if I launch glxgears it locks up solid (hard reset only to get rid of it). I use the radeon driver of MDK9.2 for my radeon

Re: Adios amigos!

2003-10-27 Thread Emmanuel ALLAUD
Raymond Jennings wrote: I fear that my membership has not been too helpful. I'm just a newbie, and Xfree86 is _way_ out of my league. Therefore, I have unsubscribed. If anyone wants me to get back on, please reply privately at [EMAIL PROTECTED] (I am no longer listed at XFree86.org). If I

Re: Kernel Module? On second thought...

2003-10-20 Thread Emmanuel ALLAUD
Mike A. Harris wrote: On Fri, 17 Oct 2003, David Fox wrote: I think that the wisest approach is, instead of suggesting a kernel module to the XFree86 folks, you do two things. First, suggest a kernel module to the Linux folks that implements a protocol for accessing the resource you are

Re: Kernel Module? On second thought...

2003-10-20 Thread Emmanuel ALLAUD
Emmanuel ALLAUD wrote: Mike A. Harris wrote: On Fri, 17 Oct 2003, David Fox wrote: I think that the wisest approach is, instead of suggesting a kernel module to the XFree86 folks, you do two things. First, suggest a kernel module to the Linux folks that implements a protocol

Re: What about a kernel module?

2003-10-10 Thread Emmanuel ALLAUD
Mark Vojkovich wrote: On Wed, 8 Oct 2003, Emmanuel ALLAUD wrote: Juliusz Chroboczek wrote: I'd like to suggest that you implement device-specific code as a kernel module. Well, that won't happen; we already have working portable driver code in userspace, and there's

Re: What about a kernel module?

2003-10-09 Thread Emmanuel ALLAUD
Juliusz Chroboczek wrote: I'd like to suggest that you implement device-specific code as a kernel module. Well, that won't happen; we already have working portable driver code in userspace, and there's no chance we'll port that to the Linux kernel. On the other hand, I do think that we'll

sched_yield futexes

2003-09-25 Thread Emmanuel Allaud
/I did not have news from my request on linux-kernel, but I came across this interview of Rusty Russel where he talks about futexes (URL : http://kerneltrap.org/node/view/892) : / / - / /Rusty Russell/: OK, a futex (Fast Userspace Mutex) isn't a mutex at all. It was in a (much) earlier

Re: Exporting sched_yield to the drivers

2003-09-25 Thread Emmanuel Allaud
Mark Vojkovich wrote: Can we at least agree to export an xf86Yield() function? It will be sched_yield() on whatever plaforms support it, a noop on others. If somebody comes up with something better to implement it with, then great. I have no voice on that but still : I think this would

Re: Exporting sched_yield to the drivers

2003-09-23 Thread emmanuel ALLAUD
--- Egbert Eich [EMAIL PROTECTED] a écrit : Mark Vojkovich writes: Can we export to the drivers some function that yields the CPU? Currently alot of drivers burn the CPU waiting for fifos, etc... usleep(0) is not good for this because it's jiffy based and usually never returns

Re: Exporting sched_yield to the drivers

2003-09-23 Thread emmanuel ALLAUD
--- Mark Vojkovich [EMAIL PROTECTED] a écrit : On Tue, 23 Sep 2003, [iso-8859-1] emmanuel ALLAUD wrote: This is perhaps a dumb idea, but could the futexes help here? I don't know if they have equivalent on other OSes than Linux. Bye Manu I don't see how they help. The problem

Re: Exporting sched_yield to the drivers

2003-09-23 Thread emmanuel ALLAUD
--- Mark Vojkovich [EMAIL PROTECTED] a écrit : On Tue, 23 Sep 2003, [iso-8859-1] emmanuel ALLAUD wrote: I'm assuming futexes are some interprocess mutex mechanism? If so, I don't see how this helps. Yes it is. Actually I am not familiar with them either

Re: Exporting sched_yield to the drivers

2003-09-23 Thread emmanuel ALLAUD
--- Mark Vojkovich [EMAIL PROTECTED] a écrit : On Tue, 23 Sep 2003, [iso-8859-1] emmanuel ALLAUD wrote: The problem with yielding is that you can have interactivity problem if the computer is loaded enough. If you don't yield you have an interactivity problem. What good

Re: i855 and 1400x1050

2003-09-15 Thread emmanuel ALLAUD
Hi, I read your mails on xfree-devel about your wiki page. I actually had also setup one via the xwin site. The link is : http://xwin.org:9673/xwin/XJANITOR There are a lot of stuff about compiling XFree and also about debugging X (using xscope, valgrind for the mem leaks and other

Arch specific optimizations?

2003-09-03 Thread emmanuel ALLAUD
Hi all, in the thread about RENDER extension, it has beem mentionned that XFree was performing much slower (ie 2 or 3 times slower) than imlib2 (sorry I don't really remember in which tasks). The reason seemed to boil down to the fact that imlib2 has arch specific asm instructions (I think

Re: RENDER question

2003-08-29 Thread emmanuel ALLAUD
--- Thomas Winischhofer [EMAIL PROTECTED] a écrit : Carsten Haitzler (The Rasterman) wrote: That is strange. Without acceleration, I get 9.7 1.7 2.3 Seems imlib uses the video RAM. definitely not. imlib2 only uses system ram - all its buffers are a direct result of malloc() :)

Re: XInput: The device type in XListInputDevices comes up again...

2003-08-29 Thread emmanuel ALLAUD
--- Bryan W. Headley [EMAIL PROTECTED] a écrit : Egbert Eich wrote: Bryan W. Headley writes: snip Sorry, just telling you how it is, now. hotplug listens to a kernel message layer, and invokes shell scripts in response to events. These scripts can load/unload kernel device drivers,

Re: Rant (was Re: ATI Drivers.)

2003-07-25 Thread emmanuel ALLAUD
--- Kendall Bennett [EMAIL PROTECTED] a écrit : David Dawes [EMAIL PROTECTED] wrote: Frankly, your own rants against XFree86 and some of its volunteers recently are no different than this. It sure left a bad taste in our mouths. There is a sickening propensity towards hostile and