Hi all,
can someone help me to fix this error?
dsdt.dsl 7202: WBYT (TSAD, 0x4F, Local0)
Error4049 -^ Method local variable
is not initialized (Local0)
Best Regards
Dirk Partikel
Part of dsdt:
Method (STOS, 3, NotSerialized)
{
WBYT (TSA
Hello. I had seen a string "Please send dmidecode to
linux-acpi@vger.kernel.org" in dmesg output and decided to
sent you this information.
# dmidecode 2.8
SMBIOS 2.4 present.
34 structures occupying 1112 bytes.
Table at 0x000DF810.
Handle 0x, DMI type 0, 24 bytes
BIOS Information
Vendo
Henrique de Moraes Holschuh wrote:
thinkpad-acpi wants to differentiate IBM from Lenovo ThinkPads, and the PCI
IDs are the best way to go about it for quirk tables and so on. Add the
missing Lenovo PCI ID to pci_ids.h.
Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
Cc: Jeff Garz
Hi Len,
These patches a targeted to 2.6.23.
I updated the previous series with a couple more patches one of which fixes a
bug present in 2.6.22 and that I'll push to the stable maintainers.
Important changes include the scancode enabling work done by Richard Hughes and
support for some recent vaio
Signed-off-by: Mattia Dongili <[EMAIL PROTECTED]>
---
drivers/misc/sony-laptop.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/misc/sony-laptop.c b/drivers/misc/sony-laptop.c
index 2063de7..9e27616 100644
--- a/drivers/misc/sony-laptop.c
+++ b/drivers/misc/sony-
Recent Vaios (C, AR, N, FE) need some special initialization
sequence to enable Fn keys interrupts through the Embedded
Controller. Moreover Fn keys have to be decoded internally
using ACPI methods to get the key code.
Thus a new DMI table to add SNC init time callbacks and new
mappings for model-s
The Vaio FE series uses the same sequence as Vaio C series
Signed-off-by: Mattia Dongili <[EMAIL PROTECTED]>
---
drivers/misc/sony-laptop.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/misc/sony-laptop.c b/drivers/misc/sony-laptop.c
index 916b477..69097
The rewritten event reading code from sonypi was absolutely wrong,
this patche makes things functional for type2 and type1 models.
Cc: Andrei Paskevich <[EMAIL PROTECTED]>
Signed-off-by: Mattia Dongili <[EMAIL PROTECTED]>
---
drivers/misc/sony-laptop.c | 30 ++
1 fil
- lid state: GLID
- indicator lamp: GILS/SILS
- multimedia bass gain: GMGB/CMGB
Signed-off-by: Mattia Dongili <[EMAIL PROTECTED]>
---
drivers/misc/sony-laptop.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/misc/sony-laptop.c b/drivers/misc/sony-la
Signed-off-by: Mattia Dongili <[EMAIL PROTECTED]>
---
drivers/misc/sony-laptop.c | 20 +++-
1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/drivers/misc/sony-laptop.c b/drivers/misc/sony-laptop.c
index ecac39b..4b15f0c 100644
--- a/drivers/misc/sony-laptop.c
+++ b
From: Richard Hughes <[EMAIL PROTECTED]>
Cc: Dmitry Torokhov <[EMAIL PROTECTED]>
Signed-off-by: Richard Hughes <[EMAIL PROTECTED]>
Signed-off-by: Mattia Dongili <[EMAIL PROTECTED]>
---
drivers/misc/sony-laptop.c | 134 +++
1 files changed, 84 insertions(+)
Hi Matthew!
On Sat, 14 Jul 2007, Matthew Garrett wrote:
> On Sat, Jul 14, 2007 at 11:12:09AM -0300, Henrique de Moraes Holschuh wrote:
>
> Ah, I see this one fixes some of my comments. However:
>
> > + KEY_RESERVED, /* 0x0F: FN+HOME (brightness up) */
> > + /* Scan codes 0
On Sat, 14 Jul 2007, Matthew Garrett wrote:
> On Sat, Jul 14, 2007 at 11:12:04AM -0300, Henrique de Moraes Holschuh wrote:
> > -.hid = IBM_PCI_HID,
> > + /* THIS ONE MUST NEVER BE USED FOR DRIVER AUTOLOADING.
>
> Some rationale here would be good. There are no known devices where
> loading
On Sat, 14 Jul 2007, Matthew Garrett wrote:
> On Sat, Jul 14, 2007 at 11:12:00AM -0300, Henrique de Moraes Holschuh wrote:
> > - KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
> > - KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
> > - KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNO
On Sat, 14 Jul 2007, Matthew Garrett wrote:
> On Sat, Jul 14, 2007 at 11:11:59AM -0300, Henrique de Moraes Holschuh wrote:
> > +static u16 hotkey_keycode_map[] = {
> > + /* Scan Codes 0x00 to 0x0B: ACPI HKEY FN+F1..F12 */
> > + KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
> > + KEY_UNK
On Sun, Jul 15, 2007 at 02:59:22PM -0300, Henrique de Moraes Holschuh wrote:
> On Sat, 14 Jul 2007, Matthew Garrett wrote:
>
> > On Sat, Jul 14, 2007 at 11:12:09AM -0300, Henrique de Moraes Holschuh wrote:
> >
> > Ah, I see this one fixes some of my comments. However:
> >
> > > + KEY_RES
On Sun, Jul 15, 2007 at 03:12:33PM -0300, Henrique de Moraes Holschuh wrote:
> On Sat, 14 Jul 2007, Matthew Garrett wrote:
> > KEY_BRIGHTNESSUP
>
> Only if I start filtering it out when disabled by the mask. This key is not
> to be sent to userspace unless explicitly configured to do so by someth
On Sun, Jul 15, 2007 at 03:02:46PM -0300, Henrique de Moraes Holschuh wrote:
> On Sat, 14 Jul 2007, Matthew Garrett wrote:
> > On Sat, Jul 14, 2007 at 11:12:04AM -0300, Henrique de Moraes Holschuh wrote:
> > > - .hid = IBM_PCI_HID,
> > > + /* THIS ONE MUST NEVER BE USED FOR DRIVER AUTOLOADING.
> >
On Sun, Jul 15, 2007 at 03:05:29PM -0300, Henrique de Moraes Holschuh wrote:
> On Sat, 14 Jul 2007, Matthew Garrett wrote:
> > Again, we have keycodes for most of these and we have the ability to
> > make the driver choose the correct one by default. Why make things more
> > difficult?
>
> Becau
On Sun, 15 Jul 2007, Matthew Garrett wrote:
> > No. This is handled in firmware in IBM thinkpads, and userspace only screws
> > it up. I am tired of watching people get this routed to the AC97 mixer by
> > default. That is a fringe configuration that only makes sense when using a
> > dock, and w
On Sun, 15 Jul 2007, Matthew Garrett wrote:
> On Sun, Jul 15, 2007 at 03:05:29PM -0300, Henrique de Moraes Holschuh wrote:
> > On Sat, 14 Jul 2007, Matthew Garrett wrote:
> > > Again, we have keycodes for most of these and we have the ability to
> > > make the driver choose the correct one by defa
On Sun, Jul 15, 2007 at 05:03:38PM -0300, Henrique de Moraes Holschuh wrote:
> I do not consider screwing up the mixer handling a harmless result.
We've shipped in this configuration for over a year. Total number of
bugs filed? None. It's not ideal, but it's simply not true that it
results in a
On Sun, Jul 15, 2007 at 05:09:48PM -0300, Henrique de Moraes Holschuh wrote:
> On Sun, 15 Jul 2007, Matthew Garrett wrote:
> > But we're able to differentiate between the models.
>
> Yes. And I was told to not do it in the kernel when possible, so I will map
> by default only what is marked and wo
Hi Matthew!
On Sun, 15 Jul 2007, Matthew Garrett wrote:
> On Sun, Jul 15, 2007 at 02:59:22PM -0300, Henrique de Moraes Holschuh wrote:
> > On Sat, 14 Jul 2007, Matthew Garrett wrote:
> >
> > > On Sat, Jul 14, 2007 at 11:12:09AM -0300, Henrique de Moraes Holschuh
> > > wrote:
> > >
> > > Ah, I
On Sun, Jul 15, 2007 at 05:17:12PM -0300, Henrique de Moraes Holschuh wrote:
> Life would be significantly easier if I could convey that information in the
> kernel. Since I cannot, I effectively consider these keys to be "defective"
> as far as the regular input device events are supposed to mea
On Sun, 15 Jul 2007, Matthew Garrett wrote:
> On Sun, Jul 15, 2007 at 05:03:38PM -0300, Henrique de Moraes Holschuh wrote:
> > I do not consider screwing up the mixer handling a harmless result.
>
> We've shipped in this configuration for over a year. Total number of
> bugs filed? None. It's not
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 kernel and HAL, it is an interface between kernel
> and userspace.
Hal is the only piece of userspace that knows h
On Mon, Jul 16, 2007 at 02:34:37AM +0900, Mattia Dongili wrote:
> + /* we emit the scancode so we can always remap the key */
> + input_event(kp.dev, EV_MSC, MSC_SCAN, event);
As I said to Henrique, I don't think this is the right solution. We know
what these keys do - we
On Sun, 15 Jul 2007, Matthew Garrett wrote:
> On Sun, Jul 15, 2007 at 05:09:48PM -0300, Henrique de Moraes Holschuh wrote:
> > On Sun, 15 Jul 2007, Matthew Garrett wrote:
> > > But we're able to differentiate between the models.
> >
> > Yes. And I was told to not do it in the kernel when possible,
On Sun, 15 Jul 2007, Matthew Garrett wrote:
> On Sun, Jul 15, 2007 at 03:02:46PM -0300, Henrique de Moraes Holschuh wrote:
> > On Sat, 14 Jul 2007, Matthew Garrett wrote:
> > > On Sat, Jul 14, 2007 at 11:12:04AM -0300, Henrique de Moraes Holschuh
> > > wrote:
> > > > -.hid = IBM_PCI_HID,
>
On Sun, Jul 15, 2007 at 06:14:21PM -0300, Henrique de Moraes Holschuh wrote:
> On Sun, 15 Jul 2007, Matthew Garrett wrote:
> > We already have in-kernel drivers that do this properly, so I'd suspect
> > that whoever told you that was wrong.
>
> I got tired of being told one way or the other, alre
On Sun, 15 Jul 2007, Jeff Garzik wrote:
> Henrique de Moraes Holschuh wrote:
>> thinkpad-acpi wants to differentiate IBM from Lenovo ThinkPads, and the
>> PCI
>> IDs are the best way to go about it for quirk tables and so on. Add the
>> missing Lenovo PCI ID to pci_ids.h.
>> Signed-off-by: Henriq
On Sun, Jul 15, 2007 at 06:18:21PM -0300, Henrique de Moraes Holschuh wrote:
> Oh, you CAN use the IBM0068 device to autoload. I am not really sure
> nothing but ThinkPads use it, and I already have other autoload hooks (based
> on DMI) anyway, but it can be used as an autoload hint, yes.
>
> Bu
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 kernel and HAL, it is an interface between kernel
> > and userspac
On Sun, 15 Jul 2007, Matthew Garrett wrote:
> On Sun, Jul 15, 2007 at 06:14:21PM -0300, Henrique de Moraes Holschuh wrote:
> > On Sun, 15 Jul 2007, Matthew Garrett wrote:
> > > We already have in-kernel drivers that do this properly, so I'd suspect
> > > that whoever told you that was wrong.
> >
On Sun, Jul 15, 2007 at 06:54:53PM -0300, Henrique de Moraes Holschuh wrote:
> On Sun, 15 Jul 2007, Matthew Garrett wrote:
> > Hal is the only piece of userspace that knows how to speak to more than
> > one type of backlight in any useful way, which makes it the de-facto
> > reference for how use
On Sun, Jul 15, 2007 at 07:08:01PM -0300, Henrique de Moraes Holschuh wrote:
> On Sun, 15 Jul 2007, Matthew Garrett wrote:
> > Right now, the hotkey functionality of the driver is not terribly useful
> > without (bleeding-edge) userspace. This is inconsistent with the
> > majority of input driver
On Sun, 15 Jul 2007, Matthew Garrett wrote:
> On Sun, Jul 15, 2007 at 07:08:01PM -0300, Henrique de Moraes Holschuh wrote:
> > On Sun, 15 Jul 2007, Matthew Garrett wrote:
> > > Right now, the hotkey functionality of the driver is not terribly useful
> > > without (bleeding-edge) userspace. This is
On Sun, Jul 15, 2007 at 09:12:40PM -0300, Henrique de Moraes Holschuh wrote:
> On Sun, 15 Jul 2007, Matthew Garrett wrote:
> > No, it doesn't. It interacts in a way that you may not consider to be
> > ideal - the vast majority of our users appear to prefer it to the
> > previous behaviour, so it'
On Sun, 15 Jul 2007, Matthew Garrett wrote:
> On Sun, Jul 15, 2007 at 06:54:53PM -0300, Henrique de Moraes Holschuh wrote:
> > On Sun, 15 Jul 2007, Matthew Garrett wrote:
> > > Hal is the only piece of userspace that knows how to speak to more than
> > > one type of backlight in any useful way, wh
On Mon, 16 Jul 2007, Matthew Garrett wrote:
> On Sun, Jul 15, 2007 at 09:12:40PM -0300, Henrique de Moraes Holschuh wrote:
> > On Sun, 15 Jul 2007, Matthew Garrett wrote:
> > > No, it doesn't. It interacts in a way that you may not consider to be
> > > ideal - the vast majority of our users appear
On Thu, Jul 12, 2007 at 10:18:17AM +0100, Richard Hughes wrote:
> On Thu, 2007-07-12 at 09:32 +0400, Alexey Starikovskiy wrote:
> > >> [*] Does someone have an alternative for
> > >> /proc/acpi/battery/BAT1/{state,info}?
> > I'm working on it. Should have proto by the end of week.
>
> If you are u
42 matches
Mail list logo
