On Mon, 10 Feb 2014 13:26:24 +0100 Jesús J. Guerrero Botella <jesus.guerrero.bote...@gmail.com> said:
> Hi again. > > Just for the sake of testing and based on the suggestion of someone at the > Gentoo fora, I recompiled the whole E stack to use X instead of xcb. I have > no idea if it makes a difference or if it's just coincidence that E hasn't > locked my machine for a few days. xcb? wtf? don't use that! we don't tesat that build and it has known missing implementations. only use xcb if you REALLY KNOW WHAT YOU ARE DOING. ugh. gentoo use flags. please please please stop with this! we don't have xcb as the default for good reasons. almost no one really pusehs or tests xcb - and xcb needs xlib still for opengl to work anyway so you don't get benefits the moment you need gl. it's meant for really tiny small systems where you could dump all of xlib (and don't have gl). :) please please please ... just use the DEFAULT options and any relevant options documented in the README as suggested or useful for your case. :) > By the way, yesterday I was thinking (sometimes I do) and reminded for no > particular reason that xscreensaver managed to freeze my box exactly two > times in the past. As far as I remember, it's the only other userland > program (along with enlightenment) that has managed to do so, thought I > don't remember what exact screensaver produced this result. Opengl was > enabled, that's for sure > > The problem is probably in some hidden place down the r300 opengl stack and > into the kernel radeon driver. But it's hard to guess exactly where : > > In any case, this thread purpose was to be able to start E, which was > achieved by updating to e18, so the case is closed. I have some other > problems with E, probably due to my own ignorance about the platform, but > I'll investigate them when I get the time to do so. > > Thank you everyone in the thread :) as above. seriously. README. it's there for a reason. options are defaults for a good reason. :) > 2014-02-08 15:52 GMT+01:00 Jesús J. Guerrero Botella < > jesus.guerrero.bote...@gmail.com>: > > > @Alan McKinnon and @Mick, I will double check that, though I've had my > > amount og Gentoo during more than a decade and I highly doubt that > > leftovers and ABI breakage are an issue in this concrete case. > > > > @Karsten Haitzler, if you can give me some hint on what and how to look, > > I'm willing to do so. I have some gdb-foo. But if the only way to solve the > > bug is to buy a new laptop, then we're stuck. > > > > I perfectly know that for this to happen, there must be a code path to it > > in the kernel, up to X And the driver, mesa, the toolkit, and, finally, the > > application. Even if it's an unconventional path (probably the case, > > because as said no other software failed this way, ever). But, please, > > don't tell me nouveau is perfect and never freezes, because I've seen it > > fail in ways that are more colourful than a kaleidoscope. > > > > Thanks everyone for answering :) > > El 08/02/2014 15:33, "Mick" <michaelkintz...@gmail.com> escribió: > > > >> On Saturday 08 Feb 2014 13:45:55 Carsten Haitzler wrote: > >> > On Sat, 8 Feb 2014 12:34:34 +0100 Jesús J. Guerrero Botella > >> > >> > actually the ati chips are not one of the better supported. i have had > >> NO > >> > end of trouble with them. slowness, bugs, freezing etc. fglrx ati > >> drivers > >> > were the culprit at the time with the open drivers simply not working > >> for > >> > me at all (zero display). so as per this thread.. yes - userspace should > >> > not be able to bring machines down like this... > >> > >> I used to have problems like this, but may be going back 10 years now ... > >> these days hard crashes are a rarity. The last time I had such a crash it > >> involved a Pentium 4 with a R360 card, running ... KDE! Ha, ha! No > >> problems > >> with e18. > >> > >> > >> > UNLESS the drivers have major bugs. and they do. i solved my problems by > >> > never touching an ati chip again. that was my solution, but let me just > >> > disabuse you of the image that ati chips (eg r300) are so well supported > >> > and solid. in my experience, they are not. the fact that sysreq wouldn't > >> > even work is a big hint... your drivers have problems. it just so > >> happens > >> > that e is tickling them. > >> > > >> > people do say the newer radeon open source drivers work well, but i've > >> > never gone back after my horrible experiences. i stick to intel or > >> nvidia > >> > (with nvidia drivers and one test machine with nouveau) and i don't see > >> > anything close to the problems you see there. > >> > > >> > so my tip is... avoid fglrx like the plague and try new radeon drivers, > >> and > >> > even then... just change gpu's. also be aware the r300 is from memory an > >> > old old old gpu. it may simply not work with compositing and opengl. > >> evas > >> > needs opengl2.0 support (full glsl shader support for fragment and > >> vertex > >> > shaders). so without this it will fall back to software compositing. > >> > depending on your cpu, gfx drivers, memory bus architecture, location of > >> > gpu on the mem bus etc. this may or may not work well for you. given the > >> > abysmal readback speeds i saw with fglrx back in the day, the compositor > >> > in sw mode relies on readback for any updates... and this will hurt > >> badly. > >> > all the reading back from pixmaps plus writing to them may be tickling > >> > your driver bugs too. > >> > >> I am running RV730/M96-XT [Mobility Radeon HD 4670] (ChipID = 0x9488) > >> which is > >> 5 years old on my laptop and very rarely I may get e17/18 to crash, but by > >> clicking on 'Restart' or some such option that pops up it reloads and > >> carries > >> on. No hard locks. > >> > >> In defence of radeon I should say that the only time that I had to look > >> into > >> which driver was needed and which firmware blob was back when I first > >> installed Linux on this machine and rolled its first kernel. People with > >> NVidia post all sort of problems of incompatible driver version with > >> particular kernels, but with radeon 'it just works'™. > >> -- > >> Regards, > >> Mick > >> > >> > >> ------------------------------------------------------------------------------ > >> Managing the Performance of Cloud-Based Applications > >> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > >> Read the Whitepaper. > >> > >> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk > >> _______________________________________________ > >> enlightenment-users mailing list > >> enlightenment-users@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-users > >> > >> > > > -- > Jesús Guerrero Botella > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk > _______________________________________________ > enlightenment-users mailing list > enlightenment-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-users -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
