@devs: Won't Implement? ( FS#15112 )
The patch still does not work in 100% cases, and I doubt it will be updated quickly when .31 is released.

not having this patch would be a serious miss, and would surely make arch lose a number of users since recompiling each kernel release is a drag. i agree though that it would have to work 100% to get included.

can this ticket be left open until more information is available, and/or a final version of the patch is available?

I really don't think adding beta code to production packages is a smart idea. The need for a custom DSDT is very small, I'd follow #15112 and close this with a won't fix.

@Glenn: the number of users that need a custom dsdt is not that small, for instance every new sony vaio owner needs one to get their screen brightness working. sony's dual-lamp screens are insanely bright and are unusable on the default (highest) level. see this for instance:

http://vaioubuntu.wordpress.com/2008/12/04/finally-a-brightness-how-to-for-vaio-fw-series/

218 comments in that thread alone, sadly enough sony refuses to release better firmware.

without a dsdt-initrd, the amount of extra time and effort that is forced upon us to get a decent working system is just crazy, while the solution is simple -- as long as the patch is of proper quality ofcourse. the beta code itself doesn't need to get included, but it would be good to test and consider the final version for inclusion.

in my opinion every binary distribution should facilitate custom dsdt's, there's a lot more trivial stuff in the arch-patchset.

218 comments in some thread doesn't really prove anything. It's still a very small part of the total users out there.

then please tell me how many people are using Arch Linux on a "Dell Optiplex 360 with 0T656F", for which we include a patch to "handle problems with rebooting"? and how's your Digi AccelePort holding up these days?

it's easy to play the semantics game Glenn, i'm willing to start challenging 90% of Arch's patches with the same argument. in the end, almost all the patches we have are quirks for small groups of people. that's the whole idea of patching, otherwise it would just be in the kernel. it's just silly to wave problems away just because you don't suffer from them yourself.

Guys, please don't flame here ;)
the main issue is that this patch needs constant updates for every (second) major kernel version, and judging from the speed of such updates coming - we won't have a new patch for .31 available in time and I'm not sure existing patch will work. And it does not work 100% now.

> not having this patch would be a serious miss, and would surely make arch lose a number of users since recompiling each kernel release is a drag
I don't see a big problem here. It's easy to create a custom kernel package with this patch included or even easier - someone could provide such kernel in AUR.

I'm not saying that we should not include the patch just because it's easy to do manually.
My point is that in case this patch won't be included in the default kernel - it's not that serious problem.

is the old dsdt hook available somewhere so i can see what it does?

Well, we decided not to wait with removing because nothing worked.
It seems it is still not working correctly for all and this patch is a nasty hack anyway.
from my side a -1 to include it again.
Thomas an opinion on it?

Hello,

i would also like to give my support with keeping this patch in (once it works of course), because i am not willing to spend hours upon hours of my time learning how to compile a kernel, all of the options, just so i can have a custom dsdt, where other distros like debian/ubuntu can just run "sudo update-initramfs -u -k kernel-version" and be done with it. My laptop actually suspends and hibernates correctly with a custom dsdt (which is very important for a laptop!) and so does my regular PC, and if this gets removed and users are forced to compile a new kernel every time a small update comes out, i will (and i imagine) many other users will just find a different distribution. Its stupid to have to compile a kernel just to get a custom dsdt to load =/

As I predicted - there is no patch for 2.6.31 yet, but the new kernel is going to hit Core soon.
Make conclusions.

I know that people are lazy with building own kernel with dsdt patch,
but we can't just add dsdt patch then remove it (because no patch for new version is ready) then add again and so on.