On Wed, Feb 20, 2008 at 07:21:57PM +0100, Thomas Renninger wrote: > On Wed, 2008-02-20 at 17:32 +0000, Matthew Garrett wrote: > > Let's look at this differently. Most hardware is produced by vendors who > > don't care about Linux. We need to make that hardware work anyway. > Not really. If you buy machine noname XY, you have to face the fact that > HW may not work on Linux correctly. No. You have failed. Do not pass go. > You can try fix to it, but you > cannot write a driver for WLAN card from vendor noname and card reader > from "never heard of that company". If you buy the wrong graphics card > you may end up without 3D and whatever else cool features the card > supports. That's fine. Some hardware support is difficult. Some hardware support is not difficult. The only possible situation in which exporting some sort of OSI value for Linux is helpful is when the firmware authors know what the difference between the Linux and Windows behaviours are. If we know that, we can fix it. Fixing it not only fixes the machine in question, it probably fixes a large number of other machines. This is a preferable solution. > So at least since HP, Dell, Lenovo (also Acer?) are selling pre-loaded > Linux laptops, you should be smart enough to take such a thing where the > BIOS is adjusted to run on Linux or you pretty much have to reckon with > trouble. Argh. No. If the BIOS is adjusted to run on Linux, it indicates that we've failed. Completely. Utterly. > So being Windows compatible is nice, but sticking to specifications is > more important (we are far away from and never will be Windows > compatibility in WMI implementation right?). No! What's the point in sticking to specifications when there's only one implementation? Windows is the de-facto specification for ACPI, and we should follow it. > Next point is that if vendors pre-load their model with a specific > distribution, they need such a knob. Fixing Linux is easier than fixing firmware in almost every single case. If vendors are installing Linux without working with the distribution vendor, then that's unfortunate and they're likely to have problems. I'm not going to prioritise them above the huge number of users buying hardware from vendors who aren't as foolish. > Please do not think about what happens when I upgrade to the latest > kernel (which should still be no problem when they know how to use > this). Think about how these vendors should fix a complex Linux bug via > a BIOS hot-fix update ... They shouldn't. They should push out a software update. > > The > > only way we can achieve that is to be bug-compatible with Windows. > > Therefore, any way in which Linux behaviour varies from Windows > > behaviour is a bug. The only reason to export any indication that the > > kernel is Linux is because our behaviour is not identical to Windows. > Linux behaviour is not identical to Windows, never will be and after > vendors start pre-loading also do not need to be... Wrong. > > But, given that that's a bug, the solution should be to fix Linux and > > not to encourage vendors to put workarounds in their firmware. > I see it the other way round. Encourage vendors to fix their BIOSes, > instead of putting "Windows compatibility" workarounds into the kernel. By which you mean "Cater for a small market, rather than the large one"? No. That would be ridiculous. Our compatibility is sufficiently good that I'm not going to recommend users buy one of the tiny number of laptops available with a "supported" Linux install over buying a laptop that actually fits their needs. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
