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
I have only read the first two parts but I already can't take it seriously anymore.
Originally Posted by birdie
It's supposed to be the "2012" edition, but...
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...
Originally Posted by 89c51
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...
... because it's the kernel driver's job, not mesa's.
Originally Posted by TAXI
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.
Originally Posted by ChrisXY
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 ?
Originally Posted by 89c51
Does this apply to UVD as well as power management, or should we keep working on UVD ?
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