Re: wistron_btns-add-support-for-x86_64-systems.patch in -mm
On Saturday 05 January 2008 17:52:06 Rémi Hérilier wrote: > What about finding what does this BIOS function and writing > an equivalent in C? There would be no BIOS call anymore and > this module could be used in the x86-64 port. > > But, is it a sane solution? The problem is that the BIOS call would be unique to each supported machine as in which memory addresses, EC registers etc get touched and with what values. You would end up needing to reimplement this on a case-by-case basis. This was an idea that was considered by acerhk, but they considered it far too much work and completely impractical. For at least all modern Acer laptops, this direct BIOS calling is completely deprecated, in favour of ACPI-WMI (which in turn, on those systems, usually either triggers SMI traps or touches EC registers, and is 32/ 64 bit agnostic), so the question for those laptops is becoming more and more irrelevant (and modern Acer laptops of the last four years, at least, don't have problems with missing keycodes that require us to poll). For Fujitsu-Siemens laptops, I did come across someone who was looking into poking at ACPI to generate keypresses for the keys that don't generate standard keycodes[1], as a 32/ 64 bit agnostic solution (since most Fujitsu Siemens laptops don't support the required BIOS call from long mode, and also still don't produce standard keycodes on certain button presses). -Carlos [1] http://code.google.com/p/fscamiloa16xx/ -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: wistron_btns-add-support-for-x86_64-systems.patch in -mm
Andi Kleen wrote: > While looking for something else I stumbled over > > wistron_btns-add-support-for-x86_64-systems.patch > > in -mm. The patch looks very dubious to me. It basically > calls a BIOS function in long mode. To work like implemented > the BIOS would need to know magically what it was called > from (32bit or 64bit) and then execute different code paths. > > It's very unlikely that this works. Most likely > it will crash and if it happens to currently work > it will be extremly fragile and crash at some future > point. > > If anything you would need to set up a compat mode segment > and call the BIOS from that, but there are other problems > like interrupts not working etc (compat mode is somewhat > limited). Early in the x86-64 port there was a decision > to not call any BIOS calls from long mode because of these > problems. > > The only sane way to call that code would be to do so > from user space using some kind of emulator (e.g. like > the x server does) > > So I think the patch should be dropped. > > -Andi > > Thanks you for your reply and these informations. What about finding what does this BIOS function and writing an equivalent in C? There would be no BIOS call anymore and this module could be used in the x86-64 port. But, is it a sane solution? Remi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: wistron_btns-add-support-for-x86_64-systems.patch in -mm
Andi Kleen wrote: While looking for something else I stumbled over wistron_btns-add-support-for-x86_64-systems.patch in -mm. The patch looks very dubious to me. It basically calls a BIOS function in long mode. To work like implemented the BIOS would need to know magically what it was called from (32bit or 64bit) and then execute different code paths. It's very unlikely that this works. Most likely it will crash and if it happens to currently work it will be extremly fragile and crash at some future point. If anything you would need to set up a compat mode segment and call the BIOS from that, but there are other problems like interrupts not working etc (compat mode is somewhat limited). Early in the x86-64 port there was a decision to not call any BIOS calls from long mode because of these problems. The only sane way to call that code would be to do so from user space using some kind of emulator (e.g. like the x server does) So I think the patch should be dropped. -Andi Thanks you for your reply and these informations. What about finding what does this BIOS function and writing an equivalent in C? There would be no BIOS call anymore and this module could be used in the x86-64 port. But, is it a sane solution? Remi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: wistron_btns-add-support-for-x86_64-systems.patch in -mm
On Saturday 05 January 2008 17:52:06 Rémi Hérilier wrote: What about finding what does this BIOS function and writing an equivalent in C? There would be no BIOS call anymore and this module could be used in the x86-64 port. But, is it a sane solution? The problem is that the BIOS call would be unique to each supported machine as in which memory addresses, EC registers etc get touched and with what values. You would end up needing to reimplement this on a case-by-case basis. This was an idea that was considered by acerhk, but they considered it far too much work and completely impractical. For at least all modern Acer laptops, this direct BIOS calling is completely deprecated, in favour of ACPI-WMI (which in turn, on those systems, usually either triggers SMI traps or touches EC registers, and is 32/ 64 bit agnostic), so the question for those laptops is becoming more and more irrelevant (and modern Acer laptops of the last four years, at least, don't have problems with missing keycodes that require us to poll). For Fujitsu-Siemens laptops, I did come across someone who was looking into poking at ACPI to generate keypresses for the keys that don't generate standard keycodes[1], as a 32/ 64 bit agnostic solution (since most Fujitsu Siemens laptops don't support the required BIOS call from long mode, and also still don't produce standard keycodes on certain button presses). -Carlos [1] http://code.google.com/p/fscamiloa16xx/ -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
wistron_btns-add-support-for-x86_64-systems.patch in -mm
While looking for something else I stumbled over wistron_btns-add-support-for-x86_64-systems.patch in -mm. The patch looks very dubious to me. It basically calls a BIOS function in long mode. To work like implemented the BIOS would need to know magically what it was called from (32bit or 64bit) and then execute different code paths. It's very unlikely that this works. Most likely it will crash and if it happens to currently work it will be extremly fragile and crash at some future point. If anything you would need to set up a compat mode segment and call the BIOS from that, but there are other problems like interrupts not working etc (compat mode is somewhat limited). Early in the x86-64 port there was a decision to not call any BIOS calls from long mode because of these problems. The only sane way to call that code would be to do so from user space using some kind of emulator (e.g. like the x server does) So I think the patch should be dropped. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
wistron_btns-add-support-for-x86_64-systems.patch in -mm
While looking for something else I stumbled over wistron_btns-add-support-for-x86_64-systems.patch in -mm. The patch looks very dubious to me. It basically calls a BIOS function in long mode. To work like implemented the BIOS would need to know magically what it was called from (32bit or 64bit) and then execute different code paths. It's very unlikely that this works. Most likely it will crash and if it happens to currently work it will be extremly fragile and crash at some future point. If anything you would need to set up a compat mode segment and call the BIOS from that, but there are other problems like interrupts not working etc (compat mode is somewhat limited). Early in the x86-64 port there was a decision to not call any BIOS calls from long mode because of these problems. The only sane way to call that code would be to do so from user space using some kind of emulator (e.g. like the x server does) So I think the patch should be dropped. -Andi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
