I'm just waiting for an article which will look at all of Wayland's current shortcomings.... bahahahahah, just kidding, that's not happening. Actually, I was worried because we haven't had a "Mesa is a miserable failure" article in a while.
Wait for the next article where somebody fixes indentation in Wayland (!!) then we'll have an article about the future of the Linux desktop"This next-generation display server brings MORE exciting changes! A header file was renamed!! Meanwhile, Mesa still doesn't support OpenGL 3.2, 3.3, 4.0, 4.1 and 4.2......... Here's a photo of beer."
![]()
MESA PEOPLE CANNOT DO ANYTHING ABOUT POWER MANAGEMENT AND VIDEO ACCELERATION.
ITS UP TO NVIDIA AND AMD TO RELEASE DOCS
Hope this makes it clear
First, thank you very much to Mesa, Gallium and OpenSource drivers developers.
Good point. I think the criticisms are correct as long as discuss how the project could be improved with our help. Anyway I think that Phoronix helps a lot with their benchmarks and articles, but sometimes the articles are a bit sensationalist
The only thing that I have to say is that I could not run "SteamPac 3d" with Mesa 8:
http://steampac3d.blogspot.com.es
Now with Mesa 9 (Nouveau driver) works as fast as with proprietary drivers.
PD:I see that write everything in capital letters and large size is allowed in this forum. It's very annoying.
Last edited by YAFU; 10-10-2012 at 06:21 AM.
I have only read the first two parts but I already can't take it seriously anymore.
It's supposed to be the "2012" edition, but...
1.1 PRIME/DMA-buf?
2.1 2012 edition. He/She links to SLASHDOT THREADS from 2009 and 2007. WAT
http://linuxfonts.narod.ru/files/audio.png I don't have experience about pulseaudio + multiuser but I do remember the "linux sucks" talk by datenwolf where he did a live demonstration how consolekit transferred the access rights on a fast user switch. Is the problem that the first user's pulseaudio would still have access even if it technically shouldn't have?
http://linuxfonts.narod.ru/files/linuxaudio.png No. Just no. At first sight I saw about five programs/libraries that are also available on windows. You have such a headache on windows because you can choose between directly outputting sound to the windows sound architecture or using SDL or openal? Every time someone posts this they don't seem to understand what it means: Most of the items shown are abstractions that are there to faciliate certain things or make sure you don't need to write sound system specific code.
http://linux.slashdot.org/comments.p...5&cid=39847439 No. That his sound doesn't work (yes, "doesn't work" is his whole description) out of the box with pulseaudio while alsa works is obviously a bug. But he doesn't even know that dmix has been enabled for years now? And then his ranting is incoherent that because everything was still set to pulse it uses still pulseaudio and thus sound mixing worked... So why does it suddenly work now, and how, after he purged pulseaudio? Did he not kill pulseaudio and it was still running from memory? Still, why did it work with pulseaudio now and not before? Sorry, if you rely on incoherent rants that have no reasonable description whatsoever of what the problem is you're gonna have a bad time with me.
...
This is not 100% true. After all the radeon driver is open source, so anybody could write proper power management. See what nouveau did without any documentation? Why shouldn't the same being possible for PM (and UVD) on the radeon side? The problem is that AMD employees can't release it (AFAIK both, proper PM and UVD code has been written in-house) cause of stupid lawyers and mesa devs don't want to do it cause they fear that AMD releases their in-house work right before (or after) they have finished. IIRC at least one of the top mesa devs knows how the PM should work, but don't code it...
Some 3rd party programmer should step in right now, RE the proprietary drivers PM code, write a open source implementation and do a pull request. Yes, I know, this is unlikely to happen...
Also dave airlie (airlied), who is the kernel graphics maintainer (read: he knows stuff about linux graphics), mentioned that they cannot do anything proper about it until AMD releases the appropriate documentation. Which is not going happen.
If someone reverse engineers it -and i thing the same goes for nvidia- then you will probably get proper dynamic PM.
The same for video acceleration.
Are you saying we should stop working on trying to release PM information because you know it's never going to happen ? If so, can you provide some details so we don't waste any more time ?
Does this apply to UVD as well as power management, or should we keep working on UVD ?
Thanks,
JB
my humble sugestion:
1. gather money(xorg foundation) for looots of cheap cards (too burn)
2. set up a (semi)automated blackbox rig or two
3. get some1 dumb enough to read hexdumps all day
4. lock him/them in a room with the rig's for a month, no proper food till its all figured out
5. ??
6. profit