ACPI

On Fri, May 24, 2002 at 07:51:04AM +0200, Jens Haug wrote:
>=20
> > > Shouldn't you be looking at the button state, i.e. that last number
> > > which appears in the event output? It looks like 1 =3D=3D pressed, 2 =
=3D=3D
> > > released.
> >=20
> > Nope, that's a counter, never mind. (I had to kill ospmd to find this
> > out...)
>=20
> Anyway, you should be able to distinguish between even and odd numbers
> which gives you the same information.

Not on all systems. E.g., on my system each key release increases the
counter - pressing the key does nothing. Don't rely on (counter % 2).

Dominik

>I also tried the kacpid.patch which in my system seems to be the only way of
>enabling events, but with it I lost the software suspending capability
>because the kacpid thread couldn't be stopped by swsusp.

A> I think that Juliusz Chroboczek is probably working to make his patch 
A> (kacpid) compatible with swsusp... ;)
A> isn't it ?

That's what I call a subtle hint.  Which version of the swsusp patch
works with 2.4.18 on the Presario 711?

                                        Juliusz

P.S. Nonostante la stranezza del mio nome, sono un ``he'', non un ``it''.

Hi,

> Regarding the second issue. As far as I've seen, C2 should be a battery=
=20
> saving state, or am I wrong? C1, as the /proc/acpi/processor/CPU0/power=
=20
> indicates, should be the default state. So, the fact of the processor bei=
ng=20
> on C2 by default, even on AC power is an undesired feature isn't it?

C2 is an "idling state". Whenever there's nothing to do for your processor
(and that happens really often on typical systems), it enters this "idling
state", consumes less power and produces less heat. The "cost" of it: it
takes a couple of microseconds to wake the processor up when there's new
work to do. This is the "latency" mentioned in /processor/.../power, and
except on really low-latency-preemptible-real-time-systems the Cx latency
might be a problem.

Dominik

Regarding swsusp, I tested sucessfully swsusp-beta5 (from=20
http://fchabaud.free.fr) with acpi-20020517 and kernel 2.4.18, using the=20
specific patch for acpi, corrected for the filename diferences of this la=
st=20
version of acpi (system.c instead of acpi_system.c), altough mine is a=20
Presario 12XL515 (1200 series) not a 711.

Best regards,

Lu=EDs Neves

Derek Broughton wrote:
> From: "Stefan Bellon" <sbellon@...>

[snip]

> > Ah, I'm not so sure about that. The tests when acpid was not
> > running didn't put the notebook in S1 obviously. And therefore it's
> > clear that when opening the lid again, the second lid event occurs.
> > But when acpid is running, the notebook goes to S1 when the first
> > lid event occurs. When you open the lid again, the second event
> > /should/ occur, but the notebook is sleeping. Then you press the
> > power button and /that/ event is recognised. Perhaps the lid
> > opening is then "remembered" and inserted into the event queue.

> Nothing you did _should_ have put the notebook in S1.  acpid had to
> have done that.

Sorry, that's what I meant with "when acpid is running ...". Yes, when
acpid is running and has the lid button script recognised, /then/ acpid
puts the notebook into S1 if the lid is closed. That's what I meant to
say.

> So I still say acpid is processing things in the wrong order.

But how should acpid get the lid event before the power button event?

> However, it seems we both may be making an invalid assumption - that
> is, you simply can't ever recognize any button push except the power
> button when you are in S1.  That's a real bitch... 

Yes, exactly. Either every event that occurred during S1 mode has to be
ignored when waking up, or they should be raised in the correct order.

Greetings,

Stefan.

-- 
 Stefan Bellon * <mailto:sbellon@...> * <http://www.sbellon.de/>
 PGP 2 and OpenPGP keys available from my home page

 If the answer is Microsoft, the question must have been quite stupid.

On Fri, May 24, 2002 at 10:56:20AM -0700, Grover, Andrew wrote:
> > From: Jens Haug [mailto:haug@...] 
> > Ok - so if nobody wants me to test it and if nobody gives me this
> > ospmd.conf or docs about it, I'll stick with the old one.
> > But I don't think that's what releases and mailing list are all about.
> 
> Well this is the acpi-*devel* mailing list. Is proficiency in C too high an
> expectation? (probably, but it's something to shoot for. ;-) Hey, coding is
> a lot of fun. Admittedly, I've released broken code -- how can people not
> seize upon that as an opportunity to demonstrate their programming prowess
> by whipping it into shape?
> 
> ;-)

Hey!  It is wrotten in C++, and even worst the gui is for KDE :)
Hum, what about some gnomeries ?  It should be Ok if I submit
you those kind of support ?

-- 
Ducrot Bruno
http://www.poupinou.org        Page profaissionelle
http://toto.tu-me-saoules.com  Haume page

> From: Ducrot Bruno [mailto:ducrot@...] 

[snip Jens talking about ospmd]

> > how 
> can people not
> > seize upon that as an opportunity to demonstrate their 
> programming prowess
> > by whipping it into shape?

> Hey!  It is wrotten in C++, and even worst the gui is for KDE :)
> Hum, what about some gnomeries ?  It should be Ok if I submit
> you those kind of support ?

Please do, that's the idea. I'd prefer not to write any GUI code (leave that
to the people who are better at it) and focus on improving the nonvisual,
policy aspects of the daemon. But we needed something to get the ball
rolling and to exercise the daemon and the library interface, so that's what
ospm_gui is.

(BTW yes you are right it does use C++, but nothing too fancy. IMHO once one
moves from systems to application programming, C++ is the right tool for the
job.)

Regards -- Andy

From: "Stefan Bellon" <sbellon@...>

> Ducrot Bruno wrote:
> > On Thu, May 23, 2002 at 05:27:01PM +0200, Stefan Bellon wrote:
>
> [snip]
>
> > > But: All syslog entries between wake-up and "hwclock --hctosys" are
> > > incorrect as the date/time is wrong. Why isn't the clock set in the
> > > ACPI implementation in the kernel?
>
> > Certainly because others issues have to be resolved.
>
> Ah, so it's a "it hasn't been done yet" and not a "this won't be done
> because the spec says so" thing.

I can't see why it _should_ be done.  Setting the clock isn't done in the
kernel at boot time, why would it be done by ACPI?  I'm sure it isn't a
"this won't be done because the spec says so" thing.because I can't imagine
why the spec would even mention it.
--
derek

On Fri, May 24, 2002 at 11:03:55AM -0700, Grover, Andrew wrote:
> > From: Warren Togami [mailto:warren@...] 
> > > > You can overwritte the _OS in an include file with 
> > 'Microsoft Windows NT'.
> > > > It seems to be the 'best' for Linux or other free-OS 
> > (FreeBSD-current p.e)
> > Do I understand this correctly.  That hardware vendor intentionally
> > broke ACPI for non-Microsoft operating systems?
> 
> Not exactly. I would think the reason would be more to work around less
> sophisticated ACPI driver versions in earlier Windows versions, like Win98
> and 98SE. For example, W2K calls _REG when operation regions (such as the EC
> opregion) become accessible, whereas Win98 does not. BIOS writers have to
> handle this if they want to run on Win98.
> 
> Regards -- Andy

Just show this page:
http://mobilix.org/toshiba_s3000_601.html

It is about the Toshiba Satellite 3000-601.

I quote:

" acpi does not work properly either. the info given
for instance in /proc/acpi/battery/1/status seems to be
static and seems to break when switching between power
supply by battery and line. this could also be a problem
with the hardware. the acpi software for winXP crashes,
too, when fiddling around with the power cord to switch
between ac/dc and battery."

Note that the issue with the AC-adapter was corrected
by my version of the DSDT for this laptop...

Worse, I did not doubt that if a submit a bug to Toshiba,
they will be likely to don't respond to me...


-- 
Ducrot Bruno
http://www.poupinou.org        Page profaissionelle
http://toto.tu-me-saoules.com  Haume page

On 2002.05.24 14:43:51 +0100 Ducrot Bruno wrote:

> 
> The trouble is the internal management of the laptop.  OEMs have to check
> that it work for the provided OS.  For example, if we wake on a Toshiba
> 3000-100, the mouse is not reset correctly.  If we say that we are on 'NT',
> the mouse now work as expected.  Why *exactly* ?  I don't know, but
> I suspect that a SMI handler was launched by the system in order to
> correct the issue for NT, but not for windows.
> 

There's 2 explanations to this, one is diferent versions of windows crap
out in diferent ways (see the diferences between handling of usb stuff for
instance). Other is "we sell it with this OS and you shall not run
another", if you dare we'll make sure it breaks miserably and blame you
for it. 
-- 
Carlos Morgado - chbm(at)chbm(dot)nu - http://chbm.nu/ -- gpgkey: 0x1FC57F0A
http://wwwkeys.pgp.net/ FP:0A27 35D3 C448 3641 0573 6876 2A37 4BB2 1FC5 7F0A
Software is like sex; it's better when it's free. - Linus Torvalds

On Fri, May 24, 2002 at 03:57:50PM +0100, Carlos Morgado wrote:
> 
> On 2002.05.24 14:43:51 +0100 Ducrot Bruno wrote:
> 
> >
> >The trouble is the internal management of the laptop.  OEMs have to check
> >that it work for the provided OS.  For example, if we wake on a Toshiba
> >3000-100, the mouse is not reset correctly.  If we say that we are on 'NT',
> >the mouse now work as expected.  Why *exactly* ?  I don't know, but
> >I suspect that a SMI handler was launched by the system in order to
> >correct the issue for NT, but not for windows.
> >
> 
> There's 2 explanations to this, one is diferent versions of windows crap
> out in diferent ways (see the diferences between handling of usb stuff for
> instance). Other is "we sell it with this OS and you shall not run
> another", if you dare we'll make sure it breaks miserably and blame you
> for it. 

This is prohibited in France.  But we saw those abuses.


-- 
Ducrot Bruno
http://www.poupinou.org        Page profaissionelle
http://toto.tu-me-saoules.com  Haume page

On Fri, May 24, 2002 at 02:20:22PM +0200, Alberto Casagrande wrote:
> On Fri, May 24, 2002 at 12:13:26PM +0100, Carlos Morgado wrote:
> > 
> > > I have tryed was 2808, so I don't know if there is another release) is
> > there's 2960 now, i'm still at 2880
> > 
> 


AFAIK I doubt it will work.  If you look the file nv.c, the power management is
*explicitely* turned off.

Search the function nv_kern_pm(), then you can see those lines:

#if 0
...
	some statements that could perhaps work.
...
#else
	/* do dummy things */
#endif


It is possible that if you change this line as

#if 1

it will work.  I don't have tested that, and I don't want anymore
this driver in my system.


-- 
Ducrot Bruno
http://www.poupinou.org        Page profaissionelle
http://toto.tu-me-saoules.com  Haume page

On 2002.05.24 12:49:27 +0100 Ducrot Bruno wrote:

> 
> 
> It is possible that if you change this line as
> 
> #if 1
> 
> it will work.  I don't have tested that, and I don't want anymore
> this driver in my system.
> 

wouldn't that break the nvidia license ?

-- 
Carlos Morgado - chbm(at)chbm(dot)nu - http://chbm.nu/ -- gpgkey: 0x1FC57F0A
http://wwwkeys.pgp.net/ FP:0A27 35D3 C448 3641 0573 6876 2A37 4BB2 1FC5 7F0A
Software is like sex; it's better when it's free. - Linus Torvalds