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
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
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