This case timed out last Friday and has three +1. There are no more
comments so I will mark this case as approved.
Phi
>1) the actual event names (and any payload details)
>2) ideally, if there is some interface to ACPI itself that these modules
>should use, then those details.
>
>Anyway, I'm not too worried at the moment... both of those sets of
>details can just be Project Private for now. (Is that what how
Garrett D'Amore wrote:
> Kerry Shu wrote:
>>
>>
>> Casper.Dik at Sun.COM wrote:
So, while I do wish that an easier user configuration were available
for these ACPI events (the first of those translations), or that the
industry had standardized a bit more here, the reality is that
>So, while I do wish that an easier user configuration were available for
>these ACPI events (the first of those translations), or that the
>industry had standardized a bit more here, the reality is that this
>probably isn't practical, at least not at this point.
It would also be very nice if
Kerry Shu wrote:
>
>
> Casper.Dik at Sun.COM wrote:
>>> So, while I do wish that an easier user configuration were available
>>> for these ACPI events (the first of those translations), or that the
>>> industry had standardized a bit more here, the reality is that this
>>> probably isn't practic
Casper.Dik at Sun.COM wrote:
>> So, while I do wish that an easier user configuration were available for
>> these ACPI events (the first of those translations), or that the
>> industry had standardized a bit more here, the reality is that this
>> probably isn't practical, at least not at this
James Carlson wrote:
> Garrett D'Amore writes:
>> I agree. So, I'll give the current proposal a +1, and gently recommend
>> that the nexus approach either be used now, the next time we have to add
>> new vendor specific modules. Thoughts?
>
> That sounds good.
I'm also happy with this so I'm
>Totally agree, but I believe (but could be mistaken) that the issue is that
>different laptops will generate different ACPI events - so the mapping from
>ACPI
>event to X event isn't consistent, and I think that this is where we would need
>a text document to allow people to do this mapping in
>A similar mechanism was provided using hal/libhal on Linux, and there was quite
>a bit of traffic on the hal aliases at freedesktop.org to create patches for
>such keys from people who had unsupported laptops.
In many cases, the keys are just "keyboard keys" and they should be
handled through th
Casper.Dik at Sun.COM wrote:
>> A similar mechanism was provided using hal/libhal on Linux, and there was
>> quite
>> a bit of traffic on the hal aliases at freedesktop.org to create patches for
>> such keys from people who had unsupported laptops.
>
> In many cases, the keys are just "keyboard k
A similar mechanism was provided using hal/libhal on Linux, and there was quite
a bit of traffic on the hal aliases at freedesktop.org to create patches for
such keys from people who had unsupported laptops.
I'm not saying that hal is the right place to do it, I believe they have changed
this agai
Garrett D'Amore writes:
> I agree. So, I'll give the current proposal a +1, and gently recommend
> that the nexus approach either be used now, the next time we have to add
> new vendor specific modules. Thoughts?
That sounds good.
--
James Carlson, Solaris Networking
Sun Micros
Garrett D'Amore writes:
> In retrospect, perhaps having a separate directory under /kernel would
> be better, and then vendors could deploy their own acpi modules without
> having to touch the acpi_drv binary.
If that's where we go, then I'd rather see an /etc registry, as we do
with other forms
Kerry Shu writes:
> > But no TOS6200?
>
> We only got docs about "TOS6208" and "TOS1900" from Toshiba. And the
> Toshiba laptops we have support either of them. I'll ask IHV team for
> help to get info about "TOS1900". It should be straightforward to add it
> or more in if we have the related docs
Kerry Shu writes:
> My current implementation is to define a static array with known vendor
> specific modules name(currently only acpi_toshiba) in acpi_drv.
> Yes, it expects at most one of them to return 0 from _init().
OK; thanks. That's what I was looking for.
> Got it. If I do find conflict
Kerry Shu wrote:
>
>
> Nicolas Williams wrote:
>> On Mon, Jan 12, 2009 at 08:49:56AM -0800, Garrett D'Amore wrote:
>>> I had suggested a similar approach (using keyboard keys) -- actually
>>> my original suggestion went a step further, and suggested that this
>>> module could emulate a USB keyboa
Kerry Shu writes:
> James Carlson wrote:
> > Kerry Shu writes:
> >>
> >> Darren J Moffat wrote:
> >>> How does acpi_drv determine which vendor specific module to load ? What
> >> acpi_drv will try to load all known vendor specific modules. Once one
> >> module is loaded successfully, it's believe
James Carlson wrote:
> Garrett D'Amore writes:
>
>> In retrospect, perhaps having a separate directory under /kernel would
>> be better, and then vendors could deploy their own acpi modules without
>> having to touch the acpi_drv binary.
>>
>
> If that's where we go, then I'd rather see a
On Mon, Jan 12, 2009 at 10:46:57AM -0800, Kerry Shu wrote:
> Nicolas Williams wrote:
> >But if I understand correctly the basic kernel ACPI driver can catch
> >ACPI hotkeys -- it just doesn't know what to do with them.
>
> There is no basic kernel ACPI driver which can catch hotkey ACPI events
> f
On Mon, Jan 12, 2009 at 10:19:04AM -0800, Garrett D'Amore wrote:
> I think there's some confusion.
>
> There are three levels of mapping:
>
> 1) mapping some arbitrary ACPI event to a system event consumable by
> userland
> 2) mapping the system event to an X11 key event
> 3) mapping the X11 key
On Mon, Jan 12, 2009 at 10:10:06AM -0800, Kerry Shu wrote:
> >Would it be possible to let users create their own set of hotkeys? Even
> >if the hotkeys are burned into the HW, it'd be nice to be able to let
> >the user input each one and assign a symbol to each. This would be a
> >good workaround
John Plocher wrote:
> [jumping in late after reading the thread...]
>
>
>> Since there is no generic ACPI specification for other hotkeys, most
>> vendors just define their own specific ACPI based hotkey method. This
>> case will also add Toshiba specific ACPI hotkey method support for:
>> 1. Fn
John Plocher wrote:
> [jumping in late after reading the thread...]
>
>> Since there is no generic ACPI specification for other hotkeys, most
>> vendors just define their own specific ACPI based hotkey method. This
>> case will also add Toshiba specific ACPI hotkey method support for:
>> 1. Fn +
On Mon, Jan 12, 2009 at 10:04:14AM -0800, Kerry Shu wrote:
> James Carlson wrote:
> >How exactly does the system know which module works on a given system?
>
> If the corresponding ACPI method is found in _init of the vendor
> specific module, then _init will return SUCCESS and we know the
> modul
In retrospect, perhaps having a separate directory under /kernel would
be better, and then vendors could deploy their own acpi modules without
having to touch the acpi_drv binary.
E.g.:
/kernel/acpi/acpi_toshiba
/kernel/acpi/amd64/acpi_toshiba
(Perhaps even /platform would be better...
/platf
[jumping in late after reading the thread...]
> Since there is no generic ACPI specification for other hotkeys, most
> vendors just define their own specific ACPI based hotkey method. This
> case will also add Toshiba specific ACPI hotkey method support for:
> 1. Fn + ESC: audio mute On/Off
> 2. F
James Carlson wrote:
> Kerry Shu writes:
>> My current implementation is to define a static array with known vendor
>> specific modules name(currently only acpi_toshiba) in acpi_drv.
>> Yes, it expects at most one of them to return 0 from _init().
>
> OK; thanks. That's what I was looking for.
On Mon, Jan 12, 2009 at 08:49:56AM -0800, Garrett D'Amore wrote:
> I had suggested a similar approach (using keyboard keys) -- actually my
> original suggestion went a step further, and suggested that this module
> could emulate a USB keyboard and generate USB boot-protocol HID keyboard
> events
James Carlson wrote:
> Kerry Shu writes:
>> James Carlson wrote:
>>> Kerry Shu writes:
Darren J Moffat wrote:
> How does acpi_drv determine which vendor specific module to load ? What
acpi_drv will try to load all known vendor specific modules. Once one
module is loaded succe
On Mon, Jan 12, 2009 at 05:43:07PM +0100, Casper.Dik at Sun.COM wrote:
> In many cases, the keys are just "keyboard keys" and they should be
> handled through the keyboard driver.
>
> In other cases, they are all "ACPI" events.
>
> I would like those to be presented as keyboard keys; and then you
Nicolas Williams wrote:
> On Mon, Jan 12, 2009 at 10:19:04AM -0800, Garrett D'Amore wrote:
>> I think there's some confusion.
>>
>> There are three levels of mapping:
>>
>> 1) mapping some arbitrary ACPI event to a system event consumable by
>> userland
>> 2) mapping the system event to an X11 k
Nicolas Williams wrote:
> On Mon, Jan 12, 2009 at 10:10:06AM -0800, Kerry Shu wrote:
>>> Would it be possible to let users create their own set of hotkeys? Even
>>> if the hotkeys are burned into the HW, it'd be nice to be able to let
>>> the user input each one and assign a symbol to each. Thi
Nicolas Williams wrote:
> On Mon, Jan 12, 2009 at 10:04:14AM -0800, Kerry Shu wrote:
>> James Carlson wrote:
>>> How exactly does the system know which module works on a given system?
>> If the corresponding ACPI method is found in _init of the vendor
>> specific module, then _init will return SU
Nicolas Williams wrote:
> On Mon, Jan 12, 2009 at 08:49:56AM -0800, Garrett D'Amore wrote:
>> I had suggested a similar approach (using keyboard keys) -- actually my
>> original suggestion went a step further, and suggested that this module
>> could emulate a USB keyboard and generate USB boot-
On Sun, Jan 11, 2009 at 08:01:10PM -0800, Phi Tran wrote:
> Since there is no generic ACPI specification for other hotkeys, most
> vendors just define their own specific ACPI based hotkey method. This
> case will also add Toshiba specific ACPI hotkey method support for:
> 1. Fn + ESC: audio mute On
Nicolas Williams wrote:
> On Mon, Jan 12, 2009 at 10:04:14AM -0800, Kerry Shu wrote:
>
>> James Carlson wrote:
>>
>>> How exactly does the system know which module works on a given system?
>>>
>> If the corresponding ACPI method is found in _init of the vendor
>> specific module, the
Garrett D'Amore wrote:
> Casper.Dik at Sun.COM wrote:
>>> A similar mechanism was provided using hal/libhal on Linux, and there
>>> was quite
>>> a bit of traffic on the hal aliases at freedesktop.org to create
>>> patches for
>>> such keys from people who had unsupported laptops.
>>>
>>
>
Darren Kenny wrote:
> A similar mechanism was provided using hal/libhal on Linux, and there was
> quite
> a bit of traffic on the hal aliases at freedesktop.org to create patches for
> such keys from people who had unsupported laptops.
Current Gnome shortcuts application is based on standand ke
Nicolas Williams wrote:
> On Sun, Jan 11, 2009 at 08:01:10PM -0800, Phi Tran wrote:
>> Since there is no generic ACPI specification for other hotkeys, most
>> vendors just define their own specific ACPI based hotkey method. This
>> case will also add Toshiba specific ACPI hotkey method support fo
James Carlson wrote:
> Kerry Shu writes:
>>
>> Darren J Moffat wrote:
>>> How does acpi_drv determine which vendor specific module to load ? What
>> acpi_drv will try to load all known vendor specific modules. Once one
>> module is loaded successfully, it's believed a vendor specific module
>>
Casper.Dik at Sun.COM wrote:
>> A similar mechanism was provided using hal/libhal on Linux, and there was
>> quite
>> a bit of traffic on the hal aliases at freedesktop.org to create patches for
>> such keys from people who had unsupported laptops.
>>
>
> In many cases, the keys are just "key
Kerry Shu writes:
>
>
> Darren J Moffat wrote:
> > How does acpi_drv determine which vendor specific module to load ? What
>
> acpi_drv will try to load all known vendor specific modules. Once one
> module is loaded successfully, it's believed a vendor specific module
> is found and function.
How does acpi_drv determine which vendor specific module to load ? What
is the guidance for naming vendor modules ? While it might hold true
for Toshiba models that one module serves all current BIOS/ACPI what
about other vendors where multiple different systems have completely
different requ
Darren J Moffat wrote:
> How does acpi_drv determine which vendor specific module to load ? What
acpi_drv will try to load all known vendor specific modules. Once one
module is loaded successfully, it's believed a vendor specific module
is found and function.
> is the guidance for naming vend
I am sponsoring this case for Kerry Shu with a requested release binding
of minor.
Phi
Template Version: @(#)sac_nextcase %I% %G% SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
Laptop Hotkey Support
1.2. Name of Docume
45 matches
Mail list logo
