On 8/23/06, Dmitry Torokhov [EMAIL PROTECTED] wrote:
On 8/18/06, Len Brown [EMAIL PROTECTED] wrote:
that patch was an incremental depending on the previous patch.
Please send just the final patch vs 2.6.18-rc4 to the above, also cc:
linux-kernel@vger.kernel.org
Also, Dmitry had asked
On 7/26/06, Dmitry Torokhov [EMAIL PROTECTED] wrote:
This is not a complaint about the driver but more a generic question -
how valid is it to mix error values from 2 different sets? I mean
input_register_device signals standard -E while
acpi_install_address_space_handler signals
On 7/14/06, Brown, Len [EMAIL PROTECTED] wrote:
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.
Ok. I'll add a maintainers entry for myself.
Yes, I know that you were following the existing
On 7/7/06, Jaya Kumar [EMAIL PROTECTED] wrote:
On 7/7/06, Dmitry Torokhov [EMAIL PROTECTED]
I think because the driver would be new for the mainline we should
remove the old way of reporting events and rely on input layer (and
make the driver depend on CONFIG_INPUT).
Also, could you please
On 7/7/06, Yu, Luming [EMAIL PROTECTED] wrote:
+ if (function == ACPI_WRITE) {
+ status = acpi_bus_generate_event(dev, 0x80, address);
+ atlas_input_report((u8) address);
+ } else {
Please don't use two mechanism to report one event.
For other part of
On 7/7/06, Dmitry Torokhov [EMAIL PROTECTED]
I think because the driver would be new for the mainline we should
remove the old way of reporting events and rely on input layer (and
make the driver depend on CONFIG_INPUT).
Also, could you please change phys from acpi/input0 to something
like
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 simultaneously report the same event
via both ACPI and
On 6/2/06, Dmitry Torokhov [EMAIL PROTECTED] wrote:
I think that you should free (unregister) input device only after
button handler was unregistered, otherwise there is a risk that it
will try to access already freed device. Other than that input part
looks good.
Oops. Sorry about that.
On 5/22/06, Pavel Machek [EMAIL PROTECTED] wrote:
ACK, but I guess you should cc Dmitry (input maintainer) and possibly
Andrew Morton to get it in... Ok, few more nits.
Will do.
+#else
+#define atlas_free_input(...)
+#define atlas_setup_input(...) 0
+#define atlas_input_report(...)
On 3/8/06, Yu, Luming [EMAIL PROTECTED] wrote:
I suggest LCD support in hotkey.c like:
http://bugzilla.kernel.org/attachment.cgi?id=6843action=view
Config userspace acpi daemon to respond events by evoking
LCD._BCM with command:
echo -n xx /sys/hotkey/brightness.
A quick question
On 3/8/06, Yu, Luming [EMAIL PROTECTED] wrote:
I know this user-defined region needs address space handler, but your
address space handler below is so weird that make me doubt
the correctness. The example of address space handler is:
ec.c : acpi_ec_space_handler
As you suggested, I looked
On 3/7/06, Yu, Luming [EMAIL PROTECTED] wrote:
I've added it as an attachment here. Please let me know if you get it.
I just found this:
Device (SVG)
Device (LCD)
It looks too simple to fit video.c.
I'm sorry but I'm confused. Do you mean that I shouldn't try to
On 3/8/06, Yu, Luming [EMAIL PROTECTED] wrote:
I think video.c is NOT a right solution for your problem.
Cool. I agree with you there.
You have dedicated ACPI device and method for brightness control.
So hotkey.c is the right place for support Device LCD.
I'm confused by what you are saying.
On 2/21/06, Yu, Luming [EMAIL PROTECTED] wrote:
It would be better if you can merge this stuff with acpi video driver.
If you look at video.c, there is NO HID definition for video device.
we rely on acpi_video_bus_match to recoginize video device in ACPI
namespace.
I took a quick look and I
feedback
or suggestions.
Thanks,
Jaya Kumar
Signed-off-by: Jaya Kumar [EMAIL PROTECTED]
---
MAINTAINERS |5
drivers/acpi/Kconfig | 11 +
drivers/acpi/Makefile |1
drivers/acpi/atlas_acpi.c | 279
++
4 files
On 2/20/06, Matthew Garrett [EMAIL PROTECTED] wrote:
On Mon, Feb 20, 2006 at 06:49:54PM +0800, Jaya Kumar wrote:
I'm not sure how standard that is. For example, I looked at the asus
and toshiba drivers. These ACPI board drivers use
/proc/acpi/somedevice/lcd. For example,
And, from
Hi ACPI folk,
I was looking at the following ACPI code in 2.6.16-rc3. I'm trying to
understand if there maybe a possible memory leak in the following
scenario. Here's what I see:
drivers/acpi/button.c calls:
464 result = acpi_bus_register_driver(acpi_button_driver);
with
17 matches
Mail list logo
