Re: wistron_btns-add-support-for-x86_64-systems.patch in -mm

Re: wistron_btns-add-support-for-x86_64-systems.patch in -mm

[Rémi Hérilier]

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

Re: wistron_btns-add-support-for-x86_64-systems.patch in -mm

[Carlos Corbacho]

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: carlos@strangeworlds.co.uk
Web: strangeworlds.co.uk
GPG Key ID: 0x23EE722D
-
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html