Bug 389441 - A bios development kernel (in the development repo) to assist in developing drivers for laptops
A bios development kernel (in the development repo) to assist in developing d...
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-11-18 10:50 EST by Rehan Khan
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-11-26 22:51:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Rehan Khan 2007-11-18 10:50:58 EST
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:
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) :)

Comment 1 Dave Jones 2007-11-26 22:51:52 EST
already vetoed countless times upstream, and we don't intend to diverge.
Comment 2 Rehan Khan 2007-11-27 07:17:50 EST
Vetoed on the basis that if Linux devs don't fix it then hardware developers 
will have more incentive to make thier harware work with it. Unfortunately this 
is not happening in the real world and indeed is getting worse with the latest 
Vista laptops which specifically switch off functionality if the hardware is 
not running vista.

if ( vista ); then
    not just the bells, but also the whistles.
    who cares? Just tell them it's not supported.
Oh well, I guess hacking at the hardware it is then.

Note You need to log in before you can comment on or make changes to this bug.