b/w reflective mode for monitor

[Mitch Bradley]

Andres Salomon wrote:
> Mitch Bradley wrote:
> [...]
>   
>> But there is a subterfuge that works.  The LEDs happen to be driven by
>> GPIO pins on the EC chip.  From the main CPU, you can control the EC
>> chip's GPIO pins.   If you turn off the "output enable" bit on the pin
>> that controls the power light, the light goes out.  It seems unlikely
>> that the EC firmware would notice that and turn it back on.  Most code
>> that deals with GPIOs sets up the basic configuration (enables, etc)
>> once, then subsequently use the "output value" bits to control the pins.
>>
>> You can demonstrate this from the firmware as follows:
>>
>>   ok  d5  fc11 ec!
>>
>> That is a brute force way; in practice you would want to read the value,
>> turn off the 02 bit, and write it back:
>>
>>   ok  fc11 ec@  2 invert and  fc11 ec!
>>
>> ec@ and ec! are shorthand Forth words that perform a little I/O port
>> dance to access internal EC chip registers - write 0xfc to I/O port
>> 0x381, write 0x11 to I/O port 0x382, then either read or write the value
>> at I/O port 0x383.
>>
>>
>>     
>
> That is all kinds of awesome.  Should I add it to the kernel LED driver?
>     It would be neat to be able to control the wireless LEDs as well.
>   

There is some question about whether this back door access to the EC 
GPIOs will last forever.  It is a security hole.  We are planning to 
turn it off at some point, providing explicit EC commands to do the 
functions that we need.  Perhaps control of the wireless LED should be 
added to the list of such functions.