On Mon, Jan 14, 2008 at 10:25:10PM +, Carlos Corbacho wrote:
On Monday 14 January 2008 18:27:33 Carlos Corbacho wrote:
On Monday 14 January 2008 17:41:07 Matthew Garrett wrote:
On Thu, Jan 03, 2008 at 11:58:02AM -0500, Dmitry Torokhov wrote:
There is no sysfs device to attach
Hi Matthew,
On Dec 26, 2007 5:48 PM, Matthew Garrett [EMAIL PROTECTED] wrote:
+ } else
+ printk (KERN_INFO HP WMI: Unknown response received\n);
+
+ return;
No need for empty returns.
+}
+
+static int __init hp_wmi_init(void)
+{
+ int err;
+ const
On 11/14/07, Zhang Rui [EMAIL PROTECTED] wrote:
On Tue, 2007-11-06 at 00:43 +0800, Dmitry Torokhov wrote:
Hi Len, Rui,
Here is a group of cleanups and patches to the acpi video driver.
Originally I just wanted to fix sysfs placement of input devices
created by the driver, but then I saw
On 11/14/07, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote:
On Wed, 14 Nov 2007, Zhang Rui wrote:
On Tue, 2007-11-06 at 00:43 +0800, Dmitry Torokhov wrote:
ACPI: video - properly handle errors when registering proc elements
Have acpi_video_device_add_fs
On 11/11/07, Andrey Borzenkov [EMAIL PROTECTED] wrote:
On Tuesday 06 November 2007, Dmitry Torokhov wrote:
Hi Andrey,
On Nov 6, 2007 12:51 PM, Andrey Borzenkov [EMAIL PROTECTED] wrote:
Properly set up parent on input device registered by the button driver.
Seems to be a popular
Hi David,
On Nov 6, 2007 3:07 PM, David Brownell [EMAIL PROTECTED] wrote:
--- g26.orig/drivers/acpi/button.c 2007-11-04 11:47:40.0 -0800
+++ g26/drivers/acpi/button.c 2007-11-04 11:48:50.0 -0800
@@ -395,6 +395,7 @@ static int acpi_button_add(struct acpi_d
Hi Andrey,
On Nov 6, 2007 12:51 PM, Andrey Borzenkov [EMAIL PROTECTED] wrote:
Properly set up parent on input device registered by the button driver.
Seems to be a popular topic today :)
+ input-cdev.dev = device-dev;
Please don't use cdev, but rather input_dev-dev.parent. cdev is
Hi Len, Rui,
Here is a group of cleanups and patches to the acpi video driver.
Originally I just wanted to fix sysfs placement of input devices
created by the driver, but then I saw some more potential issues.
The patches are against Linus's tree, please let me know if you
want them redone
ACPI: video - fit input device into sysfs tree
Properly set up parent on input device registered by the video driver.
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
---
drivers/acpi/video.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: work/drivers/acpi/video.c
ACPI: video - convert semaphore to a mutex
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
---
drivers/acpi/video.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
Index: work/drivers/acpi/video.c
ACPI: video - add missing input_free_device()
If input_register_device() fails input_free_device() must
be called to release memory allocated for the device.
Also consolidate error handling in acpi_bus_video_add()
and handle input_allocate_device() failures.
Signed-off-by: Dmitry Torokhov [EMAIL
ACPI: video - simplify handling of attached devices
The old code needlessly stored invalid entries in attached_array list.
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
---
drivers/acpi/video.c | 58 +++
1 file changed, 27 insertions(+), 31
ACPI: video - remove unsafe uses of list_for_each_safe()
list_for_each_safe() only protects list from list alterations
performed by the same thread. One still needs to implement
proper locking when list is being accessed from several threads.
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED
ACPI: video - more cleanups
Remove unneeded checks and initializations, implement proper
unwinding after errors in initialization code, get rid of
unneeded casts, adjust formatting.
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
---
drivers/acpi/video.c | 778
ACPI: video - properly handle errors when registering proc elements
Have acpi_video_device_add_fs() and acpi_video_bus_add_fs()
properly unwind proc creation after error.
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
---
drivers/acpi/video.c | 230
Subject: Sonypi: fit input devices into sysfs tree
From: Dmitry Torokhov [EMAIL PROTECTED]
Properly set up parent on input devices registered by sonypi.
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
---
drivers/char/sonypi.c |6 --
1 file changed, 4 insertions(+), 2 deletions
Hi Mattia,
Here is a small patch for sony-laptop. Untested since I don't
have the hardware.
--
Dmitry
Subject: sony-laptop: fit input devices into sysfs tree
From: Dmitry Torokhov [EMAIL PROTECTED]
Properly set up parent on input devices registered by sony-laptop.
Signed-off-by: Dmitry
Hi Mattia,
It looks like you are also looking after sonypi...
--
Dmitry
Subject: Sonypi: use synchronize_irq instead of sycnronize_sched
From: Dmitry Torokhov [EMAIL PROTECTED]
We know exactly what IRQ we are using, so synchronize_irq()
suits much better. Plus synchronize_sched
On Sunday 07 October 2007, Andrey Borzenkov wrote:
This fixes oops when registering backlight device fails. Attached as I still
cannot convince kmail to not mangle long lines ...
-andrey
Re: kmail - it usually behaves well with the patches as long as
you turn off word wrapping and use
On 8/23/07, Len Brown [EMAIL PROTECTED] wrote:
Thanks for the refreshed patch series, Rui.
I've added it to acpi-test.
Still waiting on an ACK from Dmitry on the input.h definitions.
Sorry, I am still trying to recover from a hard drive failure...
The keycodes conflict with a pending patch
On 7/18/07, Matthew Garrett [EMAIL PROTECTED] wrote:
On Wed, Jul 18, 2007 at 08:45:19PM +0900, Mattia Dongili wrote:
On Tue, Jul 17, 2007 at 11:37:33AM +0100, Richard Hughes wrote:
On Mon, 2007-07-16 at 19:09 +0100, Matthew Garrett wrote:
That's fine, we have information that lets us
On 7/18/07, Richard Hughes [EMAIL PROTECTED] wrote:
On Wed, 2007-07-18 at 11:05 -0400, Dmitry Torokhov wrote:
I think we should continue adding keymaps to kernel until everyone is
using HAL's facilities to load keymaps and then stop. Does this make
sense?
I don't think so. The whole idea
On 7/18/07, Matthew Garrett [EMAIL PROTECTED] wrote:
On Wed, Jul 18, 2007 at 04:17:02PM +0100, Richard Hughes wrote:
On Wed, 2007-07-18 at 11:05 -0400, Dmitry Torokhov wrote:
I think we should continue adding keymaps to kernel until everyone is
using HAL's facilities to load keymaps
of the ACPI object corresponding to the docking station
and elevate severity of the message printed when _DCK fails to KERN_ERR.
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
---
drivers/acpi/dock.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
Index: linux/drivers/acpi/dock.c
Hi Mattia,
On 7/15/07, Mattia Dongili [EMAIL PROTECTED] wrote:
+static int sony_laptop_input_keycode_map[] = {
+ KEY_RESERVED,/* no event... */
+ KEY_RESERVED, /* SONYPI_EVENT_JOGDIAL_DOWN */
+ KEY_RESERVED, /* SONYPI_EVENT_JOGDIAL_UP */
+ KEY_RESERVED, /*
On 7/15/07, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote:
On Mon, 16 Jul 2007, Matthew Garrett wrote:
Having checked other drivers, it looks like KEY_SWITCHVIDEOMODE is the
one used for video toggling. If that's not actually how people are using
it, we need to fix that - if it is, I'd
On 7/15/07, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote:
On Sun, 15 Jul 2007, Matthew Garrett wrote:
On Sun, Jul 15, 2007 at 05:59:34PM -0300, Henrique de Moraes Holschuh wrote:
*HAL* does. HAL is *not* all there is to userspace. The input layer is not
an interface between the
On Thursday 05 July 2007 22:42, Henrique de Moraes Holschuh wrote:
Many laptops have rf-kill physical switches that are not keys, but slider
or rocker switches. Often (like in all ThinkPads with a radio kill slider
switch), they have both a slider/rocker switch and a hot key.
Linus just
On Saturday 16 June 2007 10:44, Henrique de Moraes Holschuh wrote:
thinkpad-acpi can now be made to export EV_SW SW_LID events to the input
layer.
However, most (all?) thinkpads will also generate ACPI notifications to
\_SB.LID, on LID changes, i.e. this would duplicate an ACPI LID event,
On Saturday 16 June 2007 13:11, Richard Hughes wrote:
On Fri, 2007-06-15 at 15:53 +0100, Richard Hughes wrote:
On Fri, 2007-06-15 at 10:29 -0400, Dmitry Torokhov wrote:
On 6/15/07, Richard Hughes [EMAIL PROTECTED] wrote:
On Fri, 2007-06-15 at 13:29 +0100, Richard Hughes wrote
Hi Daniel,
On Saturday 16 June 2007 20:03, Daniel Drake wrote:
Many Dell laptops have the DSDT coded to power down the display when the lid
is closed, and leave it off when it is opened.
http://bugzilla.kernel.org/show_bug.cgi?id=5155
Based on ideas from Len Brown and Dmitry Torokhov
On 6/15/07, Richard Hughes [EMAIL PROTECTED] wrote:
On Fri, 2007-06-15 at 13:29 +0100, Richard Hughes wrote:
in response to an event, but I'm thinking in a resume hook we should
probably do acpi_evaluate_integer(handle, _LID, NULL, state) and then
send an event, just so userspace is aware of
Hi Daniel,
On Thursday 31 May 2007 23:06, Daniel Drake wrote:
This patch creates a new event system for communication between in-kernel
ACPI drivers (ievent). It is simple - it should only be used to infrequently
pass simple messages to a small audience.
This is used in an upcoming patch
On 6/7/07, Richard Hughes [EMAIL PROTECTED] wrote:
On Sun, 2007-06-03 at 00:48 -0400, Dmitry Torokhov wrote:
It looks like KEY_COFFE comes from 0x0c/0x19e - AL Terminal
Lock/Screensaver
so your interpretation is indeed correct. I guess I better add an
alias to
input.h
What's the status
On Saturday 02 June 2007 10:23, Matthew Garrett wrote:
On Sat, Jun 02, 2007 at 01:50:52PM +0100, Richard Hughes wrote:
KEY_SCREENLOCK? KEY_SCREENSAVER?
Either of these keys would be good to add.
We've been interpreting KEY_COFFEE as screenlock (as in I've gone for
a coffee break,
On 6/1/07, Matthew Garrett [EMAIL PROTECTED] wrote:
On Fri, Jun 01, 2007 at 12:37:58AM -0400, Dmitry Torokhov wrote:
On Friday 01 June 2007 00:08, Matthew Garrett wrote:
If you let users alter the kernel keymap, then you need to implement
support for resetting the kernel keymap on exit
On 6/1/07, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote:
On Fri, 01 Jun 2007, Dmitry Torokhov wrote:
On 6/1/07, Matthew Garrett [EMAIL PROTECTED] wrote:
What I am trying to say - there already EVIOCSKEYCODE ioctl in the
kernel. And for force feedback devices to work you need to nable
in reply in different thread...
On Thu, 2007-05-31 at 10:37 -0400, Dmitry Torokhov wrote:
Please use input-polldev to set up polled devices. It
will create work queue for you and will make sure that polling is
stopped when device is closed.
Okay, I had never heard of this. I've done the suggested
On 5/31/07, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote:
On Thu, 31 May 2007, Richard Hughes wrote:
I am on it on the thinkpad-acpi side, so at least for that, you don't have
to worry. I am still waiting an answer about which event is the correct one
to output scancodes, but the
On Wednesday 30 May 2007 20:53, Henrique de Moraes Holschuh wrote:
On Wed, 30 May 2007, Dmitry Torokhov wrote:
On 5/30/07, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote:
It is trivial to guarantee that KEY_PROG is unique for a single input
device (keyboard), but it certainly won't
On Thursday 31 May 2007 21:44, Matthew Garrett wrote:
On Thu, May 31, 2007 at 10:29:28PM -0300, Henrique de Moraes Holschuh wrote:
On Fri, 01 Jun 2007, Matthew Garrett wrote:
Given existing userspace, it's never useful to generate KEY_UNKNOWN.
Adding extra information to the event
On Friday 01 June 2007 00:08, Matthew Garrett wrote:
On Thu, May 31, 2007 at 11:33:10PM -0400, Dmitry Torokhov wrote:
On Thursday 31 May 2007 21:44, Matthew Garrett wrote:
It's not trivial at all. You need to introduce a mechanism for noting a
KEY_UNKNOWN keypress. It then needs
Hi Matthew,
On 5/30/07, Matthew Garrett [EMAIL PROTECTED] wrote:
On Wed, May 30, 2007 at 09:57:11AM -0400, Dmitry Torokhov wrote:
I really don't like KEY_FN_F1..KEY_FN_BACKSPACE either. What are they
supposed to do? Just being an unique value to be mapped onto something
useful? But why
On 5/30/07, Matthew Garrett [EMAIL PROTECTED] wrote:
On Wed, May 30, 2007 at 10:18:17AM -0400, Dmitry Torokhov wrote:
Hi Matthew,
We've already got KEY_PROG* - is this not the sort of situation they're
for? (ie, keys that aren't mapped to a specific purpose but would be
potentially useful
On 5/30/07, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote:
On Wed, 30 May 2007, Dmitry Torokhov wrote:
On 5/29/07, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote:
But I will still need to add keys, and I still think that a bunch of 32 or
so HOSTSPECIFIC keys is a very very good
On 5/30/07, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote:
On Wed, 30 May 2007, Dmitry Torokhov wrote:
1. Generate SOMETHING that has an undefined meaning or function, but which
is unique for that keyboard (KEY_PROG/KEY_HOSTSPECIFIC)
How do you guarantee that KEY_PROG* is unique
On 5/29/07, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote:
On Mon, 28 May 2007, Dmitry Torokhov wrote:
Documentation/input/input-programming.txt gives some pointers.
It is outdated,
Hm, I just recently updated it so it is pretty fresh.
and incomplete.
Here I agree.
--
Dmitry
Hi,
On Sunday 27 May 2007 08:03, Henrique de Moraes Holschuh wrote:
On Sat, 26 May 2007, Dmitry Torokhov wrote:
On Saturday 26 May 2007 13:31, Henrique de Moraes Holschuh wrote:
Add a sysfs interface to allow userspace to modify the mapping between
ThinkPad hotkeys and the keycode input
On Sunday 27 May 2007 08:15, Henrique de Moraes Holschuh wrote:
On Sat, 26 May 2007, Dmitry Torokhov wrote:
On Saturday 26 May 2007 13:31, Henrique de Moraes Holschuh wrote:
Add hotkeys available in almost all ThinkPads manufactured in the last
five
years (more than one million
Hi,
On Saturday 26 May 2007 13:31, Henrique de Moraes Holschuh wrote:
Register an input device to send input events to userspace.
This patch is based on a patch by Richard Hughes [EMAIL PROTECTED].
Signed-off-by: Henrique de Moraes Holschuh [EMAIL PROTECTED]
Cc: Richard Hughes [EMAIL
On Saturday 26 May 2007 13:31, Henrique de Moraes Holschuh wrote:
Add a sysfs interface to allow userspace to modify the mapping between
ThinkPad hotkeys and the keycode input events they generate.
No, please do not do that. We have a standard way to adjust keymap for
an input device via
On Saturday 26 May 2007 13:31, Henrique de Moraes Holschuh wrote:
Add hotkeys available in almost all ThinkPads manufactured in the last five
years (more than one million machines given the ammount of batteries
recalled) to input.h, and make thinkpad-acpi use those instead of issuing
On Saturday 19 May 2007 11:42, Matthew Garrett wrote:
On Sat, May 19, 2007 at 06:28:08PM +0300, Mircea Bardac wrote:
I've noticed a weird behaviour when monitoring roughly the number of
interrupts fired. The number of interrupts for i8042 increase
dramatically
when I move the pointer
Hi Thomas,
On 4/19/07, Thomas Renninger [EMAIL PROTECTED] wrote:
Hi,
I first thought it's the unload psmouse or cleanup psmouse ports
at shutdown problem again.
I think this time EC gets confused at boot time.
Compiling psmouse as module helps again.
Symptom:
AC adapter status is wrong if
On 4/16/07, Bjorn Helgaas [EMAIL PROTECTED] wrote:
On Monday 16 April 2007 13:59, marco wrote:
... It is still a problem which renders the
pen unusable after a suspend.
I am happy to run any tests you need.
Attatched are a dmesg right after a reboot when the pen is working
dmesg.wpen and
On 4/16/07, Dmitry Torokhov [EMAIL PROTECTED] wrote:
On 4/16/07, Bjorn Helgaas [EMAIL PROTECTED] wrote:
It seems a bit
strange that the device is associated differently after resume, but
I don't know enough about input drivers to know whether that's by
design or not.
It should not change
On 4/13/07, Bjorn Helgaas [EMAIL PROTECTED] wrote:
On Tuesday 20 February 2007 06:52, marco wrote:
I have a thinkpad X41-tablet which uses the linuxwacom serial drivers.
The tablet works perfectly when the laptop first boots, but does not work
at all after resuming from sleep. I posted to
On 4/13/07, Bjorn Helgaas [EMAIL PROTECTED] wrote:
On Friday 13 April 2007 13:16, Dmitry Torokhov wrote:
On 4/13/07, Bjorn Helgaas [EMAIL PROTECTED] wrote:
On Tuesday 20 February 2007 06:52, marco wrote:
I have a thinkpad X41-tablet which uses the linuxwacom serial drivers.
The tablet
On 3/7/07, Ash Milsted [EMAIL PROTECTED] wrote:
On Sun, 4 Mar 2007 14:23:50 +
Ash Milsted [EMAIL PROTECTED] wrote:
On Sat, 3 Mar 2007 15:14:24 +
Ash Milsted [EMAIL PROTECTED] wrote:
Hi,
With 2.6.21-rc2-git1 I have a problem with my ps/2 port keyboard - it only
works
with one
On 3/7/07, Ash Milsted [EMAIL PROTECTED] wrote:
On Wed, 7 Mar 2007 12:00:04 +
Ash Milsted [EMAIL PROTECTED] wrote:
On Sun, 4 Mar 2007 14:23:50 +
Ash Milsted [EMAIL PROTECTED] wrote:
On Sat, 3 Mar 2007 15:14:24 +
Ash Milsted [EMAIL PROTECTED] wrote:
Hi,
With
On Wednesday 07 March 2007 16:50, Dmitry Torokhov wrote:
On 3/7/07, Ash Milsted [EMAIL PROTECTED] wrote:
So, I tracked this down to 2.6.21-git7, the first snapshot that gives me
this problem. Tellingly it does contain an input tree merge. I would git
bisect
but I don't have a local
On 3/4/07, emisca [EMAIL PROTECTED] wrote:
At what kernel are targeted these patches? I have an nx7400, and the
same psmouse problems I would like to test them..
Please try 2.6.21-rc2 - the patches are included there.
--
Dmitry
-
To unsubscribe from this list: send the line unsubscribe
Hi Thomas,
On 2/26/07, Thomas Renninger [EMAIL PROTECTED] wrote:
On Thu, 2007-02-22 at 10:02 -0500, Dmitry Torokhov wrote:
Hope this makes sense (I must admit it makes little sense to me ;) ).
Same for me at the beginning.
I tracked two of the HP problems (wrong temperature, wrong _PPC value
On 2/22/07, Thomas Renninger [EMAIL PROTECTED] wrote:
When adding the .shutdown workaround I went down and realized it must be
this:
psmouse_set_state(psmouse, PSMOUSE_CMD_MODE);
or this:
psmouse_set_state(psmouse, PSMOUSE_IGNORE);
as I added the stuff in serio.c, I didn't
On 2/21/07, Thomas Renninger [EMAIL PROTECTED] wrote:
Hi,
I like to ask for inclusion into stable series for these.
The original patch from Dmitry can be found here:
http://bugzilla.kernel.org/show_bug.cgi?id=7689
comment #64, #65.
The reason is:
- These patches fix a lot weird stuff on all
Hi Pavel,
On 2/21/07, Pavel Machek [EMAIL PROTECTED] wrote:
Yes, it is quite nasty problem, but:
1) Fix is non-trivial (100 lines, which violates -stable rule IIRC)
The fix itself is only 30 lines (counting empty lines and comments)
which is not too bad.
2) Fix is very disconnected from
On Monday 05 February 2007 14:49, Dmitry Torokhov wrote:
Hi,
On 2/5/07, Thomas Renninger [EMAIL PROTECTED] wrote:
I have a patch that should fix the psmouse unload thing (at the end).
Not sure whether it's still needed in 2.6.20-rcX, there was some work
done... it definitely helps
interface input device corresponding to LID
switch reports true lid state instead of just a counter. SW_LID is
active when lid is closed.
The driver now depends on CONFIG_INPUT.
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
---
drivers/acpi/Kconfig |1
drivers/acpi/button.c | 223
On 10/11/06, Yu Luming [EMAIL PROTECTED] wrote:
It would have to be DMI-based to some extent - not all Sonys use the
same keys for the same purpose. Misery ensues.
Then we need to add keymap table to the sonypi's input device so that
keymap can be changed from userspace.
If some key is
On 9/18/06, Richard Hughes [EMAIL PROTECTED] wrote:
On Wed, 2006-08-30 at 23:07 -0400, Dmitry Torokhov wrote:
On Wednesday 30 August 2006 23:03, Len Brown wrote:
On Wednesday 30 August 2006 22:53, Dmitry Torokhov wrote:
So... do you want me to make it work with !CONFIG_INPUT or shoudl I
On 8/18/06, Len Brown [EMAIL PROTECTED] wrote:
On Thursday 17 August 2006 03:48, Jaya Kumar wrote:
On 8/16/06, Len Brown [EMAIL PROTECTED] wrote:
Andrew,
Please delete this patch from MM -- it is stale.
Jaya, please send Andrew the newer patch that replaces it -- the one
that doesn't
On 7/28/06, Shem Multinymous [EMAIL PROTECTED] wrote:
On 7/28/06, Dmitry Torokhov [EMAIL PROTECTED] wrote:
4) sysfs - all capabilities, IDs, etc for input devices exported there as
well.
Forgive my ignorance, but how do I conncet a sysfs directory with a /dev device?
So far the only way I
duplicate
sleep requests anyway (and discard unprocessed events right after
wakeup).
Unlike /proc/acpi/event interface input device corresponding to LID
switch reports true lid state instead of just a counter. SW_LID is
active when lid is closed.
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED
Hi Jaya,
On 7/25/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
+static acpi_status acpi_atlas_button_handler(u32 function,
+ acpi_physical_address address,
+ u32 bit_width, acpi_integer *value,
+ void *handler_context, void
On 7/13/06, Brown, Len [EMAIL PROTECTED] wrote:
Jaya,
Thanks for updating this patch.
Note that this driver can not be accepted into the kernel without
an entry being added to the MAINTAINERS file showing who is
going to look after it.
Preferably, that person should be inside Atlas, or have
On 7/2/06, Jaya Kumar [EMAIL PROTECTED] wrote:
Hi Len,
On 7/1/06, Brown, Len [EMAIL PROTECTED] wrote:
+ if (function == ACPI_WRITE) {
+ status = acpi_bus_generate_event(dev, 0x80, address);
+ atlas_input_report((u8) address);
What is the reasoning to
On 7/6/06, Fryderyk Dziarmagowski [EMAIL PROTECTED] wrote:
--- Dmitry Torokhov [EMAIL PROTECTED] wrote:
From: Dmitry Torokhov [EMAIL PROTECTED]
ACPI: disable SBS by default
Kconfig help even says that SBS is pretty rare and already
obsolete so it does not make sence to keep it enabled
From: Dmitry Torokhov [EMAIL PROTECTED]
ACPI: disable SBS by default
Kconfig help even says that SBS is pretty rare and already
obsolete so it does not make sence to keep it enabled.
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
---
drivers/acpi/Kconfig |2 +-
1 files changed, 1
On 6/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
+
+static int atlas_acpi_button_remove(struct acpi_device *device, int type)
+{
+ acpi_status status;
+
+ atlas_free_input();
+ status = acpi_remove_address_space_handler(device-handle,
+ 0x81,
On 4/20/06, Pavel Machek [EMAIL PROTECTED] wrote:
Having EV_ACPI might make sense for thermal/battery events, but not
for normal keys.
No, I do not want EV_ACPI at all. If it does not map to standard
key/button/switch abstraction it really does not belong in input
layer. There could be a
On 4/21/06, Yu, Luming [EMAIL PROTECTED] wrote:
There are keyboards with power/sleep buttons. It makes
sense they have
the same behavior than ACPI buttons.
Agree, make them behave like ACPI buttons -- remove them
from input stream, as they do not belong there...
What if there is no
On 4/20/06, Alexey Starikovskiy [EMAIL PROTECTED] wrote:
Xavier Bestel wrote:
There are keyboards with power/sleep buttons. It makes sense they have
the same behavior than ACPI buttons.
Agree, make them behave like ACPI buttons -- remove them from input stream,
as they do not belong
On 1/18/06, Kristen Accardi [EMAIL PROTECTED] wrote:
On Wed, 2006-01-18 at 23:23 +0100, Pavel Machek wrote:
snip
Device GDCK looks like dock to my untrained eye. Unfortunately its
type is IBM0079... ...
Ahha, and ibm_acpi.c agrees with me.
IBM_HANDLE(dock, root, \\_SB.GDCK,/*
On Tuesday 17 January 2006 19:56, Kristen Accardi wrote:
+
+ down(slot-crit_sect);
+ list_for_each(l, slot-funcs) {
+ func = list_entry(l, struct acpiphp_func, sibling);
list_for_each_entry() maybe?
+static struct acpiphp_func * get_func(struct acpiphp_slot *slot,
+
84 matches
Mail list logo
