Resguardo inicial

This commit is contained in:
lastdragon
2026-09-06 12:53:21 -06:00
parent 662efe3c2a
commit ad2088d178
94853 changed files with 43200404 additions and 0 deletions
@@ -0,0 +1,127 @@
.. SPDX-License-Identifier: GPL-2.0-or-later
====================
Alienware WMI Driver
====================
Kurt Borja <kuurtb@gmail.com>
This is a driver for the "WMAX" WMI device, which is found in most Dell gaming
laptops and controls various special features.
Before the launch of M-Series laptops (~2018), the "WMAX" device controlled
basic RGB lighting, deep sleep mode, HDMI mode and amplifier status.
Later, this device was completely repurpused. Now it mostly deals with thermal
profiles, sensor monitoring and overclocking. This interface is named "AWCC" and
is known to be used by the AWCC OEM application to control these features.
The alienware-wmi driver controls both interfaces.
AWCC Interface
==============
WMI device documentation: Documentation/wmi/devices/alienware-wmi.rst
Supported devices
-----------------
- Alienware M-Series laptops
- Alienware X-Series laptops
- Alienware Aurora Desktops
- Dell G-Series laptops
If you believe your device supports the AWCC interface and you don't have any of
the features described in this document, try the following alienware-wmi module
parameters:
- ``force_platform_profile=1``: Forces probing for platform profile support
- ``force_hwmon=1``: Forces probing for HWMON support
If the module loads successfully with these parameters, consider submitting a
patch adding your model to the ``awcc_dmi_table`` located in
``drivers/platform/x86/dell/alienware-wmi-wmax.c`` or contacting the maintainer
for further guidance.
Status
------
The following features are currently supported:
- :ref:`Platform Profile <platform-profile>`:
- Thermal profile control
- G-Mode toggling
- :ref:`HWMON <hwmon>`:
- Sensor monitoring
- Manual fan control
.. _platform-profile:
Platform Profile
----------------
The AWCC interface exposes various firmware defined thermal profiles. These are
exposed to user-space through the Platform Profile class interface. Refer to
:ref:`sysfs-class-platform-profile <abi_file_testing_sysfs_class_platform_profile>`
for more information.
The name of the platform-profile class device exported by this driver is
"alienware-wmi" and it's path can be found with:
::
grep -l "alienware-wmi" /sys/class/platform-profile/platform-profile-*/name | sed 's|/[^/]*$||'
If the device supports G-Mode, it is also toggled when selecting the
``performance`` profile.
.. note::
You may set the ``force_gmode`` module parameter to always try to toggle this
feature, without checking if your model supports it.
.. _hwmon:
HWMON
-----
The AWCC interface also supports sensor monitoring and manual fan control. Both
of these features are exposed to user-space through the HWMON interface.
The name of the hwmon class device exported by this driver is "alienware_wmi"
and it's path can be found with:
::
grep -l "alienware_wmi" /sys/class/hwmon/hwmon*/name | sed 's|/[^/]*$||'
Sensor monitoring is done through the standard HWMON interface. Refer to
:ref:`sysfs-class-hwmon <abi_file_testing_sysfs_class_hwmon>` for more
information.
Manual fan control on the other hand, is not exposed directly by the AWCC
interface. Instead it let's us control a fan `boost` value. This `boost` value
has the following approximate behavior over the fan pwm:
::
pwm = pwm_base + (fan_boost / 255) * (pwm_max - pwm_base)
Due to the above behavior, the fan `boost` control is exposed to user-space
through the following, custom hwmon sysfs attribute:
=============================== ======= =======================================
Name Perm Description
=============================== ======= =======================================
fan[1-4]_boost RW Fan boost value.
Integer value between 0 and 255
=============================== ======= =======================================
.. note::
In some devices, manual fan control only works reliably if the ``custom``
platform profile is selected.
@@ -0,0 +1,271 @@
==================
Asus Laptop Extras
==================
Version 0.1
August 6, 2009
Corentin Chary <corentincj@iksaif.net>
http://acpi4asus.sf.net/
This driver provides support for extra features of ACPI-compatible ASUS laptops.
It may also support some MEDION, JVC or VICTOR laptops (such as MEDION 9675 or
VICTOR XP7210 for example). It makes all the extra buttons generate input
events (like keyboards).
On some models adds support for changing the display brightness and output,
switching the LCD backlight on and off, and most importantly, allows you to
blink those fancy LEDs intended for reporting mail and wireless status.
This driver supersedes the old asus_acpi driver.
Requirements
------------
Kernel 2.6.X sources, configured for your computer, with ACPI support.
You also need CONFIG_INPUT and CONFIG_ACPI.
Status
------
The features currently supported are the following (see below for
detailed description):
- Fn key combinations
- Bluetooth enable and disable
- Wlan enable and disable
- GPS enable and disable
- Video output switching
- Ambient Light Sensor on and off
- LED control
- LED Display control
- LCD brightness control
- LCD on and off
A compatibility table by model and feature is maintained on the web
site, http://acpi4asus.sf.net/.
Usage
-----
Try "modprobe asus-laptop". Check your dmesg (simply type dmesg). You should
see some lines like this :
Asus Laptop Extras version 0.42
- L2D model detected.
If it is not the output you have on your laptop, send it (and the laptop's
DSDT) to me.
That's all, now, all the events generated by the hotkeys of your laptop
should be reported via netlink events. You can check with
"acpi_genl monitor" (part of the acpica project).
Hotkeys are also reported as input keys (like keyboards) you can check
which key are supported using "xev" under X11.
You can get information on the version of your DSDT table by reading the
/sys/devices/platform/asus-laptop/infos entry. If you have a question or a
bug report to do, please include the output of this entry.
LEDs
----
You can modify LEDs be echoing values to `/sys/class/leds/asus/*/brightness`::
echo 1 > /sys/class/leds/asus::mail/brightness
will switch the mail LED on.
You can also know if they are on/off by reading their content and use
kernel triggers like disk-activity or heartbeat.
Backlight
---------
You can control lcd backlight power and brightness with
/sys/class/backlight/asus-laptop/. Brightness Values are between 0 and 15.
Wireless devices
----------------
You can turn the internal Bluetooth adapter on/off with the bluetooth entry
(only on models with Bluetooth). This usually controls the associated LED.
Same for Wlan adapter.
Display switching
-----------------
Note: the display switching code is currently considered EXPERIMENTAL.
Switching works for the following models:
- L3800C
- A2500H
- L5800C
- M5200N
- W1000N (albeit with some glitches)
- M6700R
- A6JC
- F3J
Switching doesn't work for the following:
- M3700N
- L2X00D (locks the laptop under certain conditions)
To switch the displays, echo values from 0 to 15 to
/sys/devices/platform/asus-laptop/display. The significance of those values
is as follows:
+-------+-----+-----+-----+-----+-----+
| Bin | Val | DVI | TV | CRT | LCD |
+-------+-----+-----+-----+-----+-----+
| 0000 | 0 | | | | |
+-------+-----+-----+-----+-----+-----+
| 0001 | 1 | | | | X |
+-------+-----+-----+-----+-----+-----+
| 0010 | 2 | | | X | |
+-------+-----+-----+-----+-----+-----+
| 0011 | 3 | | | X | X |
+-------+-----+-----+-----+-----+-----+
| 0100 | 4 | | X | | |
+-------+-----+-----+-----+-----+-----+
| 0101 | 5 | | X | | X |
+-------+-----+-----+-----+-----+-----+
| 0110 | 6 | | X | X | |
+-------+-----+-----+-----+-----+-----+
| 0111 | 7 | | X | X | X |
+-------+-----+-----+-----+-----+-----+
| 1000 | 8 | X | | | |
+-------+-----+-----+-----+-----+-----+
| 1001 | 9 | X | | | X |
+-------+-----+-----+-----+-----+-----+
| 1010 | 10 | X | | X | |
+-------+-----+-----+-----+-----+-----+
| 1011 | 11 | X | | X | X |
+-------+-----+-----+-----+-----+-----+
| 1100 | 12 | X | X | | |
+-------+-----+-----+-----+-----+-----+
| 1101 | 13 | X | X | | X |
+-------+-----+-----+-----+-----+-----+
| 1110 | 14 | X | X | X | |
+-------+-----+-----+-----+-----+-----+
| 1111 | 15 | X | X | X | X |
+-------+-----+-----+-----+-----+-----+
In most cases, the appropriate displays must be plugged in for the above
combinations to work. TV-Out may need to be initialized at boot time.
Debugging:
1) Check whether the Fn+F8 key:
a) does not lock the laptop (try a boot with noapic / nolapic if it does)
b) generates events (0x6n, where n is the value corresponding to the
configuration above)
c) actually works
Record the disp value at every configuration.
2) Echo values from 0 to 15 to /sys/devices/platform/asus-laptop/display.
Record its value, note any change. If nothing changes, try a broader range,
up to 65535.
3) Send ANY output (both positive and negative reports are needed, unless your
machine is already listed above) to the acpi4asus-user mailing list.
Note: on some machines (e.g. L3C), after the module has been loaded, only 0x6n
events are generated and no actual switching occurs. In such a case, a line
like::
echo $((10#$arg-60)) > /sys/devices/platform/asus-laptop/display
will usually do the trick ($arg is the 0000006n-like event passed to acpid).
Note: there is currently no reliable way to read display status on xxN
(Centrino) models.
LED display
-----------
Some models like the W1N have a LED display that can be used to display
several items of information.
LED display works for the following models:
- W1000N
- W1J
To control the LED display, use the following::
echo 0x0T000DDD > /sys/devices/platform/asus-laptop/
where T control the 3 letters display, and DDD the 3 digits display,
according to the tables below::
DDD (digits)
000 to 999 = display digits
AAA = ---
BBB to FFF = turn-off
T (type)
0 = off
1 = dvd
2 = vcd
3 = mp3
4 = cd
5 = tv
6 = cpu
7 = vol
For example "echo 0x01000001 >/sys/devices/platform/asus-laptop/ledd"
would display "DVD001".
Driver options
--------------
Options can be passed to the asus-laptop driver using the standard
module argument syntax (<param>=<value> when passing the option to the
module or asus-laptop.<param>=<value> on the kernel boot line when
asus-laptop is statically linked into the kernel).
wapf: WAPF defines the behavior of the Fn+Fx wlan key
The significance of values is yet to be found, but
most of the time:
- 0x0 should do nothing
- 0x1 should allow to control the device with Fn+Fx key.
- 0x4 should send an ACPI event (0x88) while pressing the Fn+Fx key
- 0x5 like 0x1 or 0x4
The default value is 0x1.
Unsupported models
------------------
These models will never be supported by this module, as they use a completely
different mechanism to handle LEDs and extra stuff (meaning we have no clue
how it works):
- ASUS A1300 (A1B), A1370D
- ASUS L7300G
- ASUS L8400
Patches, Errors, Questions
--------------------------
I appreciate any success or failure
reports, especially if they add to or correct the compatibility table.
Please include the following information in your report:
- Asus model name
- a copy of your ACPI tables, using the "acpidump" utility
- a copy of /sys/devices/platform/asus-laptop/infos
- which driver features work and which don't
- the observed behavior of non-working features
Any other comments or patches are also more than welcome.
acpi4asus-user@lists.sourceforge.net
http://sourceforge.net/projects/acpi4asus
@@ -0,0 +1,151 @@
==========================
Hard disk shock protection
==========================
Author: Elias Oltmanns <eo@nebensachen.de>
Last modified: 2008-10-03
.. 0. Contents
1. Intro
2. The interface
3. References
4. CREDITS
1. Intro
--------
ATA/ATAPI-7 specifies the IDLE IMMEDIATE command with unload feature.
Issuing this command should cause the drive to switch to idle mode and
unload disk heads. This feature is being used in modern laptops in
conjunction with accelerometers and appropriate software to implement
a shock protection facility. The idea is to stop all I/O operations on
the internal hard drive and park its heads on the ramp when critical
situations are anticipated. The desire to have such a feature
available on GNU/Linux systems has been the original motivation to
implement a generic disk head parking interface in the Linux kernel.
Please note, however, that other components have to be set up on your
system in order to get disk shock protection working (see
section 3. References below for pointers to more information about
that).
2. The interface
----------------
For each ATA device, the kernel exports the file
`block/*/device/unload_heads` in sysfs (here assumed to be mounted under
/sys). Access to `/sys/block/*/device/unload_heads` is denied with
-EOPNOTSUPP if the device does not support the unload feature.
Otherwise, writing an integer value to this file will take the heads
of the respective drive off the platter and block all I/O operations
for the specified number of milliseconds. When the timeout expires and
no further disk head park request has been issued in the meantime,
normal operation will be resumed. The maximal value accepted for a
timeout is 30000 milliseconds. Exceeding this limit will return
-EOVERFLOW, but heads will be parked anyway and the timeout will be
set to 30 seconds. However, you can always change a timeout to any
value between 0 and 30000 by issuing a subsequent head park request
before the timeout of the previous one has expired. In particular, the
total timeout can exceed 30 seconds and, more importantly, you can
cancel a previously set timeout and resume normal operation
immediately by specifying a timeout of 0. Values below -2 are rejected
with -EINVAL (see below for the special meaning of -1 and -2). If the
timeout specified for a recent head park request has not yet expired,
reading from `/sys/block/*/device/unload_heads` will report the number
of milliseconds remaining until normal operation will be resumed;
otherwise, reading the unload_heads attribute will return 0.
For example, do the following in order to park the heads of drive
/dev/sda and stop all I/O operations for five seconds::
# echo 5000 > /sys/block/sda/device/unload_heads
A simple::
# cat /sys/block/sda/device/unload_heads
will show you how many milliseconds are left before normal operation
will be resumed.
A word of caution: The fact that the interface operates on a basis of
milliseconds may raise expectations that cannot be satisfied in
reality. In fact, the ATA specs clearly state that the time for an
unload operation to complete is vendor specific. The hint in ATA-7
that this will typically be within 500 milliseconds apparently has
been dropped in ATA-8.
There is a technical detail of this implementation that may cause some
confusion and should be discussed here. When a head park request has
been issued to a device successfully, all I/O operations on the
controller port this device is attached to will be deferred. That is
to say, any other device that may be connected to the same port will
be affected too. The only exception is that a subsequent head unload
request to that other device will be executed immediately. Further
operations on that port will be deferred until the timeout specified
for either device on the port has expired. As far as PATA (old style
IDE) configurations are concerned, there can only be two devices
attached to any single port. In SATA world we have port multipliers
which means that a user-issued head parking request to one device may
actually result in stopping I/O to a whole bunch of devices. However,
since this feature is supposed to be used on laptops and does not seem
to be very useful in any other environment, there will be mostly one
device per port. Even if the CD/DVD writer happens to be connected to
the same port as the hard drive, it generally *should* recover just
fine from the occasional buffer under-run incurred by a head park
request to the HD. Actually, when you are using an ide driver rather
than its libata counterpart (i.e. your disk is called /dev/hda
instead of /dev/sda), then parking the heads of one drive (drive X)
will generally not affect the mode of operation of another drive
(drive Y) on the same port as described above. It is only when a port
reset is required to recover from an exception on drive Y that further
I/O operations on that drive (and the reset itself) will be delayed
until drive X is no longer in the parked state.
Finally, there are some hard drives that only comply with an earlier
version of the ATA standard than ATA-7, but do support the unload
feature nonetheless. Unfortunately, there is no safe way Linux can
detect these devices, so you won't be able to write to the
unload_heads attribute. If you know that your device really does
support the unload feature (for instance, because the vendor of your
laptop or the hard drive itself told you so), then you can tell the
kernel to enable the usage of this feature for that drive by writing
the special value -1 to the unload_heads attribute::
# echo -1 > /sys/block/sda/device/unload_heads
will enable the feature for /dev/sda, and giving -2 instead of -1 will
disable it again.
3. References
-------------
There are several laptops from different vendors featuring shock
protection capabilities. As manufacturers have refused to support open
source development of the required software components so far, Linux
support for shock protection varies considerably between different
hardware implementations. Ideally, this section should contain a list
of pointers at different projects aiming at an implementation of shock
protection on different systems. Unfortunately, I only know of a
single project which, although still considered experimental, is fit
for use. Please feel free to add projects that have been the victims
of my ignorance.
- https://www.thinkwiki.org/wiki/HDAPS
See this page for information about Linux support of the hard disk
active protection system as implemented in IBM/Lenovo Thinkpads.
4. CREDITS
----------
This implementation of disk head parking has been inspired by a patch
originally published by Jon Escombe <lists@dresco.co.uk>. My efforts
to develop an implementation of this feature that is fit to be merged
into mainline have been aided by various kernel developers, in
particular by Tejun Heo and Bartlomiej Zolnierkiewicz.
@@ -0,0 +1,19 @@
.. SPDX-License-Identifier: GPL-2.0
==============
Laptop Drivers
==============
.. toctree::
:maxdepth: 1
alienware-wmi
asus-laptop
disk-shock-protection
lg-laptop
samsung-galaxybook
sony-laptop
sonypi
thinkpad-acpi
toshiba_haps
uniwill-laptop
@@ -0,0 +1,82 @@
.. SPDX-License-Identifier: GPL-2.0+
LG Gram laptop extra features
=============================
By Matan Ziv-Av <matan@svgalib.org>
Hotkeys
-------
The following FN keys are ignored by the kernel without this driver:
- FN-F1 (LG control panel) - Generates F15
- FN-F5 (Touchpad toggle) - Generates F21
- FN-F6 (Airplane mode) - Generates RFKILL
- FN-F9 (Reader mode) - Generates F14
The rest of the FN keys work without a need for a special driver.
Reader mode
-----------
Writing 0/1 to /sys/devices/platform/lg-laptop/reader_mode disables/enables
reader mode. In this mode the screen colors change (blue color reduced),
and the reader mode indicator LED (on F9 key) turns on.
FN Lock
-------
Writing 0/1 to /sys/devices/platform/lg-laptop/fn_lock disables/enables
FN lock.
Battery care limit
------------------
Writing 80/100 to /sys/class/power_supply/CMB0/charge_control_end_threshold
sets the maximum capacity to charge the battery. Limiting the charge
reduces battery capacity loss over time.
This value is reset to 100 when the kernel boots.
Fan mode
--------
Writing 0/1/2 to /sys/devices/platform/lg-laptop/fan_mode sets fan mode to
Optimal/Silent/Performance respectively.
USB charge
----------
Writing 0/1 to /sys/devices/platform/lg-laptop/usb_charge disables/enables
charging another device from the USB port while the device is turned off.
This value is reset to 0 when the kernel boots.
LEDs
~~~~
The are two LED devices supported by the driver:
Keyboard backlight
------------------
A led device named kbd_led controls the keyboard backlight. There are three
lighting level: off (0), low (127) and high (255).
The keyboard backlight is also controlled by the key combination FN-F8
which cycles through those levels.
Touchpad indicator LED
----------------------
On the F5 key. Controlled by led device names tpad_led.
@@ -0,0 +1,174 @@
.. SPDX-License-Identifier: GPL-2.0-or-later
==========================
Samsung Galaxy Book Driver
==========================
Joshua Grisham <josh@joshuagrisham.com>
This is a Linux x86 platform driver for Samsung Galaxy Book series notebook
devices which utilizes Samsung's ``SCAI`` ACPI device in order to control
extra features and receive various notifications.
Supported devices
=================
Any device with one of the supported ACPI device IDs should be supported. This
covers most of the "Samsung Galaxy Book" series notebooks that are currently
available as of this writing, and could include other Samsung notebook devices
as well.
Status
======
The following features are currently supported:
- :ref:`Keyboard backlight <keyboard-backlight>` control
- :ref:`Performance mode <performance-mode>` control implemented using the
platform profile interface
- :ref:`Battery charge control end threshold
<battery-charge-control-end-threshold>` (stop charging battery at given
percentage value) implemented as a battery hook
- :ref:`Firmware Attributes <firmware-attributes>` to allow control of various
device settings
- :ref:`Handling of Fn hotkeys <keyboard-hotkey-actions>` for various actions
- :ref:`Handling of ACPI notifications and hotkeys
<acpi-notifications-and-hotkey-actions>`
Because different models of these devices can vary in their features, there is
logic built within the driver which attempts to test each implemented feature
for a valid response before enabling its support (registering additional devices
or extensions, adding sysfs attributes, etc). Therefore, it can be important to
note that not all features may be supported for your particular device.
The following features might be possible to implement but will require
additional investigation and are therefore not supported at this time:
- "Dolby Atmos" mode for the speakers
- "Outdoor Mode" for increasing screen brightness on models with ``SAM0427``
- "Silent Mode" on models with ``SAM0427``
.. _keyboard-backlight:
Keyboard backlight
==================
A new LED class named ``samsung-galaxybook::kbd_backlight`` is created which
will then expose the device using the standard sysfs-based LED interface at
``/sys/class/leds/samsung-galaxybook::kbd_backlight``. Brightness can be
controlled by writing the desired value to the ``brightness`` sysfs attribute or
with any other desired userspace utility.
.. note::
Most of these devices have an ambient light sensor which also turns
off the keyboard backlight under well-lit conditions. This behavior does not
seem possible to control at this time, but can be good to be aware of.
.. _performance-mode:
Performance mode
================
This driver implements the
Documentation/userspace-api/sysfs-platform_profile.rst interface for working
with the "performance mode" function of the Samsung ACPI device.
Mapping of each Samsung "performance mode" to its respective platform profile is
performed dynamically by the driver, as not all models support all of the same
performance modes. Your device might have one or more of the following mappings:
- "Silent" maps to ``low-power``
- "Quiet" maps to ``quiet``
- "Optimized" maps to ``balanced``
- "High performance" maps to ``performance``
The result of the mapping can be printed in the kernel log when the module is
loaded. Supported profiles can also be retrieved from
``/sys/firmware/acpi/platform_profile_choices``, while
``/sys/firmware/acpi/platform_profile`` can be used to read or write the
currently selected profile.
The ``balanced`` platform profile will be set during module load if no profile
has been previously set.
.. _battery-charge-control-end-threshold:
Battery charge control end threshold
====================================
This platform driver will add the ability to set the battery's charge control
end threshold, but does not have the ability to set a start threshold.
This feature is typically called "Battery Saver" by the various Samsung
applications in Windows, but in Linux we have implemented the standardized
"charge control threshold" sysfs interface on the battery device to allow for
controlling this functionality from the userspace.
The sysfs attribute
``/sys/class/power_supply/BAT1/charge_control_end_threshold`` can be used to
read or set the desired charge end threshold.
If you wish to maintain interoperability with the Samsung Settings application
in Windows, then you should set the value to 100 to represent "off", or enable
the feature using only one of the following values: 50, 60, 70, 80, or 90.
Otherwise, the driver will accept any value between 1 and 100 as the percentage
that you wish the battery to stop charging at.
.. note::
Some devices have been observed as automatically "turning off" the charge
control end threshold if an input value of less than 30 is given.
.. _firmware-attributes:
Firmware Attributes
===================
The following enumeration-typed firmware attributes are set up by this driver
and should be accessible under
``/sys/class/firmware-attributes/samsung-galaxybook/attributes/`` if your device
supports them:
- ``power_on_lid_open`` (device should power on when the lid is opened)
- ``usb_charging`` (USB ports can deliver power to connected devices even when
the device is powered off or in a low sleep state)
- ``block_recording`` (blocks access to camera and microphone)
All of these attributes are simple boolean-like enumeration values which use 0
to represent "off" and 1 to represent "on". Use the ``current_value`` attribute
to get or change the setting on the device.
Note that when ``block_recording`` is updated, the input device "Samsung Galaxy
Book Lens Cover" will receive a ``SW_CAMERA_LENS_COVER`` switch event which
reflects the current state.
.. _keyboard-hotkey-actions:
Keyboard hotkey actions (i8042 filter)
======================================
The i8042 filter will swallow the keyboard events for the Fn+F9 hotkey (Multi-
level keyboard backlight toggle) and Fn+F10 hotkey (Block recording toggle)
and instead execute their actions within the driver itself.
Fn+F9 will cycle through the brightness levels of the keyboard backlight. A
notification will be sent using ``led_classdev_notify_brightness_hw_changed``
so that the userspace can be aware of the change. This mimics the behavior of
other existing devices where the brightness level is cycled internally by the
embedded controller and then reported via a notification.
Fn+F10 will toggle the value of the "block recording" setting, which blocks
or allows usage of the built-in camera and microphone (and generates the same
Lens Cover switch event mentioned above).
.. _acpi-notifications-and-hotkey-actions:
ACPI notifications and hotkey actions
=====================================
ACPI notifications will generate ACPI netlink events under the device class
``samsung-galaxybook`` and bus ID matching the Samsung ACPI device ID found on
your device. The events can be received using userspace tools such as
``acpi_listen`` and ``acpid``.
The Fn+F11 Performance mode hotkey will be handled by the driver; each keypress
will cycle to the next available platform profile.
@@ -0,0 +1,174 @@
=========================================
Sony Notebook Control Driver (SNC) Readme
=========================================
- Copyright (C) 2004- 2005 Stelian Pop <stelian@popies.net>
- Copyright (C) 2007 Mattia Dongili <malattia@linux.it>
This mini-driver drives the SNC and SPIC device present in the ACPI BIOS of the
Sony Vaio laptops. This driver mixes both devices functions under the same
(hopefully consistent) interface. This also means that the sonypi driver is
obsoleted by sony-laptop now.
Fn keys (hotkeys):
------------------
Some models report hotkeys through the SNC or SPIC devices, such events are
reported both through the ACPI subsystem as acpi events and through the INPUT
subsystem. See the logs of /proc/bus/input/devices to find out what those
events are and which input devices are created by the driver.
Additionally, loading the driver with the debug option will report all events
in the kernel log.
The "scancodes" passed to the input system (that can be remapped with udev)
are indexes to the table "sony_laptop_input_keycode_map" in the sony-laptop.c
module. For example the "FN/E" key combination (EJECTCD on some models)
generates the scancode 20 (0x14).
Backlight control:
------------------
If your laptop model supports it, you will find sysfs files in the
/sys/class/backlight/sony/
directory. You will be able to query and set the current screen
brightness:
====================== =========================================
brightness get/set screen brightness (an integer
between 0 and 7)
actual_brightness reading from this file will query the HW
to get real brightness value
max_brightness the maximum brightness value
====================== =========================================
Platform specific:
------------------
Loading the sony-laptop module will create a
/sys/devices/platform/sony-laptop/
directory populated with some files.
You then read/write integer values from/to those files by using
standard UNIX tools.
The files are:
====================== ==========================================
brightness_default screen brightness which will be set
when the laptop will be rebooted
cdpower power on/off the internal CD drive
audiopower power on/off the internal sound card
lanpower power on/off the internal ethernet card
(only in debug mode)
bluetoothpower power on/off the internal bluetooth device
fanspeed get/set the fan speed
====================== ==========================================
Note that some files may be missing if they are not supported
by your particular laptop model.
Example usage::
# echo "1" > /sys/devices/platform/sony-laptop/brightness_default
sets the lowest screen brightness for the next and later reboots
::
# echo "8" > /sys/devices/platform/sony-laptop/brightness_default
sets the highest screen brightness for the next and later reboots
::
# cat /sys/devices/platform/sony-laptop/brightness_default
retrieves the value
::
# echo "0" > /sys/devices/platform/sony-laptop/audiopower
powers off the sound card
::
# echo "1" > /sys/devices/platform/sony-laptop/audiopower
powers on the sound card.
RFkill control:
---------------
More recent Vaio models expose a consistent set of ACPI methods to
control radio frequency emitting devices. If you are a lucky owner of
such a laptop you will find the necessary rfkill devices under
/sys/class/rfkill. Check those starting with sony-* in::
# grep . /sys/class/rfkill/*/{state,name}
Development:
------------
If you want to help with the development of this driver (and
you are not afraid of any side effects doing strange things with
your ACPI BIOS could have on your laptop), load the driver and
pass the option 'debug=1'.
REPEAT:
**DON'T DO THIS IF YOU DON'T LIKE RISKY BUSINESS.**
In your kernel logs you will find the list of all ACPI methods
the SNC device has on your laptop.
* For new models you will see a long list of meaningless method names,
reading the DSDT table source should reveal that:
(1) the SNC device uses an internal capability lookup table
(2) SN00 is used to find values in the lookup table
(3) SN06 and SN07 are used to call into the real methods based on
offsets you can obtain iterating the table using SN00
(4) SN02 used to enable events.
Some values in the capability lookup table are more or less known, see
the code for all sony_call_snc_handle calls, others are more obscure.
* For old models you can see the GCDP/GCDP methods used to pwer on/off
the CD drive, but there are others and they are usually different from
model to model.
**I HAVE NO IDEA WHAT THOSE METHODS DO.**
The sony-laptop driver creates, for some of those methods (the most
current ones found on several Vaio models), an entry under
/sys/devices/platform/sony-laptop, just like the 'cdpower' one.
You can create other entries corresponding to your own laptop methods by
further editing the source (see the 'sony_nc_values' table, and add a new
entry to this table with your get/set method names using the
SNC_HANDLE_NAMES macro).
Your mission, should you accept it, is to try finding out what
those entries are for, by reading/writing random values from/to those
files and find out what is the impact on your laptop.
Should you find anything interesting, please report it back to me,
I will not disavow all knowledge of your actions :)
See also http://www.linux.it/~malattia/wiki/index.php/Sony_drivers for other
useful info.
Bugs/Limitations:
-----------------
* This driver is not based on official documentation from Sony
(because there is none), so there is no guarantee this driver
will work at all, or do the right thing. Although this hasn't
happened to me, this driver could do very bad things to your
laptop, including permanent damage.
* The sony-laptop and sonypi drivers do not interact at all. In the
future, sonypi will be removed and replaced by sony-laptop.
* spicctrl, which is the userspace tool used to communicate with the
sonypi driver (through /dev/sonypi) is deprecated as well since all
its features are now available under the sysfs tree via sony-laptop.
@@ -0,0 +1,158 @@
==================================================
Sony Programmable I/O Control Device Driver Readme
==================================================
- Copyright (C) 2001-2004 Stelian Pop <stelian@popies.net>
- Copyright (C) 2001-2002 Alcôve <www.alcove.com>
- Copyright (C) 2001 Michael Ashley <m.ashley@unsw.edu.au>
- Copyright (C) 2001 Junichi Morita <jun1m@mars.dti.ne.jp>
- Copyright (C) 2000 Takaya Kinjo <t-kinjo@tc4.so-net.ne.jp>
- Copyright (C) 2000 Andrew Tridgell <tridge@samba.org>
This driver enables access to the Sony Programmable I/O Control Device which
can be found in many Sony Vaio laptops. Some newer Sony laptops (seems to be
limited to new FX series laptops, at least the FX501 and the FX702) lack a
sonypi device and are not supported at all by this driver.
It will give access (through a user space utility) to some events those laptops
generate, like:
- jogdial events (the small wheel on the side of Vaios)
- capture button events (only on Vaio Picturebook series)
- Fn keys
- bluetooth button (only on C1VR model)
- programmable keys, back, help, zoom, thumbphrase buttons, etc.
(when available)
Those events (see linux/sonypi.h) can be polled using the character device node
/dev/sonypi (major 10, minor auto allocated or specified as an option).
A simple daemon which translates the jogdial movements into mouse wheel events
can be downloaded at: <http://popies.net/sonypi/>
Another option to intercept the events is to get them directly through the
input layer.
This driver supports also some ioctl commands for setting the LCD screen
brightness and querying the batteries charge information (some more
commands may be added in the future).
This driver can also be used to set the camera controls on Picturebook series
(brightness, contrast etc), and is used by the video4linux driver for the
Motion Eye camera.
Please note that this driver was created by reverse engineering the Windows
driver and the ACPI BIOS, because Sony doesn't agree to release any programming
specs for its laptops. If someone convinces them to do so, drop me a note.
Driver options:
---------------
Several options can be passed to the sonypi driver using the standard
module argument syntax (<param>=<value> when passing the option to the
module or sonypi.<param>=<value> on the kernel boot line when sonypi is
statically linked into the kernel). Those options are:
=============== =======================================================
minor: minor number of the misc device /dev/sonypi,
default is -1 (automatic allocation, see /proc/misc
or kernel logs)
camera: if you have a PictureBook series Vaio (with the
integrated MotionEye camera), set this parameter to 1
in order to let the driver access to the camera
fnkeyinit: on some Vaios (C1VE, C1VR etc), the Fn key events don't
get enabled unless you set this parameter to 1.
Do not use this option unless it's actually necessary,
some Vaio models don't deal well with this option.
This option is available only if the kernel is
compiled without ACPI support (since it conflicts
with it and it shouldn't be required anyway if
ACPI is already enabled).
verbose: set to 1 to print unknown events received from the
sonypi device.
set to 2 to print all events received from the
sonypi device.
compat: uses some compatibility code for enabling the sonypi
events. If the driver worked for you in the past
(prior to version 1.5) and does not work anymore,
add this option and report to the author.
mask: event mask telling the driver what events will be
reported to the user. This parameter is required for
some Vaio models where the hardware reuses values
used in other Vaio models (like the FX series who does
not have a jogdial but reuses the jogdial events for
programmable keys events). The default event mask is
set to 0xffffffff, meaning that all possible events
will be tried. You can use the following bits to
construct your own event mask (from
include/linux/sonypi.h)::
SONYPI_JOGGER_MASK 0x0001
SONYPI_CAPTURE_MASK 0x0002
SONYPI_FNKEY_MASK 0x0004
SONYPI_BLUETOOTH_MASK 0x0008
SONYPI_PKEY_MASK 0x0010
SONYPI_BACK_MASK 0x0020
SONYPI_HELP_MASK 0x0040
SONYPI_LID_MASK 0x0080
SONYPI_ZOOM_MASK 0x0100
SONYPI_THUMBPHRASE_MASK 0x0200
SONYPI_MEYE_MASK 0x0400
SONYPI_MEMORYSTICK_MASK 0x0800
SONYPI_BATTERY_MASK 0x1000
SONYPI_WIRELESS_MASK 0x2000
useinput: if set (which is the default) two input devices are
created, one which interprets the jogdial events as
mouse events, the other one which acts like a
keyboard reporting the pressing of the special keys.
=============== =======================================================
Module use:
-----------
In order to automatically load the sonypi module on use, you can put those
lines a configuration file in /etc/modprobe.d/::
alias char-major-10-250 sonypi
options sonypi minor=250
This supposes the use of minor 250 for the sonypi device::
# mknod /dev/sonypi c 10 250
Bugs:
-----
- several users reported that this driver disables the BIOS-managed
Fn-keys which put the laptop in sleeping state, or switch the
external monitor on/off. There is no workaround yet, since this
driver disables all APM management for those keys, by enabling the
ACPI management (and the ACPI core stuff is not complete yet). If
you have one of those laptops with working Fn keys and want to
continue to use them, don't use this driver.
- some users reported that the laptop speed is lower (dhrystone
tested) when using the driver with the fnkeyinit parameter. I cannot
reproduce it on my laptop and not all users have this problem.
This happens because the fnkeyinit parameter enables the ACPI
mode (but without additional ACPI control, like processor
speed handling etc). Use ACPI instead of APM if it works on your
laptop.
- sonypi lacks the ability to distinguish between certain key
events on some models.
- some models with the nvidia card (geforce go 6200 tc) uses a
different way to adjust the backlighting of the screen. There
is a userspace utility to adjust the brightness on those models,
which can be downloaded from
https://www.acc.umu.se/~erikw/program/smartdimmer-0.1.tar.bz2
- since all development was done by reverse engineering, there is
*absolutely no guarantee* that this driver will not crash your
laptop. Permanently.
File diff suppressed because it is too large Load Diff
@@ -0,0 +1,87 @@
====================================
Toshiba HDD Active Protection Sensor
====================================
Kernel driver: toshiba_haps
Author: Azael Avalos <coproscefalo@gmail.com>
.. 0. Contents
1. Description
2. Interface
3. Accelerometer axes
4. Supported devices
5. Usage
1. Description
--------------
This driver provides support for the accelerometer found in various Toshiba
laptops, being called "Toshiba HDD Protection - Shock Sensor" officially,
and detects laptops automatically with this device.
On Windows, Toshiba provided software monitors this device and provides
automatic HDD protection (head unload) on sudden moves or harsh vibrations,
however, this driver only provides a notification via a sysfs file to let
userspace tools or daemons act accordingly, as well as providing a sysfs
file to set the desired protection level or sensor sensibility.
2. Interface
------------
This device comes with 3 methods:
==== =====================================================================
_STA Checks existence of the device, returning Zero if the device does not
exists or is not supported.
PTLV Sets the desired protection level.
RSSS Shuts down the HDD protection interface for a few seconds,
then restores normal operation.
==== =====================================================================
Note:
The presence of Solid State Drives (SSD) can cause this driver to fail loading,
given the fact that such drives have no movable parts, and thus, not requiring
any "protection" as well as failing during the evaluation of the _STA method
found under this device.
3. Accelerometer axes
---------------------
This device does not report any axes, however, to query the sensor position
a couple HCI (Hardware Configuration Interface) calls (0x6D and 0xA6) are
provided to query such information, handled by the kernel module toshiba_acpi
since kernel version 3.15.
4. Supported devices
--------------------
This driver binds itself to the ACPI device TOS620A, and any Toshiba laptop
with this device is supported, given the fact that they have the presence of
conventional HDD and not only SSD, or a combination of both HDD and SSD.
5. Usage
--------
The sysfs files under /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS620A:00/ are:
================ ============================================================
protection_level The protection_level is readable and writeable, and
provides a way to let userspace query the current protection
level, as well as set the desired protection level, the
available protection levels are::
============ ======= ========== ========
0 - Disabled 1 - Low 2 - Medium 3 - High
============ ======= ========== ========
reset_protection The reset_protection entry is writeable only, being "1"
the only parameter it accepts, it is used to trigger
a reset of the protection interface.
================ ============================================================
@@ -0,0 +1,91 @@
.. SPDX-License-Identifier: GPL-2.0+
Uniwill laptop extra features
=============================
On laptops manufactured by Uniwill (either directly or as ODM), the ``uniwill-laptop`` driver
handles various platform-specific features.
Module Loading
--------------
The ``uniwill-laptop`` driver relies on a DMI table to automatically load on supported devices.
When using the ``force`` module parameter, this DMI check will be omitted, allowing the driver
to be loaded on unsupported devices for testing purposes.
Hotkeys
-------
Usually the FN keys work without a special driver. However as soon as the ``uniwill-laptop`` driver
is loaded, the FN keys need to be handled manually. This is done automatically by the driver itself.
Keyboard settings
-----------------
The ``uniwill-laptop`` driver allows the user to enable/disable:
- the FN lock and super key of the integrated keyboard
- the touchpad toggle functionality of the integrated touchpad
See Documentation/ABI/testing/sysfs-driver-uniwill-laptop for details.
Hwmon interface
---------------
The ``uniwill-laptop`` driver supports reading of the CPU and GPU temperature and supports up to
two fans. Userspace applications can access sensor readings over the hwmon sysfs interface.
Platform profile
----------------
Support for changing the platform performance mode is currently not implemented.
Battery Charging Control
------------------------
.. warning:: Some devices do not properly implement the charging threshold interface. Forcing
the driver to enable access to said interface on such devices might damage the
battery [1]_. Because of this the driver will not enable said feature even when
using the ``force`` module parameter. The charging profile interface will be
available instead.
The ``uniwill-laptop`` driver supports controlling the battery charge limit. This either happens
over the standard ``charge_control_end_threshold`` or ``charge_types`` power supply sysfs attribute,
depending on the device. When using the ``charge_control_end_threshold`` sysfs attribute, all values
between 1 and 100 percent are supported. When using the ``charge_types`` sysfs attribute, the driver
supports switching between the ``Standard``, ``Trickle`` and ``Long Life`` profiles.
Keep in mind that when using the ``charge_types`` sysfs attribute, the EC firmware will hide the
true charging status of the battery from the operating system, potentially misleading users into
thinking that the charging profile does not work. Checking the ``current_now`` sysfs attribute
tells you the true charging status of the battery even when using the ``charge_types`` sysfs
attribute (0 means that the battery is currently not charging).
Additionally the driver signals the presence of battery charging issues through the standard
``health`` power supply sysfs attribute.
It also lets you set whether a USB-C power source should prioritise charging the battery or
delivering immediate power to the cpu. See Documentation/ABI/testing/sysfs-driver-uniwill-laptop for
details.
Lightbar
--------
The ``uniwill-laptop`` driver exposes the lightbar found on some models as a standard multicolor
LED class device. The default name of this LED class device is ``uniwill:multicolor:status``.
See Documentation/ABI/testing/sysfs-driver-uniwill-laptop for details on how to control the various
animation modes of the lightbar.
Configurable TGP
----------------
The ``uniwill-laptop`` driver allows to set the configurable TGP for devices with NVIDIA GPUs that
allow it.
See Documentation/ABI/testing/sysfs-driver-uniwill-laptop for details.
References
==========
.. [1] https://www.reddit.com/r/XMG_gg/comments/ld9yyf/battery_limit_hidden_function_discovered_on/