[haiku-development] Re: Haiku development: getting involved
- From: Fredrik Holmqvist <fredrik.holmqvist@xxxxxxxxx>
- To: haiku-development <haiku-development@xxxxxxxxxxxxx>
- Date: Thu, 9 May 2013 14:33:23 +0200
2013/5/9 Vladimir Kovalev <maverik.mail@xxxxxxxxx>:
> Fredrik, can you please provide more information about what has been already
> done and about the task itself (if any), so I can quickly jump into it.
Ok here goes. It's not a task without challanges, so I understand if
it doesn't fit you.
we use ACPICA to call ACPI system so first thing is to read the ACPICA
specification[1] which describes the functions available.
Currently the driver builds and detects the prescence of functions for
display controls, check if (the '_DOS' acpi function) is available. So
it inits only if there are display functions. Everything else needs
implementation, and it is not added to the build at the moment. Here
are a summary of functions from the ACPI specifications[2] for 'ACPI
Extensions for Display Adapters':
_DOS Enable/Disable output switching Required if system supports
display switching
or LCD brightness levels
_DOD Enumerate all devices attached to display Required if integrated
controller supports
adapter output switching
_ROM Get ROM Data Required if ROM image is stored in
proprietary format
_GPD Get POST Device Required if _VPO is implemented
_SPD Set POST Device Required if _VPO is implemented
_VPO Video POST Options Required if system supports changing post
VGA device
_ADR Return the unique ID for this device Required
_BCL Query list of brightness control levels Required if embedded LCD supports
supported brightness control
_BCM Set the brightness level Required if _BCL is implemented
_DDC Return the EDID for this device Required if embedded LCD does not support
return of EDID via standard interface
_DCS Return status of output device Required if the system supports display
switching (via hotkey)
_DGS Query graphics state Required if the system supports display
switching (via hotkey
_DSS Device state set Required if the system supports display
switching (via hotkey).
The functions needed to complete a first working brightness driver is:
1. Enumerate displays. Maybe expose them as sub-devices, this needs
some recommendations from driver experts.
2. Implement the ACPI calls for brightness:
_BCL (Query List of Brightness Control Levels Supported)
Be prepared that the list returned may be broken, ie non numeric values.
_BCM (Set the Brightness Level)
_BQC (Brightness Query Current level)
3. Install notification handlers for the displays that has brightness functions.
First step would just be to detect and print that brightness keys are pressed.
Read the ACPICA spec for the functions to install notification handlers.
The notifications for brightness are:
0x85 Cycle Brightness. Used to notify OSPM that the output device
brightness should be increased by
one level. Used to notify OSPM that the user pressed a button or
key that is associated with cycling
brightness. A useful response by OSPM would be to increase output
device brightness by one or
more levels. (Levels are defined in _BCL.) If the brightness level
is currently at the maximum
value, it should be set to the minimum level.
0x86 Increase Brightness. Used to notify OSPM that the output device
brightness should be increased
by one or more levels as defined by the _BCL object. Used to
notify OSPM that the user pressed a
button or key that is associated with increasing brightness. If the
brightness level is currently at the
maximum value, OSPM may should ignore the notification.
Hewlett-Packard/Intel/Microsoft/Phoenix/Toshiba708 Advanced
Configuration and Power Interface Specification
Value Description
0x87 Decrease Brightness. Used to notify OSPM that the output device
brightness should be decreased
by one or more levels as defined by the _BCL object. Used to
notify OSPM that the user pressed a
button or key that is associated with decreasing device brightness.
If the brightness level is
currently at the minimum value, OSPM may should ignore the notification.
0x88 Zero Brightness. Used to notify OSPM that the output device
brightness should be zeroed,
effectively turning off any lighting that is associated with the
device. Used to notify OSPM that the
user pressed a button or key associated with zeroing device
brightness. This is not to be confused
with putting the device in a D3 state. While the brightness may be
decreased to zero, the device
may still be displaying, using only ambient light.
0x89 Display Device Off. Used to notify OSPM that the device should be
put in an off state, one that is
not active or visible to the user, usually D3, but possibly D1 or
D2. Used to notify OSPM that the
user pressed a low power button or key associated with putting the
device in an off state. There is
no need for a corresponding “device on” notification, for two
reasons. First, OSPM may choose to
toggle device state when this event is pressed multiple times.
Second, OSPM may (and probably
will) choose to turn the monitor on whenever the user types on the
keyboard, m
3. Call the brightness functions on notifications.
You can take a look at how FreeBSD driver does things:
http://fxr.watson.org/fxr/source/dev/acpica/acpi_video.c
[1] https://acpica.org/documentation
[2] http://www.acpi.info/spec.htm
/Fredrik Holmqvist, TQH
Other related posts:
