IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This commit adds a rules file to extract the properties from hwdb
to set on i2c IIO devices. This is used to set the ACCEL_MOUNT_MATRIX
property on IIO devices, to be consumed by iio-sensor-proxy or
equivalent daemon.
The hwdb file contains documentation on how to write quirks. Note
however that mount information is usually exported in:
- the device-tree for ARM devices
- the ACPI DSDT for Intel-compatible devices
but currently not extracted by the kernel.
Also note that some devices have the framebuffer rotation that changes
between the bootloader and the main system, which might mean that the
accelerometer is then wrongly oriented. This is a missing feature in the
i915 kernel driver: https://bugs.freedesktop.org/show_bug.cgi?id=94894
which needs to be fixed, and won't require quirks.
Evidently this code path was never hit, because we'd crash with NameError.
The exception message also seems bogus. So just replace the whole thing
with the standard exception for invalid input.
Yubikeys and other pseudo keyboards require that they are in the US layout,
otherwise the data they send is invalid. Add two new keys to signal this to
processes that handles (XKB) layouts.
pyparsing uses the system locale by default, which in the case of 'C' (in lots
of build environment) will fail with a UnicodeDecodeError. Explicitly open it
with UTF-8 encoding to guard against this.
pyparsing 2.1.10 fixed the handling of LineStart to really just apply to line
starts and not ignore whitespace and comments any more. Adjust EMPTYLINE to
this.
Many thanks to Paul McGuire for pointing this out!
pyparsing uses the system locale by default, which in the case of 'C' (in lots
of build environment) will fail with a UnicodeDecodeError. Explicitly open it
with UTF-8 encoding to guard against this.
Add MSI VR420 (model MS-1422) to the list of MSI models which need to
ignore brightness hotkey presses, as these are already reported through
the acpi-video interface.
Bug-link: https://bugzilla.redhat.com/show_bug.cgi?id=1270124
Reported-by: David Dreggors <dadreggors@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
MOUSE_WHEEL_CLICK_ANGLE has been an integer, and at least libinput (probably
the only user) parses it as strict integer. For backwards compatibility, we
cannot change it to a decimal number now.
Add a new property to list the number of clicks for a full 360 degree
rotation, to be specified in addition to the old click angle property. Clients
can prefer the new one where available and calculate the decimal value to
whatever precision they want.
Like the Inspiron 1520, the Dell Latitude 2110 emits brightness-control
key events both through atkbd and acpi-video. This suppresses them on
the atkbd side.
This parser will also be used in libinput, which uses the MIT license, so
relicense this file to the more permissive license to make bidirectional code
flow easier. parse_hwdb.py is only useful during building of the project, and
is not part of the installation, so effectively both licenses are very similar.
In particular, the licensing of binary packages produced by systemd is not
influenced in any way, because the MIT licensed part is not installed.
Like many other recent thinkpads the factory default pointingstick
sensitivity on these devices is quite low, making the pointingstick
very slow in moving the cursor.
This extends the existing hwdb rules for tweaking the sensitivity to
also apply to the X1 Tablet models.
Signed-off-by: Dennis Wassenberg <dennis.wassenberg@secunet.com>
The Logitech MX Master has a horizontal scroll wheel with a different click
angle than the vertical one. Add a new property for this case, we can't add
values to the normal one without risking upsetting existing parsers.
Fixes#3947
It's hard to say which one of the two mappings should stay. But the later
one would win (when both very present), and nobody complained, so let's
assume that that's the one.
This works for hwdb/[67]0-*.hwdb. I also added code to parse hwdb/20-*, but those
files are huge, and parsing them using this parser is annoyingly slow (about one
minute for the biggest files). So I removed the support for hwdb/20-*, a much simpler
hand-generated parser should suffice for those.
Current output:
hwdb/60-evdev.hwdb: 24 match groups, 35 matches, 88 properties, 0.19323015213012695s to parse
Match 'evdev:input:b0003v05ACp0259*' is duplicated
Match 'evdev:input:b0003v05ACp025A*' is duplicated
Match 'evdev:input:b0003v05ACp025B*' is duplicated
hwdb/60-keyboard.hwdb: 122 match groups, 188 matches, 638 properties, 1.0906572341918945s to parse
Failed to parse: 'KEYBOARD_KEY_8F=switchvideomode'
Failed to parse: 'KEYBOARD_KEY_C0183=media'
Failed to parse: 'KEYBOARD_KEY_C0201=new'
Failed to parse: 'KEYBOARD_KEY_C0289=reply'
Failed to parse: 'KEYBOARD_KEY_C028B=forwardmail'
Failed to parse: 'KEYBOARD_KEY_C028C=send'
Failed to parse: 'KEYBOARD_KEY_C021A=undo'
Failed to parse: 'KEYBOARD_KEY_C0279=redo'
Failed to parse: 'KEYBOARD_KEY_C0208=print'
Failed to parse: 'KEYBOARD_KEY_C0207=save'
Failed to parse: 'KEYBOARD_KEY_C0194=file'
Failed to parse: 'KEYBOARD_KEY_C01A7=documents'
Failed to parse: 'KEYBOARD_KEY_C01B6=images'
Failed to parse: 'KEYBOARD_KEY_C01B7=sound'
Property KEYBOARD_KEY_c7 is duplicated
Failed to parse: 'KEYBOARD_KEY_cF=end'
hwdb/70-mouse.hwdb: 62 match groups, 93 matches, 68 properties, 0.34186625480651855s to parse
Match 'mouse:usb:v046dpc51b:name:Logitech USB Receiver:' is duplicated
hwdb/70-pointingstick.hwdb: 5 match groups, 14 matches, 7 properties, 0.06518816947937012s to parse
hwdb/70-touchpad.hwdb: 3 match groups, 5 matches, 3 properties, 0.039690494537353516s to parse
Subsequest commits will clean those issues up.
This way it's clear that the property block does not end at the comment.
The python checker will complain if this is not the case.
We had a few bugs before where two match blocks were merged by mistake,
and this change should help avoid that.
Whether a device is a trackball or not is a physical property so we should
store this globally, in one place. The new property must be set in addition to
ID_INPUT_MOUSE, otherwise existing clients won't detect the device.
No actual code changes required, the default match rule is simply checking for
"Trackball" in the name (in a few versions), other entries need to be added
manually.
Like many other recent thinkpads the factory default pointingstick
sensitivity on these devices is quite low, making the pointingstick
very slow in moving the cursor.
This extends the existing hwdb rules for tweaking the sensitivity to
also apply to the X260 models.
Like many other recent thinkpads the factory default pointingstick
sensitivity on these devices is quite low, making the pointingstick
very slow in moving the cursor.
This extends the existing hwdb rules for tweaking the sensitivity to
also apply to the T560 models.
Like many other recent thinkpads the factory default pointingstick
sensitivity on these devices is quite low, making the pointingstick
very slow in moving the cursor.
This extends the existing hwdb rules for tweaking the sensitivity to
also apply to the T460s models.
Like many other recent thinkpads the factory default pointingstick
sensitivity on these devices is quite low, making the pointingstick
very slow in moving the cursor.
This extends the existing hwdb rules for tweaking the sensitivity to
also apply to the L460 models.
Like many other recent thinkpads the factory default pointingstick
sensitivity on these devices is quite low, making the pointingstick
very slow in moving the cursor.
This extends the existing hwdb rules for tweaking the sensitivity to
also apply to the X250 models.
Like many other recent thinkpads the factory default pointingstick
sensitivity on these devices is quite low, making the pointingstick
very slow in moving the cursor.
This extends the existing hwdb rules for tweaking the sensitivity to
also apply to the T450s models.
Like many other recent thinkpads the factory default pointingstick
sensitivity on these devices is quite low, making the pointingstick
very slow in moving the cursor.
This extends the existing hwdb rules for tweaking the sensitivity to
also apply to the L450 models.
Like many other recent thinkpads the factory default pointingstick
sensitivity on these devices is quite low, making the pointingstick
very slow in moving the cursor.
This extends the existing hwdb rules for tweaking the sensitivity to
also apply to the T440p models.
Add a new key ID_INPUT_TOUCHPAD_INTEGRATION=internal|external so we have a
single source for figuring out which touchpads are built-in.
Fairly simple approach: bluetooth is external, usb is external unless it's an
Apple touchpad. Everything else is internal.
Let's hook up the ACPI database we maintain from the upstream UEFI sources.
This adds a tool to convert the database provided upstream to our native
format, similar to how this is handled for the PCI and USB databases.
Note that the upstream web site claims to offer an XLS download, but the actual
data made available is an HTML file in reality, just one with the ".xls"
suffix...
The data provided from the UEFI folks is not very high quality nor complete,
hence apply a patch after the conversion step that fixes up a few things and
adds in more entries from various sources. For example, the EDID ids maintained
by GNOME and other sources have been added too, as they all appear to use the
same ID namespace.
This also adds explicit support for 4 character ACPI ids, in addition to the
normal 3 character PNP ids.
Also fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=90524
Like many other recent thinkpads the factory default pointingstick
sensitivity on these devices is quite low, making the pointingstick
very slow in moving the cursor.
This extends the existing hwdb rules for tweaking the sensitivity to
also apply to the X1 carbon 4thgen model.
Apparently the vendor string for newer models now uses "svnHP" instead of
"svnHewlett-Packard", so add this alternative match to the global HP map.
Generalize matches for micmute key on ProBook 4xx.
Silence two hardwired keys on the ProBook 440 G3 that should not produce evdev
events. Thanks to Hermann Kraus for those! (See PR #2679)
This Lenovo machine use codec Line2 to implement a microphone mute
button, it depends on the unsolicited interrupt to generate key event,
the scan code for this button is assigned to 0x00 in the linux kernel
driver, and the keycode is KEY_MICMUTE(248), we need to remap this
keycode to KEY_F20 to make this hotkey work in X11.
BugLink: https://bugs.launchpad.net/bugs/1531362
Signed-off-by: Hui Wang <hui.wang@canonical.com>
The Yoga's firmware sends key events whenever it's being folded or unfolded.
These are thus *not* a button for requesting a screen orientation change, just
an indication that this already happened. Thus they should not be assigned to
"direction", but be ignored. Assigning them to "reserved" does not silence the
"unknown key pressed" kernel warning, so there's no point in maintaining a
mapping here.
Fixes#1440
This breaks the same vendor/product ID with the German keyboard layout. As this
is a hack around some weird keyboard driver bug, let's revert until this is
understood better.
See https://github.com/systemd/systemd/issues/1243
This reverts commit a2aa71a954.
Like many other recent thinkpads the factory default pointingstick
sensitivity on these devices is quite low, making the pointingstick
very slow in moving the cursor.
This extends the existing hwdb rules for tweaking the sensitivity to
also apply to the X1 carbon 3rd gen model.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1200717
Like many other recent thinkpads the factory default pointingstick
sensitivity on these devices is quite low, making the pointingstick
very slow in moving the cursor.
This extends the existing hwdb rules for tweaking the sensitivity to
also apply to the T550 / W550s models.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1200717
The main purpose of this hwdb was to tag touchpads that have the physical
trackstick buttons wired to the touchpad (Lenovo Carbon X1 3rd, Lenovo *50
series). This hwdb is not required on kernels 4.0 and above, the kernel now
re-routes button presses through the trackstick's device node. Userspace does
not need to do anything.
See kernel commit cdd9dc195916ef5644cfac079094c3c1d1616e4c.
This reverts commit 001a247324.
Unplugging and plugging in the cable will create various scancodes
on the keyboard controller.
Userspace within X should be able to interact with these to show
interesting messages. Assign them to generic prog1/prog2.
(David: add comment to hwdb explaining that these keycodes are reserved)
Like the T440s these need the sensitity to be set significantly higher
then the default of 128 for the trackpoint to be usable. Like with the
T440s 200 seems to be a good value to get a reasonable but not too high
sensitivity.
The atmel driver sets a default resolution of 20 for each touchpads it
creates. On this model, 10 is more appropriate.
The resolution is not set for the touchscreen by the kernel, so match
the name to both touchpad and touchscreen.
The Lenovo X230 advertize a vertical resolution of 136, which gives a true
size of 31 mm. The actual physical size of the touchpad is 40 mm, so
override the resolution to 100.
The pointingstick of the Dell Latitude E6400 is somewhat slow by default,
whereas the pointingstick of the Dell Latitude D620 is much too fast by
default, set POINTINGSTICK_CONST_ACCEL for both of them to adjust for this.
Lenovo has changed the sensitivity of the trackpoint on the x240 / T440s / T540
generation of Thinkpads, making them somewhat insensitive by default, add a
hwdb entry to tweak the sensitivity setting.
The ThinkPad X200s is way way too slow by default and unless you push the
trackpoint quite hard only sends delta events in the 1-2 range, tweak the
sensitivity to make it send a wider range of deltas and apply a const accel
factor to make it have a more reasonable speed by default.
IBM / Lenovo trackpoints allow specifying a sensitivity setting through a
ps/2 command, which changes the range of the deltas sent when using the
trackpoint.
On some models with normal usage only deltas of 1 or 2 are send, resulting in
there only being 2 mouse cursor movement speeds, rather than the expected fluid
scale. Changing the sensitivity to a higher level than the bootup default fixes
this.
This commit adds support for setting a POINTINGSTICK_SENSITIVITY value
in hwdb to allow changing the sensitivity on boot through udev / hwdb.
There is quite a wide spread in the delta events generated by pointingsticks,
some generate deltas of 1-2 under normal use, while others generate deltas
from 1-20.
This commit adds a hwdb file which allows specifying a per model
POINTINGSTICK_CONST_ACCEL value which can be used by the userspace input stack
to normalize the deltas so that all pointingsticks get the same feeling ootb.
The hwdb matching re-uses the existing 60-evdev.rules.
Verified for the 5,1 Macbook, the others are guesses based on the list of
supported devices of the moshi trackpad protector.
http://www.moshi.com/trackpad-protector-trackguard-macbook-pro#silver
Resolution calculated based on the min/max settings set in the kernel driver,
divided by the physical size. This is probably slightly off, but still better
than no resolution at all.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Parse properties in the form
EVDEV_ABS_00="<min>:<max>:<res>:<fuzz>:<flat>"
and apply them to the kernel device. Future processes that open that device
will see the updated EV_ABS range.
This is particularly useful for touchpads that don't provide a resolution in
the kernel driver but can be fixed up through hwdb entries (e.g. bcm5974).
All values in the property are optional, e.g. a string of "::45" is valid to
set the resolution to 45.
The order intentionally orders resolution before fuzz and flat despite it
being the last element in the absinfo struct. The use-case for setting
fuzz/flat is almost non-existent, resolution is probably the most common case
we'll need.
To avoid multiple hwdb invocations for the same device, replace the
hwdb "keyboard:" prefix with "evdev:" and drop the separate 60-keyboard.rules
file. The new 60-evdev.rules is called for all event nodes
anyway, we don't need a separate rules file and second callout to the hwdb
builtin.
This reverts commit ba76ee29bc. As it turns
out, we need to match on driver=atkbd to not load the fixups on any
plugged USB devices.
That is, whenever you use "name:<name>:dmi:<dmi>" style matches, you
better provide a name or you're screwing things up.
Currently, we always run
hwdb 'keyboard:name:$attr{name}:$attr{[dmi/id]modalias}'
as last step to match keyboards. Therefore, if nothing else matched so
far, we still try the device-name+dmi combination.
However, we have a special atkbd rule which is only run for atkbd as:
hwdb 'keyboard:$attr{[dmi/id]modalias}'
This is redundant, as we already pass the same information to hwdb in the
last fallback step.
This patch converts the hwdb "keyboard:dmi:*" matches to
"keyboard:name:*:dmi:*" matches and drops the redundant rule.
There is no reason to match on usb-modaliases, if we can use the
input-modalias to achieve the same. This commit changes the
keyboard-lookups to not be restricted to USB, but pass all modaliases to
the hwdb. Furthermore, we convert all usb:* matches to input:* matches,
thus getting rid of any ambiguity if multiple usb devices are chained (or
a bluetooth device / etc. is on top).
Note that legacy keyboard:usb:* matches are still supported, but
deprecated. If possible, please use keyboard:input:* matches instead.
This is a required step to make other input devices work with
60-keyboard.hwdb. Other bus-types are often chained on usb and we want to
avoid any ambiguity here if we incorrectly match on a USB hub.
