於 日，2012-05-27 於 23:45 +0800，joeyli 提到：
> 於 日，2012-05-27 於 10:28 +0200，Marek Vasut 提到：
> > Dear joeyli,
> >
> > > > Hi Marek,
> > > >
> > > > 於 一，2012-05-07 於 21:38 +0200，Marek Vasut 提到：
> > > >
> > > > > > > >
> > > > > > > > Now it gets interesting ;-)
> > > > > > > >
> > > > > > > > The obj->buffer.pointer contains the following:
> > > > > > > > 0x05 0x01 0x00 0x00 0x00 0x00 0x00 0x00
> > > > > > > >
> > > > > > > > That means, return_value.function is 0x05, instead of 0x01
> > > > > > > > (WMID_HOTKEY_EVENT).
> > > > > > >
> > > > > > > Yes, the 0x05 event is a event reflect to g-sensor, but I don't
> > > > > > > have any hardware can test it.
> > > > > > >
> > > > > > > Did you see any other value but not just "0x05 0x01 0x00 0x00 0x00
> > > > > > > 0x00 0x00 0x00" ?
> > > > > >
> > > > > > Nope, nothing at all. I flipped it back and forth, no result :(
> > > > > >
> > > > > > > I mean if you invert your table, did you see other return value?
> > > > > > > The return data must point to Portrait or Landscape view.
> > > > > >
> > > > > > Nope, still zeroes. This is only some interrupt-like event I believe.
> > > > > > My opinion is, I need to call some WMI method to actually read-back
> > > > > > the data.
> > > > > >
> > > > > >
...
> > > >
> > > > Sorry! I am sticking on another critical issue. I will find a time to
> > > > trace TAB's DSDT at this week.
> > >
> > > No need to be sorry, I know exactly what you mean :) No need to rush, I'm
> > > stuck with a few bugs at work too.
> >
> > Hi, I'm starting to get curious again. Did you had time to look into it? Thanks
> > in advance!
> >
>
> Sorry for I am late to reply you!
...
> >
>
> I checked your DSDT, unfortunately I found the logic is empty for
> G-sesor in W500's DSDT.
>
> I mean, that's right we got only g-sensor event but didn't have sensor
> state data, because they didn't put the return value in DSDT!
>
> On you TAB W500, the _Q7C method should run by EC when G-sensor detected
> state change:
>
> Method (_Q7C, 0, NotSerialized)
> {
> If (LEqual (^^SENR.GSLC, Zero)) /* G sensor enabled? */
> {
> Store (0x05, Index (^^^WMID.FEBC, Zero)) /* 0x05 is Sensor Event */
> Store (One, Index (^^^WMID.FEBC, One)) /* 0x01 is G-Sensor */
> Notify (WMID, 0xBC)
> }
>
> If (LMST)
> {
> Return (Zero)
> }
> }
>
> You can enable ACPI debug message to verify _Q7C method run when you reverse TAB, add the
> following kernel parameter and reboot:
>
> acpi.debug_level=0x0000000F acpi.debug_layer=0xffffffff log_buf_len=5M
>
>
> The WMI event code in DSDT like this:
>
> Method (EVBC, 0, NotSerialized) /* call by _WED */
> {
> ...
> If (LEqual (Local0, One)) /* hotkey event */
> {
> ...
> If (LEqual (Local0, 0x05)) {} /* 0x05 is Sensor Event, why empty? */
> ...
> Store (Zero, Index (FEBC, 0x04)) /* all set to zero */
> Store (Zero, Index (FEBC, 0x05))
> Store (Zero, Index (FEBC, 0x06))
> Store (Zero, Index (FEBC, 0x07))
> ...
> Return (FEBC)
> }
>
>
> That's why we receive a G-sensor event but didn't have orientation information of TAB.
> On windows platform, I believe there have another driver listen and handle this g-sensor event when tab turned.
>
OK, there havse a "BST0001" acpi device should handle by a g-sensor
driver or a special acpi driver:
Scope (_SB.PCI0.LPC0)
{
Device (SENR)
{
Name (_HID, "BST0001")
Name (_UID, Zero)
Name (_STA, 0x0F)
Name (GSLC, Zero) /* G-sensor lock? */
Name (GSLX, Zero) /* X */
Name (GSLY, Zero) /* Y */
Name (GSLZ, Zero) /* Z */
...
Method (_INI, 0, NotSerialized)
...
Method (RDST, 0, NotSerialized)
{
...
Method (RDVL, 0, NotSerialized)
{
...
Method (WRVL, 1, NotSerialized)
{
...
There have 3 methods "RDST", "RDVL" and "WRVL", currently, no idea for
what functions provided by those 3 methods.
my _GUESS_:
"RDST" is read state?
"RDVL" is read value(what!?)
"WRVL" is write value?
My idea is just find out which method is for read the orientation of
G-sensor then we can use a driver raise it to userland.
Thanks a lot!
Joey Lee
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
