evtouch driver on x86_64 (segfault)

[matth45]

I actually ran through most of that a couple months ago, and posted about it here:

http://ubuntuforums.org/showthread.php?t=442483&page=9

I never tried booting from the recompiled dsdt, but given the warnings I thought it wouldn't make much of a difference. I could be wrong though - maybe I'll give that a try.

[guyc]

Missed that, but it confirms my suspicions somewhat - from what I read acpi functions not returning a value is exactly what causes linux to crash but is ignored in Windows (in any honest compiler it would be considered an error). Also, I'm worried about the Windows only functionality. You would think passing acpi_osi="Linux" could help there, but one wonders.

I doubt it will make much of a difference if you boot from it without repairing the problems first.

By the way, did you have any luck with the handwriting recognition software I mentioned/find something better?

[matth45]

Interesting observation! I did actually look at the code when I posted that - It was a structure like:

if (condition1) {
blah
return value;
}
if (condition2){
blah
return value;
}

// no return statement here
end of function;

From what I recall, I remember thinking condition1 and condition2 were exclusive - so it couldn't actually leave the function without returning - it would just cause a compiler warning. That's why I ignored it.

But I admit it was a bit lazy of me not to try it. If I have a chance this weekend I'll take a look.

Thanks for the recommendations on the handwriting stuff. I like cellwriter, but I'm not sure it's practical to actually use it

Since I have messy handwriting I don't think jarnal would work for me. I haven't tried gournal yet either. My basic problem with just typing (which would probably be faster than handwriting for me as well) is that the notes I'd like to take are usually about 70-80% figures, which is hard to enter in the likes of lyx. But thank you again for the suggestions - you saved me a lot of googling!

[guyc]

Actually, no. There are two paths to no return value. Easy to fix though.

Method (_Q16, 0, NotSerialized)
                {
                    Store (QBBB, Local0)
                    If (LEqual (Local0, 0x00))
                    {
                        Store (QPDD, Local0)
                        ShiftRight (Local0, 0x02, Local0)
                        Add (Local0, 0x02, Local0)
                        If (LEqual (Local0, 0x01))
                        {
                            Notify (\_SB.QBTN, 0x80)
                        }

                        If (LEqual (Local0, 0x02))
                        {
                            Notify (\_SB.DBTN, 0x80)
                        }
                    }
                    Else
                    {
                        If (LEqual (Local0, 0x04))
                        {
                            Store (0x04, \_SB.WMID.Z010)
                            Store (0x00, \_SB.WMID.Z011)
                            Notify (\_SB.WMID, 0x80)
                            Return (0x00)
                        }

,,, Several similar if blocks...

                        Store (0x04, \_SB.WMID.Z010)
                        Store (0x00, \_SB.WMID.Z011)
                        Notify (\_SB.WMID, 0x80)
                    }
                }

Regarding the other warnings - the (apparently tired) programmer executes "And (CTRL, 0x1E)" as a statement. I can't help but think he was trying to set flags in CTRL rather than having no effect whatsoever.

[matth45]

Yes, you're absolutely right. QBBB could have had values other than those in the if/else block, so it could fail to execute a return. (I hadn't looked at it since July).

Have you checked out the F.18 bios? I haven't found a way to install it using dos or linux. They claim to have made bug fixes - I'm just curious what those might be.

Any idea how to tell what those registers refer to?

[guyc]

This code is from F.18. I get ACPI events and proper behavior for a lid close, which I saw someone complaining about in the Ubuntu forum, so possibly they fixed that... I don't remember whether it worked before I upgraded, which I did using my dual-booted Vista.

I tried using the ACPI documentation IBM provides to backtrack along the code and figure some things out, but didn't get very far with the time I had to invest. Also, it looks like some of the code refers directly to hardware addresses.