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 graphic chip doesn't have a DRM driver and fall back to vesa-framebuffer
driver.
Without this patch, users of such chip suddenly see their GUI broken without
any indication or reason of what happened (no error message). Hence this
regression is near to impossible to troubleshoot for end users. Such case was
reported https://bugzilla.opensuse.org/show_bug.cgi?id=1187154.
Rather than adding another exception in the udev rules to deal with such
HWs, they instead get their own hwdb file '60-seat.hwdb'.
The Pinebook Pro touchpad returns a resolution data that is 2 times of
the real value, which makes libinput think the touchpad is only 1/4 the
real size.
Add a resolution override value for it, to allow libinput to calculate
the distance moved on it correctly.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Recently the kernel has gotten support for reading the mount-matrix for
BMA250 sensors represented by a BOSC0200 ACPI device from the ACPI tables,
so that we don't need to add quirks for these.
At least that was the theory. The Chuwi Hi13 (CWI534) with BMA250 sensor
has the sensor mounted such that it works / needs the normal(ized) matrix,
but the ACPI tables actually contain a wrong matrix inverting the X and Y
axis.
Add a quirk to override /sys/bus/iio/devices/iio:device?/in_mount_matrix
with the norm-matrix, since the ACPI derived matrix is actually wrong on
these devices (sigh)
Altough the Logitech website states "1000 DPI", the default DPI
settings seems to be 800 as shown by older versions of Logitech
SetPoint and verification by mouse-dpi-tool.
The old settings were all over the place contained mixed refresh rates.
The new settings are the correct default DPI settings as advertised online.
This has also been confirmed in the latest Logitech Gaming Software (9.02.65).
The atkbd device on the Lenovo Yoga 300-11IBR 2-in-1 sends unknown
keycodes when the touchpad is toggled on/off:
[ 1918.995562] atkbd serio0: Unknown key pressed (translated set 2, code 0x63 on isa0060/serio0).
[ 1918.995610] atkbd serio0: Use 'setkeycodes 63 <keycode>' to make it known.
[ 1919.032121] atkbd serio0: Unknown key released (translated set 2, code 0x63 on isa0060/serio0).
[ 1919.032135] atkbd serio0: Use 'setkeycodes 63 <keycode>' to make it known.
[ 1926.098414] atkbd serio0: Unknown key pressed (translated set 2, code 0x62 on isa0060/serio0).
[ 1926.098461] atkbd serio0: Use 'setkeycodes 62 <keycode>' to make it known.
[ 1926.146537] atkbd serio0: Unknown key released (translated set 2, code 0x62 on isa0060/serio0).
[ 1926.146583] atkbd serio0: Use 'setkeycodes 62 <keycode>' to make it known.
The "Ideapad extra buttons" driver alreadys sends f22 / f23 key-events
when the touchpad is toggles off, so map the keycodes for the duplicate
atkbd events to unknown to silence these kernel warnings.
Old meson fails with:
Element not a string: [<Holder: <ExternalProgram 'sh' -> ['/bin/sh']>>, '-c', 'test -n "$DESTDIR" || /bin/journalctl --update-catalog']
I'm doing it as a revert so that it's easy to undo the revert when we require
newer meson. The effect is not so bad, maybe a dozen or so lines about finding
'sh'.
Meson 0.58 has gotten quite bad with emitting a message every time
a quoted command is used:
Program /home/zbyszek/src/systemd-work/tools/meson-make-symlink.sh found: YES (/home/zbyszek/src/systemd-work/tools/meson-make-symlink.sh)
Program sh found: YES (/usr/bin/sh)
Program sh found: YES (/usr/bin/sh)
Program sh found: YES (/usr/bin/sh)
Program sh found: YES (/usr/bin/sh)
Program sh found: YES (/usr/bin/sh)
Program sh found: YES (/usr/bin/sh)
Program xsltproc found: YES (/usr/bin/xsltproc)
Configuring custom-entities.ent using configuration
Message: Skipping bootctl.1 because ENABLE_EFI is false
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Message: Skipping journal-remote.conf.5 because HAVE_MICROHTTPD is false
Message: Skipping journal-upload.conf.5 because HAVE_MICROHTTPD is false
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Message: Skipping loader.conf.5 because ENABLE_EFI is false
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
...
Let's suffer one message only for each command. Hopefully we can silence
even this when https://github.com/mesonbuild/meson/issues/8642 is
resolved.
- Internet specifications give 1600 DPI @ 1000Hz for this sensor
- Confirmed experimentally via `mouse-dpi-tool`
- vid, pid, and name match string from `mouse-dpi-tool`
I have also seen that VIOS LTH17 has the exact same correction and it's also a SIPODEV composite hid device also through usb. In the D330 is a detachable keyboard. It's possible that a very generic way to apply this to at least affected sipodev keyboard could be found using the device ids, but needs info to do that and ensure all sipodev keyboard with the pertinent ids need it.
Signed-off-by: David Santamaría Rogado <howl.nsp@gmail.com>
We use pvr match for efifb pitch and drm orientation quirk and in touchpad toggle keymap. Also seems most consistent with the devices here.
While at it, correct a typo, 81H3 and 81MD are product names not numbers, my bad.
Signed-off-by: David Santamaría Rogado <howl.nsp@gmail.com>
D330-10IGM has been added due the fact that 81H3 and 81MD product name belongs to the same product version. So the fact is that now that we know 81MD has the same transformation matrix that the 81H3 we can just use the product version and get rid the product name.
Signed-off-by: David Santamaría Rogado <howl.nsp@gmail.com>
In IEC 61883-1:1998, we can see some values for AV/C device with vendor
unique command set in IEC 61883-1:1998. Current udev rule handles it
for video. However it brings an issue that the functions in AV/C device
are not distinguished just by the content of configuration ROM.
In former commit, hardware database was added to describe function type
of unit in the node, then udev rules are added to utilize the database.
However, we have an request to obsolete existent udev rules by putting
enough entries to the database. It should be done carefully.
This commit adds entry into hardware database just for backward
compatibility. The entry can match to some node and unit unexpectedly.
Therefore this commit modifies existent entries to invalidate the effect
from added entry.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Typical node of AV/C device has standard content of configuration ROM.
This is defined in documentation of 1394 Trading Association.
* Configuration ROM for AV/C Devices 1.0 (Dec. 12, 2000, 1394 Trading
Association, TA Document 1999027)
However, it brings an issue that the functions in AV/C device are not
distinguished just by the content of configuration ROM.
In former commit, hardware database was added to describe function type
of unit in the node, then udev rules are added to utilize the database.
However, we have an request to obsolete existent udev rules by putting
enough entries to the database. It should be done carefully.
This commit adds entry into hardware database just for backward
compatibility. The entry can match to some node and unit unexpectedly.
Therefore this commit modifies existent entries to invalidate the effect
from added entry.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
IIDC specification describes configuration ROM without model field, thus
it's not possible to match any entry with vendor ID and model ID.
Current entry for Cool Stream iSweet can match any node and unit of
IIDC.
This commit removes the entry. I note that this model uses Texus
Instruments MC680-DCC as all-in-one chipset for video function in
IEEE 1394 bus.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Point Grey Research, inc. shipped cameras to support IIDC, however some
of them are necessarily compliant to IIDC specification in terms of the
value of software version field in unit directory of configuration ROM.
This commit adds entries for them.
Reviewed-by: Damien Douxchamps <damien@douxchamps.net>
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Instrumentation & Industrial Digital Camera (IIDC) specifications are
defined by 1394 Trading Association for camera device in IEEE 1394 bus.
IIDC2 specifications are defined by joint working group between Japan
Industrial Imaging Association (JIIA) and 1394 Trade Association as
bus-independent specification.
This commit adds entries for the specifications to remove existent udev
rules. Supported specifications are listed below:
* 1394-based Digital Camera Specification Version 1.04 (Aug. 9, 1996,
1394 Trading Association)
* 1394-based Digital Camera Specification Version 1.20 (Jul. 23, 1998,
1394 Trading Association)
* IIDC Digital Camera Control Specification Ver.1.30 (Jul. 25, 2000,
1394 Trading Association)
* IIDC Digital Camera Control Specification Ver.1.31 (Feb. 2, 2004,
1394 Trading Association, TA Document 2003017)
* IIDC Digital Camera Control Specification Ver.1.32 (Jul. 24, 2008,
1394 Trading Association, Document number 2007009)
* IIDC2 Digital Camera Control Specification Ver.1.0.0 (Jan 26th, 2012,
1394 Trading Association, TS2011001)
* IIDC2 Digital Camera Control Specification Ver.1.1.0 (May 19th, 2015,
1394 Trading Association, TS2015001)
Reviewed-by: Damien Douxchamps <damien@douxchamps.net>
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Linux kernel has firedtv kernel module as driver for Digital Everywhere
FloppyDTV and FireDTV. Although this driver works without any help of
userspace application, it's better to add entries to hardware database
for developer's convenience.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>