Bug 389441

Description of problem:
Many manufacturers customise thier bios' to add functionality to create some 
kind of product differentiation (this is good). This feature is being abused by 
manufacturers to lock hardware to a specific OS by disabling functionality if a 
particular OS is not present (this is bad).

To work around these issues the user has to look at the ASL code and figure out 
why something may not be working in linux but it does in the OS that came 
preinstalled. To enable these features the ASL code might have to be modified 
and those modifications tersted. SuSe and some other linux enable a feature in 
thier kernel (by default) that allows a custom bios dsdt table to be loaded. 
This is not recomended by the kernel developers as this functionality should be 
switched off in production kernels. However not having this functionality 
available in Fedora precludes it from being a recognised platform for 
developing fixes for bios quirks.

Fedora turns over it's kernel to new versions quite often (relatively) and if 
someone is using Fedora in preference to other linux varieties he/she will need 
to recompile the kernel with the custom dsdt options enabled each time. this is 
a bit of a drag.

If a kernel can be made available in the development repos with the custom dsdt 
options enabled then the developer can keep up with kernel updates and keep 
thier dsdt developments going.


Version-Release number of selected component (if applicable):


How reproducible:
There is no kernel rpm available with the custom dsdt options available.

Steps to Reproduce:
1.
2.
3.
  
Actual results:
Cannot load a custom dsdt by default.

Expected results:
ability to be able to use a custom dsdt in a development environment whilst 
keeping up with kernel developments (especially in the ACPI drivers and 
hopefully also when WMI is exposed to the linux kernel).

Additional info:

I believe that this would entail setting up a kernel koji build with the custom 
dsdt features enabled. Each time the kernel is updated the i386 and x86_64 
default kerrnels can have these features enabled and a development kernel 
created. the user can point his yum upgrades to the development repo to get 
kernel updates.

This would be very useful for people trying to get thier laptops working with a 
number of things: hotkeys, suspend/hibernate, adding functionality to the newer 
tablet pc's which can also be notebooks. Probably a lot more.

Although there might be an argument saying that if someone is going to be doing 
this kind of work they should be able to recompile thier kernel and not make a 
fuss. There is also the argument that devlopment time is given voluntarily for 
the benefit of all and that time may be limited. If a distro can help out by 
saving a half an hour here or there for a (possibly small) bunch of users it 
might be worth considering especially if the thing once setup can be automated 
(Spec file customisation, koji building) :)

Thanks
R