gmane.os.freebsd.devel.acpi

Re: How can I help with thinkpad x220 issues?

Pierre-Luc Drouin — 2012-05-26T05:10:36



You should be able to bind these keys to commands such as mixer vol +5 amd
mixer vol -5

Re: How can I help with thinkpad x220 issues?

Kevin Oberman — 2012-05-26T03:25:47

After adding LEN0068 ti the ACPI IDs, I tried this and I get no ACPI
event when pressing either button, but I do get regular key press
events:
KeyPress event, serial 30, synthetic NO, window 0x4600001,
    root 0x121, subw 0x0, time 166670035, (96,121), root:(100,750),
    state 0x0, keycode 176 (keysym 0x1008ff13, XF86AudioRaiseVolume),
same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0x4600001,
    root 0x121, subw 0x0, time 166670185, (96,121), root:(100,750),
    state 0x0, keycode 176 (keysym 0x1008ff13, XF86AudioRaiseVolume),
same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 33, synthetic NO, window 0x4600001,
    root 0x121, subw 0x0, time 166927339, (98,0), root:(102,629),
    state 0x0, keycode 174 (keysym 0x1008ff11, XF86AudioLowerVolume),
same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:

Re: [CFT] SMP/i386 suspend/resume

Garrett Cooper — 2012-05-26T00:08:30

    A basic suspend test worked on my netbook. I'll have to see about
some edgecases I've run into in the past where UP wouldn't resume if
the system had been sitting for an extensive period of time, etc.
Very cool though -- thanks for your work so far on this ;)!
-Garrett

Re: How can I help with thinkpad x220 issues?

Lars Engels — 2012-05-24T06:55:32

About the key:

Did you try loading "acpi_ibm", "sysctl dev.acpi_ibm.0.events=1",
"cat /var/run/devd.pipe" and then press the keys. Does anything show up?

Re: How can I help with thinkpad x220 issues?

Kevin Oberman — 2012-05-23T22:19:14

If it has not been committed, the minor fix to make acpi_ibm work on
modern ThinkPads needs to be committed. Once done, the issues
mentioned need to be addressed.This includes getting brightness to be
setable from both the keypad hot-keys and from applications. ATM, I
can set the brightness, but making the hot-keys work will require the
ability to extract the current level so that it may be adjusted
plus/minus one.

The other issue is volume control keys don't work. I suspect it will
be similar to brightness, but I don't know just how to figure it out.

I should also mention that I don't have an X220. I have a T520, but
the issues seem to be identical, so fixing one will probably fix a lot
of recent ThinkPads.

Re: How can I help with thinkpad x220 issues?

Любомир Григоров — 2012-05-23T17:28:51

No. I got my X220 AFTER the suspend/resume was broken. There was a point, I
hear, during which it worked properly. I guess we are getting there.
FreeBSD 10 has some hopes for me, including Intel GEM/KMS patch in code and
some other goodies.

Re: How can I help with thinkpad x220 issues?

Ian Smith — 2012-05-23T17:25:34

 > Good news is that Konstantin's latest patch works with FreeBSD 9-STABLE so
 > no longer need to run HEAD. I would love to see resume work, though.

I don't suppose your Thinkpad maybe one of those that resumes properly, 
from X or from a VTY, with sysctl hw.syscons.sc_no_suspend_vtswitch=1 ?

cheers, Ian

Re: How can I help with thinkpad x220 issues?

Любомир Григоров — 2012-05-23T17:05:28

Well, brightness works with the command line, sooo.... I think it has to be
mapped to the hardware keys. There is a long thread where I discussed this
with a couple other members (toward the bottom for the recent brightness
discussion).
http://comments.gmane.org/gmane.os.freebsd.current/135827

Good news is that Konstantin's latest patch works with FreeBSD 9-STABLE so
no longer need to run HEAD. I would love to see resume work, though.

Cheers.

How can I help with thinkpad x220 issues?

Natacha Porté — 2012-05-23T15:13:57

Hello,

I happen to be the owner of a brand new Lenovo Thinkpad X220. From a
recent thread here I gather it almost works with FreeBSD, and the
remaining problems are screen brightness and screen left unpowered at
resume. Is that right?

So my question is, how can I help make progress in any of these area?
(though I admit I'm more interested in having the brightness problem
solved than the resume one)

I don't know anything about ACPI or about FreeBSD or Linux internals,
but I'm quite proficient in C and somewhat used to navigate in unknown
huge code bases.

So I guess the first steps to help would be to first learn stuff.

However I don't have much time available. I guess FreeBSD 11 would reach
end-of-life before I could reach a level of understanding I find
satisfying (though I admit I have high standards there), so I would have
to prioritize. So my question is rather *what* should I learn to provide
help as soon as possible?

For example, if the brightness issue is just a matter of extracting the
right num

Current problem reports assigned to freebsd-acpi< at >FreeBSD.org

FreeBSD bugmaster — 2012-05-21T11:07:07

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/164329  acpi       [acpi] hw.acpi.thermal.tz0.temperature shows strange v
o kern/163268  acpi       [acpi_hp] fix driver detach in absence of CMI
o kern/162859  acpi       [acpi] ACPI battery/acline monitoring partialy working
o kern/161715  acpi       [acpi] Dell E6520 doesn't resume after ACPI suspend
o kern/161713  acpi       [acpi] Suspend on Dell E6520
o kern/160838  acpi       [acpi] ACPI Battery Monitor Non-Functional
o kern/160419  acpi       [acpi_thermal] acpi_thermal kernel thread high CPU usa
o kern/158689  acpi       [acpi] value of sysctl hw.acpi.thermal.polling_rate ne
o kern/154955  acpi

Re: ACPI 'driver bug: Unable to set devclass'

John Baldwin — 2012-05-17T17:50:53

Not yet.  I'll try to test it later today unless someone beats me to it. :-P

Re: ACPI 'driver bug: Unable to set devclass'

Andriy Gapon — 2012-05-17T15:33:56

on 17/05/2012 17:05 John Baldwin said the following:

The patch has not been compile-tested? :)

Re: ACPI 'driver bug: Unable to set devclass'

John Baldwin — 2012-05-17T14:05:19

I haven't been able to try this yet, but I have a first cut at
www.freebsd.org/~jhb/patches/acpi_cpu.patch

Re: ACPI 'driver bug: Unable to set devclass'

John Baldwin — 2012-05-16T20:07:43

Oh, whoops.  Actually, the right way to do this I think is bus_hint_device_unit()
(and/or, not make the unit number in cpuX mean anything at all, but use a separate
ivar to track what PCPU_GET(cpuid) a given cpuX device corresponds to).  I think
the last approach is really the right way to fix this.

You do not have much money? We offer a solution to - work in yourspare time in our company

2012-05-16T19:26:26

We invite you to work in the remote assistant position.

This work takes 2-3 hours per week and requires absolutely no investment.
The essence of this work for incoming client requests in your city.
The starting salary is about 2500 EUR per month + bonuses.

You get paid your salary every 2 weeks and your bonuses after fulfilling each task!

We guarantee work for everyone. But we accept applications this week only!
Therefore, you should write a request right now. And you will start earning money, starting from next week.

Please indicate in the request:
Your name:
Your email address:
City of residence:

Please send the request to my email Margarito< at >eureseurope.com and I will answer you personally as soon as possible

Sincerely,
Margarito Lacy

Re: ACPI 'driver bug: Unable to set devclass'

John Baldwin — 2012-05-16T14:50:35

Yes.  The third step will see that unit 0 is already in use and shouldn't
reuse unit 0.

Re: ACPI 'driver bug: Unable to set devclass'

Andriy Gapon — 2012-05-15T16:35:12

on 15/05/2012 17:34 John Baldwin said the following:

Not sure what you disagree with...
First, the wildcard device is added to the child list during the walk.
Then, the unit 0 device is added to the list when acpi_timer identify is executed.
Then, the wildcard device is probed and gets unit number of zero.
Then, the fixed device is being probed and the unit number conflict arises.

Am I misunderstanding something?

Re: ACPI 'driver bug: Unable to set devclass'

John Baldwin — 2012-05-15T14:34:13

Eh.  This should not be true.  The unit 0 is reserved when device_add_child()
is called in the acpi_timer identify routine.  The wildcard device will not be
assigned a unit number until device_probe_child time.


That is, the unit for the wildcard devices should still be -1 here and should not
even get to this message.

I wonder if this is related to the recent changes to set the unit number for CPUs?

Re: [CFT] SMP/i386 suspend/resume

Peter Jeremy — 2012-05-15T07:30:02

On 2012-May-13 22:53:28 +0900, Mitsuru IWASAKI <iwasaki< at >jp.FreeBSD.org> wrote:

I've tried stable/9 r235399 with your patches as well as
PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND and suspend/resume now works
(for the first time) from VTY.  I haven't tried suspending directly
from X but expect that is still broken.  Thank you very much.

Re: [CFT] SMP/i386 suspend/resume

Jung-uk Kim — 2012-05-14T17:55:04

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2012-05-14 00:16:17 -0400, Mitsuru IWASAKI wrote:

First of all, thank you very much for your work!  I wanted to do it
for very long time but I had no time to actually implement it. :-)


I know for sure it is not related to your patches.  In fact, we cannot
resume most NVIDIA controllers without NVIDIA kernel driver + binary
X.org driver + VT switching hack (i.e.,
hw.syscons.sc_no_suspend_vtswitch=0, which is default).  Also, there
is ACPI_PM option for ports/x11/nvidia-driver but it doesn't help much
because it doesn't seem to save/restore GPU registers by itself (off
by default).  Very few NVIDIA controllers can be reset with BIOS POST
or saved/restored with VBE functions.  Many Intel controllers have
similar issues and they need kib's KMS driver.  Usually, ATI/AMD
controllers have no problem when (relatively recent) vesa.ko is
compiled into kernel or loaded as module as they have complete VBE
save/restore functions.  Similarly, any video controllers with

Current problem reports assigned to freebsd-acpi< at >FreeBSD.org

FreeBSD bugmaster — 2012-05-14T11:07:05

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/164329  acpi       [acpi] hw.acpi.thermal.tz0.temperature shows strange v
o kern/163268  acpi       [acpi_hp] fix driver detach in absence of CMI
o kern/162859  acpi       [acpi] ACPI battery/acline monitoring partialy working
o kern/161715  acpi       [acpi] Dell E6520 doesn't resume after ACPI suspend
o kern/161713  acpi       [acpi] Suspend on Dell E6520
o kern/160838  acpi       [acpi] ACPI Battery Monitor Non-Functional
o kern/160419  acpi       [acpi_thermal] acpi_thermal kernel thread high CPU usa
o kern/158689  acpi       [acpi] value of sysctl hw.acpi.thermal.polling_rate ne
o kern/154955  acpi