New VoodooPS2Controller, Keyboard, Trackpad (ClickPad support)

[RehabMan]

I have it set in BIOS to utilize normal mode, which requires pressing the Fn button to produce the media button scancodes (or a call to EC query, which is applicable to backlight control for both LVDS and keyboard).

So the problem occurs on the PS2 path. Key repeat on the PS2 path depends on OS X detecting that the key is held down. The driver generates events only when the key goes down (make) and when the key goes up (break). OS X, internally, creates a timer to cause the key to repeat. So, it seems there is some sort of trouble with this inside the OS X input system.

I'm not quite sure what is the SAVE method you are referencing, sorry.

PNLF.SAVE is called from ACPI backlight (if it exists) to save the backlight level in NVRAM. It is better than your current technique in that it will work also when you change the backlight level via SysPrefs->Displays.

Note: You'll have to let me know if it works. I've not implemented it on any of my machines, as I haven't bothered to figure out how to save the value to NVRAM from ACPI. In fact, I don't think my Lenovo has the capability, as it doesn't save on Windows either (the laptop always starts a full brightness). The ProBook can save its brightness level, and there I have it set to a value which is close to the value I usually use (the backlight level can be manipulated while in BIOS setup and it will be saved from there for future boots).

 

[TimeWalker]

It's better, but my current technique has other purpose .. I guess I will have to look into it before I say anything else.. I will make a note on the SAVE method though, but I don't recall ever changing backlight through the slider though
I have updated my previous post, it does indeed seem like the issue is on PS2/ADB side of things. The key sticks .. but I wonder why it works in short burst and then never works after ..

 

[RehabMan]

...
I have updated my previous post, it does indeed seem like the issue is on PS2/ADB side of things. The key sticks .. but I wonder why it works in short burst and then never works after ..

It is not that the key is "sticking". If it stuck down ('up' event never sent), it would be seen by the input system as "key still held down"/"endless repeat". Sounds to me more like the system is seeing a phantom "key up" event, and therefore is canceling the repeat timer.

Of course, you'd look entirely somewhere different if this was happening on the ACPI path (if I misunderstand your description of the situation). ACPI repeats are done by the EC itself. A key down and key up are generated with each call to an EC query (as that is how the Notifies are generally coded). We have to do it that way as generally an EC query is not generated separately for the key down vs. key up event (we get only the down, with automatic repeats, no EC query on up)

Further debugging/tracing would be necessary to see if anything funny is going on inside the driver. That is, you should trace all events being sent into the input system (set LogScanCodes to 2 "ioio -s ApplePS2Keyboard LogScanCodes 2") to see what is happening...

 

[TimeWalker]

Makes perfect sense, thank you for explanation. Will debug this tomorrow (Friday the 13th - perfect day to stay at home, hehe) and let you know what I find.

Meanwhile, though it may be off-topic here, but I'm totally sold for the SAVE method:

            Method (SAVE, 1, NotSerialized)
            {
                Store (Match (_BCL, MGE, Arg0, MTR, Zero, 0x02), Local0)
                Store (DerefOf (Index (_BCL, Local0)), \_SB.PCI0.IGPU.CBLV)
            }

Does wonders, compared to the clusterf of a code I was using previously!

 

[RehabMan]

Makes perfect sense, thank you for explanation. Will debug this tomorrow (Friday the 13th - perfect day to stay at home, hehe) and let you know what I find.

Meanwhile, though it may be off-topic here, but I'm totally sold for the SAVE method:

            Method (SAVE, 1, NotSerialized)
            {
                Store (Match (_BCL, MGE, Arg0, MTR, Zero, 0x02), Local0)
                Store (DerefOf (Index (_BCL, Local0)), \_SB.PCI0.IGPU.CBLV)
            }

Does wonders, compared to the clusterf of a code I was using previously!

In order for that to work, you'll have to make the sure the list of _BCL values matches what your BIOS expects (eg. is within the same min/max range). It all depends on whether the _BCL range matches the original _BCL range....

 

[TimeWalker]

In order for that to work, you'll have to make the sure the list of _BCL values matches what your BIOS expects (eg. is within the same min/max range). It all depends on whether the _BCL range matches the original _BCL range....

I have my _BCL matching the original backlight levels already, so all is fine there. It works exactly the same as it did before, but way cleaner!

// the range is set to comply with what windows sets - 6% to 90% with 6% increments, then 100%

Thanks for hinting about this!

 

[RehabMan]

I have my _BCL matching the original backlight levels already, so all is fine there. It works exactly the same as it did before, but way cleaner!

// the range is set to comply with what windows sets - 6% to 90% with 6% increments, then 100%

Thanks for hinting about this!

I figured, as it would be relatively obviously broken if that wasn't the case...

Note: With my current brightness patches, you can set LMAX to zero and it will scale the _BCL to the BIOS range.

Note 2: Officially off-topic now...

 

[TimeWalker]

ok, something really odd here in regards to the issue I was describing initially.
when I'm logged in, having the backlight control key pressed down doesn't do anything. it adjusts the level by one on key down and thats it. when I release the key the up event is generated:

2/13/15 7:03:50.000 PM kernel[0]: ApplePS2Keyboard: sending key 3e=e005, e005=91 down
2/13/15 7:03:58.000 PM kernel[0]: ApplePS2Keyboard: sending key 3e=e005, e005=91 up

HOWEVER! When i press sleep and interrupt it immediately sitting at the password input screen allows me to adjust the backlight all the way up or all the way down with a single press of F4/F5. after logging in using my password I loose the ability to do so. If I disable immediate password prompt from Security syspref I can't adjust the backlight across the entire range and it's the same thing as after I log in. I adjusted it all the way up sitting at the login screen, then kept the button pressed down even after screen has reached min brightness here:

2/13/15 7:07:20.000 PM kernel[0]: ApplePS2Keyboard: sending key 3f=e006, e006=90 down
2/13/15 7:07:23.000 PM kernel[0]: ApplePS2Keyboard: sending key 3f=e006, e006=90 up
2/13/15 7:07:23.000 PM kernel[0]: ApplePS2Keyboard: sending key 3e=e005, e005=91 down
2/13/15 7:07:28.000 PM kernel[0]: ApplePS2Keyboard: sending key 3e=e005, e005=91 up

What do we find? That for some reason at the login screen as well as occasionally in the system itself (while being logged in) the down action is generating continuous ADB code, which in hand leads to backlight adjustment across the entire range. Logically, this should be the case, because NX commands for sound adjustment supposedly works the same way, having the ability to adjust across the entire volume range?

 

[RehabMan]

ok, something really odd here in regards to the issue I was describing initially.
when I'm logged in, having the backlight control key pressed down doesn't do anything. it adjusts the level by one on key down and thats it. when I release the key the up event is generated:

2/13/15 7:03:50.000 PM kernel[0]: ApplePS2Keyboard: sending key 3e=e005, e005=91 down
2/13/15 7:03:58.000 PM kernel[0]: ApplePS2Keyboard: sending key 3e=e005, e005=91 up

HOWEVER! When i press sleep and interrupt it immediately sitting at the password input screen allows me to adjust the backlight all the way up or all the way down with a single press of F4/F5. after logging in using my password I loose the ability to do so. If I disable immediate password prompt from Security syspref I can't adjust the backlight across the entire range and it's the same thing as after I log in. I adjusted it all the way up sitting at the login screen, then kept the button pressed down even after screen has reached min brightness here:

2/13/15 7:07:20.000 PM kernel[0]: ApplePS2Keyboard: sending key 3f=e006, e006=90 down
2/13/15 7:07:23.000 PM kernel[0]: ApplePS2Keyboard: sending key 3f=e006, e006=90 up
2/13/15 7:07:23.000 PM kernel[0]: ApplePS2Keyboard: sending key 3e=e005, e005=91 down
2/13/15 7:07:28.000 PM kernel[0]: ApplePS2Keyboard: sending key 3e=e005, e005=91 up

What do we find? That for some reason at the login screen as well as occasionally in the system itself (while being logged in) the down action is generating continuous ADB code, which in hand leads to backlight adjustment across the entire range. Logically, this should be the case, because NX commands for sound adjustment supposedly works the same way, having the ability to adjust across the entire volume range?

Keep in mind the "Use all F1,F2..." option is a *user* preference. It does not take effect until you login. The default at the *initial* login screen is as if it was unchecked. After logging in, the real setting will take effect, and *will remain in effect* if you logout (it is a bug in OS X, IMHO).

You may be able to set a specific setting for it by logging in as 'root' and changing the option there. I've never tried it.

FWIW, I just tested brightness key repeat (both ACPI and PS2 path) at the login screen and after logged in on my Lenovo u430, and it all works as expected.

 

[TimeWalker]

Well, I'm actually relying on it being unchecked, as the mode I was trying to fix is the *special mode* .. which doesn't require Fn press.

Seems like it fixed it though .. Since I no longer need to run the original EC queries, because I've transplanted everything needed for NVRAM preservation (not really, but it's needed for BIOS init) into SAVE, I got rid of RKA1 and RKA2 and mapped F4 and F5 to regular e005 and e006 scancodes. I have restarted at least 4 times now and it does work as expected. So something about calling the ADB codes directly was off. I see you are doing it on your U430 though, so I'm definitely puzzled regardless..