Age | Commit message (Collapse) | Author |
|
The FT260 is not supposed to generate unexpected HID reports. However,
in theory, the unsolicited HID Input reports can be issued by a specially
crafted malicious USB device masquerading as FT260 when the attacker has
physical access to the USB port. In this case, the read_buf pointer points
to the final data portion of the previous I2C Read transfer, and the memcpy
invoked in the ft260_raw_event() will try copying the content of the
unexpected report into the wrong location.
This commit sets the Read buffer pointer to NULL on the I2C Read
transaction completion and checks it in the ft260_raw_event() to detect
and skip the unsolicited Input report.
Reported-by: Enrik Berkhan <Enrik.Berkhan@inka.de>
Signed-off-by: Michael Zaidman <michael.zaidman@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
Do not populate the /dev/hidraw on ft260 interfaces when the hid-ft260
driver is loaded.
$ sudo insmod hid-ft260.ko
$ ls /dev/hidraw*
/dev/hidraw0
$ sudo rmmod hid-ft260.ko
$ ls /dev/hidraw*
/dev/hidraw0 /dev/hidraw1 /dev/hidraw2
Reported-by: Enrik Berkhan <Enrik.Berkhan@inka.de>
Signed-off-by: Michael Zaidman <michael.zaidman@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
The patch increases the read buffer size to 180 bytes. It reduces
the number of ft260_i2c_read() calls by three, improving the big
reads performance.
$ sudo i2ctransfer -y -f 13 w2@0x51 0x0 0x0 r180
Before:
[ +4.071878] ft260_i2c_write_read: off 0x0 rlen 180 wlen 2
[ +0.000005] ft260_i2c_write: rep 0xd0 addr 0x51 off 0 len 2 wlen 2 flag 0x2 d[0] 0x0
[ +0.001097] ft260_xfer_status: bus_status 0x41, clock 100
[ +0.000175] ft260_xfer_status: bus_status 0x40, clock 100
[ +0.000004] ft260_i2c_read: rep 0xc2 addr 0x51 len 180 rlen 60 flag 0x3
[ +0.008579] ft260_raw_event: i2c resp: rep 0xde len 60
[ +0.000208] ft260_xfer_status: bus_status 0x40, clock 100
[ +0.000001] ft260_i2c_read: rep 0xc2 addr 0x51 len 120 rlen 60 flag 0x0
[ +0.008794] ft260_raw_event: i2c resp: rep 0xde len 60
[ +0.000181] ft260_xfer_status: bus_status 0x40, clock 100
[ +0.000002] ft260_i2c_read: rep 0xc2 addr 0x51 len 60 rlen 60 flag 0x4
[ +0.008817] ft260_raw_event: i2c resp: rep 0xde len 60
[ +0.000223] ft260_xfer_status: bus_status 0x20, clock 100
After:
[ +11.611642] ft260_i2c_write_read: off 0x0 rlen 180 wlen 2
[ +0.000005] ft260_i2c_write: rep 0xd0 addr 0x51 off 0 len 2 wlen 2 flag 0x2 d[0] 0x0
[ +0.008001] ft260_xfer_status: bus_status 0x20, clock 100
[ +0.000001] ft260_i2c_read: rep 0xc2 addr 0x51 len 180 rlen 180 flag 0x7
[ +0.008994] ft260_raw_event: i2c resp: rep 0xde len 60
[ +0.007987] ft260_raw_event: i2c resp: rep 0xde len 60
[ +0.007992] ft260_raw_event: i2c resp: rep 0xde len 60
[ +0.000206] ft260_xfer_status: bus_status 0x20, clock 100
Suggested-by: Enrik Berkhan <Enrik.Berkhan@inka.de>
Signed-off-by: Michael Zaidman <michael.zaidman@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
A random i2c read operation in EEPROM devices is implemented as a dummy
write operation, followed by a current address read operation. The dummy
write operation is used to load the target byte or word address (a.k.a
offset) into the offset counter, from which the subsequent read operation
then reads.
To support longer than one HID report size random read, the ft260 driver
issues multiple pairs of i2c write offset + read data transactions of HID
report size so that the EEPROM device sees many i2c random read requests
from different offsets.
Two issues with the current implementation:
- This approach suffers from extra overhead caused by writing offset
requests.
- Necessity to handle offset per HID report in big-endian representation
as EEPROM devices expect. The current implementation does not do it and
correctly handles the reads up to 60 bytes only.
This patch addresses both issues by implementing more efficient approach.
It issues a single i2c read request of up to the EEPROM page size and then
waits for the data to arrive in multiple HID reports. For example, to read
the 256 bytes from a 24LC512 chip, which has 128 bytes page size, the old
method performs six ft260_i2c_write_read transactions while the new - two
only.
Before:
$ sudo ./i2cperf -d 2 -o 2 -s 128 -r 0-0xff 13 0x51 -S
Read block via i2ctransfer by chunks
-------------------------------------------------------------------
data rate(bps) efficiency(%) data size(B) total IOs IO size(B)
-------------------------------------------------------------------
40803 85 256 2 128
Kernel log of a single 128 bytes read request:
[ +2.376308] ft260_i2c_write_read: read_off 0x0 left_len 128 len 60
[ +0.000002] ft260_i2c_write: rep 0xd0 addr 0x51 off 0 len 2 wlen 2 flag 0x2 d[0] 0x0
[ +0.000707] ft260_xfer_status: bus_status 0x41, clock 100
[ +0.000173] ft260_xfer_status: bus_status 0x40, clock 100
[ +0.000001] ft260_i2c_read: rep 0xc2 addr 0x51 len 60
[ +0.008660] ft260_raw_event: i2c resp: rep 0xde len 60
[ +0.000156] ft260_xfer_status: bus_status 0x20, clock 100
[ +0.000001] ft260_i2c_write_read: read_off 0x3c left_len 68 len 60
[ +0.000001] ft260_i2c_write: rep 0xd0 addr 0x51 off 0 len 2 wlen 2 flag 0x2 d[0] 0x3c
[ +0.001034] ft260_xfer_status: bus_status 0x41, clock 100
[ +0.000191] ft260_xfer_status: bus_status 0x40, clock 100
[ +0.000001] ft260_i2c_read: rep 0xc2 addr 0x51 len 60
[ +0.008614] ft260_raw_event: i2c resp: rep 0xde len 60
[ +0.000203] ft260_xfer_status: bus_status 0x20, clock 100
[ +0.000001] ft260_i2c_write_read: read_off 0x78 left_len 8 len 8
[ +0.000001] ft260_i2c_write: rep 0xd0 addr 0x51 off 0 len 2 wlen 2 flag 0x2 d[0] 0x78
[ +0.000987] ft260_xfer_status: bus_status 0x41, clock 100
[ +0.000192] ft260_xfer_status: bus_status 0x40, clock 100
[ +0.000001] ft260_i2c_read: rep 0xc2 addr 0x51 len 8
[ +0.002614] ft260_raw_event: i2c resp: rep 0xd1 len 8
[ +0.000200] ft260_xfer_status: bus_status 0x20, clock 100
After:
$ sudo ./i2cperf -d 2 -o 2 -s 128 -r 0-0xff 13 0x51 -S
Read block via i2ctransfer by chunks
-------------------------------------------------------------------
data rate(bps) efficiency(%) data size(B) total IOs IO size(B)
-------------------------------------------------------------------
43990 85 256 2 128
Kernel log of a single 128 bytes read request:
[ +1.464346] ft260_i2c_write_read: off 0x0 rlen 128 wlen 2
[ +0.000002] ft260_i2c_write: rep 0xd0 addr 0x51 off 0 len 2 wlen 2 flag 0x2 d[0] 0x0
[ +0.001653] ft260_xfer_status: bus_status 0x41, clock 100
[ +0.000188] ft260_xfer_status: bus_status 0x40, clock 100
[ +0.000002] ft260_i2c_read: rep 0xc2 addr 0x51 len 128 rlen 60 flag 0x3
[ +0.008609] ft260_raw_event: i2c resp: rep 0xde len 60
[ +0.000157] ft260_xfer_status: bus_status 0x40, clock 100
[ +0.000002] ft260_i2c_read: rep 0xc2 addr 0x51 len 68 rlen 60 flag 0x0
[ +0.008840] ft260_raw_event: i2c resp: rep 0xde len 60
[ +0.000203] ft260_xfer_status: bus_status 0x40, clock 100
[ +0.000002] ft260_i2c_read: rep 0xc2 addr 0x51 len 8 rlen 8 flag 0x4
[ +0.002794] ft260_raw_event: i2c resp: rep 0xd1 len 8
[ +0.000201] ft260_xfer_status: bus_status 0x20, clock 100
Signed-off-by: Michael Zaidman <michael.zaidman@gmail.com>
Tested-by: Guillaume Champagne <champagne.guillaume.c@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
To support longer than one HID report size write, the driver splits a
single i2c message data payload into multiple i2c messages of HID report
size. However, it does not replicate the offset bytes within the EEPROM
chip in every consequent HID report because it is not and should not be
aware of the EEPROM type. It breaks the i2c write message integrity and
causes the EEPROM device not to acknowledge the second HID report keeping
the i2c bus busy until the ft260 controller reports failure.
This patch preserves the i2c write message integrity by manipulating the
i2c flag bits across multiple HID reports to be seen by the EEPROM device
as a single i2c write transfer.
Before:
$ sudo ./i2cperf -f 2 -o 2 -s 64 -r 0-0xff 13 0x51 -S
Error: Sending messages failed: Input/output error
[ +3.667741] ft260_i2c_write: rep 0xde addr 0x51 off 0 len 60 d[0] 0x0
[ +0.007330] ft260_hid_output_report_check_status: wait 6400 usec, len 64
[ +0.000203] ft260_xfer_status: bus_status 0x40, clock 100
[ +0.000001] ft260_i2c_write: rep 0xd1 addr 0x51 off 60 len 6 d[0] 0x0
[ +0.002337] ft260_hid_output_report_check_status: wait 1000 usec, len 10
[ +0.000157] ft260_xfer_status: bus_status 0x2e, clock 100
[ +0.000241] ft260_i2c_reset: done
[ +0.000003] ft260_i2c_write: failed to start transfer, ret -5
After:
$ sudo ./i2cperf -f 2 -o 2 -s 128 -r 0-0xff 13 0x51 -S
Fill block with increment via i2ctransfer by chunks
-------------------------------------------------------------------
data rate(bps) efficiency(%) data size(B) total IOs IO size(B)
-------------------------------------------------------------------
71260 86 256 2 128
Signed-off-by: Michael Zaidman <michael.zaidman@gmail.com>
Tested-by: Guillaume Champagne <champagne.guillaume.c@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
The patch improves the I2C write performance by 20 - 30 percent by
revising the sleep time in the ft260_hid_output_report_check_status()
in the following ways:
1. Reduce the wait time and start to poll earlier.
Sending a large amount of data at a low I2C clock rate saturates the
internal FT260 buffer and causes hiccups in status readiness, as shown
below in the log fragment. Aligning the status check wait time to the
worst case significantly reduces the write performance.
[Oct22 10:28] ft260_i2c_write: rep 0xd8 addr 0x51 off 0 len 34 d[0] 0x0
[ +0.005296] ft260_xfer_status: bus_status 0x20, clock 100
[ +0.013460] ft260_i2c_write: rep 0xd8 addr 0x51 off 0 len 34 d[0] 0x0
[ +0.003244] ft260_hid_output_report_check_status: wait 1920 usec, len 38
[ +0.000190] ft260_xfer_status: bus_status 0x40, clock 100
[ +0.015324] ft260_i2c_write: rep 0xd8 addr 0x51 off 0 len 34 d[0] 0x0
[ +0.003491] ft260_hid_output_report_check_status: wait 1920 usec, len 38
[ +0.000202] ft260_xfer_status: bus_status 0x40, clock 100
[ +0.016047] ft260_i2c_write: rep 0xd8 addr 0x51 off 0 len 34 d[0] 0x0
[ +0.002768] ft260_hid_output_report_check_status: wait 1920 usec, len 38
[ +0.000150] ft260_xfer_status: bus_status 0x40, clock 100
[ +0.011389] ft260_i2c_write: rep 0xd8 addr 0x51 off 0 len 34 d[0] 0x0
[ +0.003467] ft260_hid_output_report_check_status: wait 1920 usec, len 38
[ +0.000191] ft260_xfer_status: bus_status 0x41, clock 100
[ +0.000172] ft260_xfer_status: bus_status 0x41, clock 100
[ +0.000131] ft260_xfer_status: bus_status 0x41, clock 100
[ +0.000241] ft260_xfer_status: bus_status 0x41, clock 100
[ +0.000233] ft260_xfer_status: bus_status 0x41, clock 100
[ +0.000190] ft260_xfer_status: bus_status 0x41, clock 100
[ +0.000196] ft260_xfer_status: bus_status 0x40, clock 100
[ +0.011314] ft260_i2c_write: rep 0xd8 addr 0x51 off 0 len 34 d[0] 0x0
[ +0.003334] ft260_hid_output_report_check_status: wait 1920 usec, len 38
[ +0.000227] ft260_xfer_status: bus_status 0x41, clock 100
[ +0.000204] ft260_xfer_status: bus_status 0x41, clock 100
[ +0.000198] ft260_xfer_status: bus_status 0x41, clock 100
[ +0.000147] ft260_xfer_status: bus_status 0x40, clock 100
[ +0.011060] ft260_i2c_write: rep 0xd8 addr 0x51 off 0 len 34 d[0] 0x0
Before:
$ sudo ./i2cperf -f 2 -o 2 -s 32 -r 0-0xff 13 0x51 -S
Fill block with increment via i2ctransfer by chunks
-------------------------------------------------------------------
data rate(bps) efficiency(%) data size(B) total IOs IO size(B)
-------------------------------------------------------------------
40510 80 256 8 32
After:
$ sudo ./i2cperf -f 2 -o 2 -s 32 -r 0-0xff 13 0x51 -S
Fill block with increment via i2ctransfer by chunks
-------------------------------------------------------------------
data rate(bps) efficiency(%) data size(B) total IOs IO size(B)
-------------------------------------------------------------------
52584 80 256 8 32
2. Do not sleep if the estimated I2C transfer time is below 2 ms since
the first xfer status query frequently takes around 1.5 ms, and the
following status queries take about 200us on average. So we usually
return from the routine after the first 1 - 3 status checks.
[Oct22 11:14] ft260_i2c_write: rep 0xd4 addr 0x51 off 0 len 18 d[0] 0x0
[ +0.004270] ft260_xfer_status: bus_status 0x20, clock 100
[ +0.013889] ft260_i2c_write: rep 0xd4 addr 0x51 off 0 len 18 d[0] 0x0
[ +0.000856] ft260_xfer_status: bus_status 0x41, clock 100
[ +0.000138] ft260_xfer_status: bus_status 0x40, clock 100
[ +0.013352] ft260_i2c_write: rep 0xd4 addr 0x51 off 0 len 18 d[0] 0x0
[ +0.001501] ft260_xfer_status: bus_status 0x41, clock 100
[ +0.000177] ft260_xfer_status: bus_status 0x40, clock 100
[ +0.014477] ft260_i2c_write: rep 0xd4 addr 0x51 off 0 len 18 d[0] 0x0
[ +0.001377] ft260_xfer_status: bus_status 0x41, clock 100
[ +0.000233] ft260_xfer_status: bus_status 0x41, clock 100
[ +0.000191] ft260_xfer_status: bus_status 0x40, clock 100
[ +0.013197] ft260_i2c_write: rep 0xd4 addr 0x51 off 0 len 18 d[0] 0x0
Before:
$ sudo ./i2cperf -f 2 -o 2 -s 16 -r 0-0xff 13 0x51 -S
Fill block with increment via i2ctransfer by chunks
-------------------------------------------------------------------
data rate(bps) efficiency(%) data size(B) total IOs IO size(B)
-------------------------------------------------------------------
28826 73 256 16 16
After:
$ sudo ./i2cperf -f 2 -o 2 -s 16 -r 0-0xff 13 0x51 -S
Fill block with increment via i2ctransfer by chunks
-------------------------------------------------------------------
data rate(bps) efficiency(%) data size(B) total IOs IO size(B)
-------------------------------------------------------------------
45138 73 256 16 16
Signed-off-by: Michael Zaidman <michael.zaidman@gmail.com>
Tested-by: Guillaume Champagne <champagne.guillaume.c@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
After clarifying with FTDI's support, it turned out that the error
condition (bit 1) in byte 1 of the i2c status HID report is a status
bit reflecting all error conditions. When bits 2, 3, or 4 are raised
to 1, bit 1 is set to 1 also. Since the ft260_xfer_status routine tests
the error condition bit and exits in the case of an error, the program
flow never reaches the conditional expressions for 2, 3, and 4 bits when
any of them indicates an error state. Though these expressions are never
evaluated to true, they are checked several times per IO, increasing the
ft260_xfer_status polling cycle duration.
The patch removes the conditional expressions for 2, 3, and 4 bits in
byte 1 of the i2c status HID report.
Signed-off-by: Michael Zaidman <michael.zaidman@gmail.com>
Tested-by: Guillaume Champagne <champagne.guillaume.c@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
This patch adds support for the DualShock4 dongle in a very similar
way we contributed to hid-sony before.
The dongle is a USB to Bluetooth bridge and uses the same HID reports
as a USB device. It reports data through the DS4's main USB input
report independent on whether a Bluetooth controller is connected.
For this reason there is custom dongle report parsing code to
detect controller hotplug and kick of calibration work until we
are ready to process actual input reports.
The logic also incorporates a workaround needed for Steam in which
hid-playstation and Steam using hidraw can fight.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
The poll interval for DualShock4 in Bluetooth mode is adjustable
through the main output report. Configure it to 4ms, which is
similar to USB.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
Add support for DualShock4 in Bluetooth mode. In Bluetooth, the device
is a bit strange in that after 'calibration' it switches sending all its
input data from a basic report (only containing buttons/sticks) to an
extended report, which also contains touchpad, motion sensors and other
data. The overall design of this code is similar to the DualSense code.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
This patch adds a parameter to ps_get_report to ignore CRC checks.
This prepares for DualShock4, which has some HID reports, which lack CRC.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
Support lightbar blink through LEDs framework.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
Expose the lightbar LEDs in the same manner as hid-sony through
individual LEDs for backwards compatibility reasons. There is a
slight change in LED naming to use the input device name as opposed
to the MAC address like hid-sony did. This is expected to not
cause any issues and should make the naming more compliant.
In addition set a default lightbar color based on player ID.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
Make the max_brightness adjustable through ps_led_info struct. This
paves the way for a next DualShock4 patch to allow larger brightness
values.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
This patch implements DualShock4 rumble support in a similar manner
as the DualSense implementation. It adds an output worker with
granular control of different features of the main DualShock4 output
report.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
Support accelerometer and gyroscope as separate input devices similar
how DualSense and hid-sony do it.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
Support the DualShock4 touchpad as a separate input device. The code
describes the touchpad input reports through structures similar a bit
to the DualSense code.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
Provide DualShock4 battery support through powersupply framework.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
Report DualShock4 hardware and firmware version info through sysfs.
It uses the same sysfs nodes as the DualSense did (and hid-sony).
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
Add basic support for DualShock4 USB controller with buttons and sticks.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
The XP-PEN Deco LW is a UGEE v2 device with a frame with 8 buttons.
Its pen has 2 buttons, supports tilt and pressure.
It can be connected by USB cable or using a USB Bluetooth dongle to use
it in wireless mode. When it is connected using the dongle, the device
battery is used to power it.
Its vendor, product and version are identical to the Deco L. The only
difference reported by its firmware is the product name.
In order to add support for battery reporting, add a new HID descriptor
and a quirk to detect the wireless version of the tablet.
Link: https://github.com/DIGImend/digimend-kernel-drivers/issues/635
Tested-by: Mia Kanashi <chad@redpilled.dev>
Tested-by: Andreas Grosse <andig.mail@t-online.de>
Tested-by: Mia Kanashi <chad@redpilled.dev>
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
The XP-PEN Deco LW drawing tablet can be connected by USB cable or using
a USB Bluetooth dongle. When it is connected using the dongle, there
might be a small delay until the tablet is paired with the dongle.
Fetching the device battery during this delay results in random battery
percentage values.
Add a quirk to avoid actively querying the battery percentage and wait
for the device to report it on its own.
Reported-by: Mia Kanashi <chad@redpilled.dev>
Tested-by: Mia Kanashi <chad@redpilled.dev>
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
This adds support for the turntable extension for Wiimote devices.
jstest-gtk and html5 gamepad tester show everything correctly
but when trying to map the controller in software like rpcs3 or dolphin
it currently doesn't map correctly
Co-authored-by: Bogdan Petru <thonkdifferent@outlook.com>
Signed-off-by: Bogdan Petru <thonkdifferent@outlook.com>
Signed-off-by: Joshua Jun <joshuajun@vivaldi.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
When support was added for devices using an explicit 3rd barrel switch,
the logic used by devices emulating this feature was broken. The 'if'
statement / block that was introduced only handles the case where the
button is pressed (i.e. 'barrelswitch' and 'barrelswitch2' are both set)
but not the case where it is released (i.e. one or both being cleared).
This results in a BTN_STYLUS3 "down" event being sent when the button
is pressed, but no "up" event ever being sent afterwards.
This patch restores the previously-used logic for determining button
states in the emulated case so that switches are reported correctly
again.
Link: https://github.com/linuxwacom/xf86-input-wacom/issues/292
Fixes: 6d09085b38e5 ("HID: wacom: Adding Support for new usages")
CC: stable@vger.kernel.org #v5.19+
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Tested-by: Joshua Dickens <joshua.dickens@wacom.com>
Reviewed-by: Ping Cheng <ping.cheng@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
If hid_add_device() returns error, it should call hid_destroy_device()
to free hid_dev which is allocated in hid_allocate_device().
Fixes: 74c4fb058083 ("HID: hv_mouse: Properly add the hid device")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Reviewed-by: Wei Liu <wei.liu@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
Variable count is just being incremented and it's never used
anywhere else. The variable and the increment are redundant so
remove it.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
T2 chip
The iso_layout parameter must be manually set to get the driver to
swap KEY_102ND and KEY_GRAVE. This patch eliminates the need to do that.
This is safe to do, as Macs with keyboards that do not need the quirk
will keep working the same way as the value of hid->country will be
different than HID_COUNTRY_INTERNATIONAL_ISO. This was tested by one
person with a Mac with the WELLSPRINGT2_J152F keyboard with a layout
that does not require the quirk to be set.
Signed-off-by: Kerem Karabay <kekrby@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
the same key
The hid-apple driver does not support chaining translations or
dependencies on other translations. This creates two problems:
1 - In Non-English keyboards of Macs, KEY_102ND and KEY_GRAVE are
swapped and the APPLE_ISO_TILDE_QUIRK is used to work around this
problem. The quirk is not set for the Macs where these bugs happen yet
(see the 2nd patch for that), but this can be forced by setting the
iso_layout parameter. Unfortunately, this only partially works.
KEY_102ND gets translated to KEY_GRAVE, but KEY_GRAVE does not get
translated to KEY_102ND, so both of them end up functioning as
KEY_GRAVE. This is because the driver translates the keys as if Fn was
pressed and the original is sent if it is not pressed, without any
further translations happening on the key[#463]. KEY_GRAVE is present at
macbookpro_no_esc_fn_keys[#195], so this is what happens:
- KEY_GRAVE -> KEY_ESC (as if Fn is pressed)
- KEY_GRAVE is returned (Fn isn't pressed, so translation is discarded)
- KEY_GRAVE -> KEY_102ND (this part is not reached!)
...
2 - In case the touchbar does not work, the driver supports sending
Escape when Fn+KEY_GRAVE is pressed. As mentioned previously, KEY_102ND
is actually KEY_GRAVE and needs to be translated before this happens.
Normally, these are the steps that should happen:
- KEY_102ND -> KEY_GRAVE
- KEY_GRAVE -> KEY_ESC (Fn is pressed)
- KEY_ESC is returned
Though this is what happens instead, as dependencies on other
translations are not supported:
- KEY_102ND -> KEY_ESC (Fn is pressed)
- KEY_ESC is returned
This patch fixes both bugs by ordering the translations correctly and by
making the translations continue and not return immediately after
translating a key so that chained translations work and translations can
depend on other ones.
This patch also simplifies the implementation of the swap_fn_leftctrl
option a little bit, as it makes it simply use a normal translation
instead adding extra code to translate a key to KEY_FN[#381]. This change
wasn't put in another patch as the code that translates the Fn key needs
to be changed because of the changes in the patch, and those changes
would be discarded with the next patch anyway (the part that originally
translates KEY_FN to KEY_LEFTCTRL needs to be made an else-if branch of
the part that transltes KEY_LEFTCTRL to KEY_FN).
Note: Line numbers (#XYZ) are for drivers/hid/hid-apple.c at commit
20afcc462579 ("HID: apple: Add "GANSS" to the non-Apple list").
Note: These bugs are only present on Macs with a keyboard with no
dedicated escape key and a non-English layout.
Signed-off-by: Kerem Karabay <kekrby@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
struct synthhid_msg was meant to be a generic representation of the
possible protocol messages sent through VMBus. In practice, only the
header is read and depending on the message type, a cast to the actual
type is done. Also, SYNTHHID_MAX_INPUT_REPORT_SIZE constant isn't used
which I suspect is a leftover from the refactoring made while this
driver was at the staging folder.
This patch removes struct synthhid_msg and refactor the code
accordingly.
Signed-off-by: Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid
Pull HID fixes from Benjamin Tissoires:
- a 12 year old bug fix for the Apple Magic Trackpad v1 (José Expósito)
- a fix for a potential crash on removal of the Playstation controllers
(Roderick Colenbrander)
- a few new device IDs and device-specific quirks, most notably support
of the new Playstation DualSense Edge controller
* tag 'for-linus-2022102101' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid:
HID: lenovo: Make array tp10ubkbd_led static const
HID: saitek: add madcatz variant of MMO7 mouse device ID
HID: playstation: support updated DualSense rumble mode.
HID: playstation: add initial DualSense Edge controller support
HID: playstation: stop DualSense output work on remove.
HID: magicmouse: Do not set BTN_MOUSE on double report
|
|
Singular #ifdef IS_REACHABLE(CONFIG_GPIOLIB) weren't covering all the
gpiolib functions that were being referenced.
Update the code regions that are commented out when CONFIG_GPIOLIB isn't
enabled to avoid errors.
Fixes: 960f9df7c620 ("HID: mcp2221: add ADC/DAC support via iio subsystem")
Signed-off-by: Matt Ranostay <matt.ranostay@konsulko.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
Use (__force __le16) cast for adc_values le16_to_cpu conversion to correct following sparse
warnings:
drivers/hid/hid-mcp2221.c:950:32: sparse: sparse: cast to restricted __le16
Reported-by: kernel test robot <lkp@intel.com>
Fixes: 960f9df7c620 ("HID: mcp2221: add ADC/DAC support via iio subsystem")
Signed-off-by: Matt Ranostay <matt.ranostay@konsulko.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
In mcp2221_raw_event(), 'tmp' is used only conditionally. Move
the declaration into the conditional block in order to prevent
unused variable warning.
Reported-by: kernel test robot <lkp@intel.com>
Fixes: 960f9df7c620 ("HID: mcp2221: add ADC/DAC support via iio subsystem")
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
With the changes to the driver core to make more pointers const, the USB
subsystem also needs to be modified to take a const * for the devnode
callback so that the driver core's constant pointer will also be
properly propagated.
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Juergen Stuber <starblue@users.sourceforge.net>
Reviewed-by: Johan Hovold <johan@kernel.org>
Acked-by: Pete Zaitcev <zaitcev@redhat.com>
Reviewed-by: Jiri Kosina <jkosina@suse.cz>
Link: https://lore.kernel.org/r/20221001165128.2688526-1-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
All these drivers have an i2c probe function which doesn't use the
"struct i2c_device_id *id" parameter, so they can trivially be
converted to the "probe_new" style of probe with a single argument.
This is part of an ongoing transition to single-argument i2c probe
functions. Old-style probe functions involve a call to i2c_match_id:
in drivers/i2c/i2c-core-base.c,
/*
* When there are no more users of probe(),
* rename probe_new to probe.
*/
if (driver->probe_new)
status = driver->probe_new(client);
else if (driver->probe)
status = driver->probe(client,
i2c_match_id(driver->id_table, client));
else
status = -EINVAL;
Drivers which don't need the second parameter can be declared using
probe_new instead, avoiding the call to i2c_match_id. Drivers which do
can still be converted to probe_new-style, calling i2c_match_id
themselves (as is done currently for of_match_id).
This change was done using the following Coccinelle script, and fixed
up for whitespace changes:
@ rule1 @
identifier fn;
identifier client, id;
@@
- static int fn(struct i2c_client *client, const struct i2c_device_id *id)
+ static int fn(struct i2c_client *client)
{
...when != id
}
@ rule2 depends on rule1 @
identifier rule1.fn;
identifier driver;
@@
struct i2c_driver driver = {
- .probe
+ .probe_new
=
(
fn
|
- &fn
+ fn
)
,
};
Signed-off-by: Stephen Kitt <steve@sk2.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
Add support for 3x 10-bit ADC and 1x DAC channels registered via the iio
subsystem.
To prevent breakage and unexpected dependencies this support only is
only built if CONFIG_IIO is enabled, and is only weakly referenced by
'imply IIO' within the respective Kconfig.
Additionally the iio device only gets registered if at least one channel
is enabled in the power-on configuration read from SRAM.
Signed-off-by: Matt Ranostay <matt.ranostay@konsulko.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
To avoid recursive dependencies on GPIOLIB when 'imply IIO' is requested
with other drivers we should switch GPIOLIB to an imply.
This isn't the most ideal solution but avoids modifiying the Kconfig for
other drivers, and only requires a singular IS_REACHABLE(CONFIG_GPIOLIB)
check.
Signed-off-by: Matt Ranostay <matt.ranostay@konsulko.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
Switch from i2c_add_adapter() to resource managed devm_i2c_add_adapter()
for matching rest of driver initialization, and more concise code.
Signed-off-by: Matt Ranostay <matt.ranostay@konsulko.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
One-element arrays are deprecated, and we are replacing them with
flexible array members instead. So, replace one-element array with
flexible-array member in structs synthhid_msg, synthhid_input_report,
pipe_prt_msg and refactor the rest of the code accordingly.
This helps with the ongoing efforts to tighten the FORTIFY_SOURCE
routines on memcpy() and help us make progress towards globally
enabling -fstrict-flex-arrays=3 [1].
Link: https://github.com/KSPP/linux/issues/79
Link: https://github.com/KSPP/linux/issues/210
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [1]
Signed-off-by: Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
Don't populate the read-only array tp10ubkbd_led on the stack but instead
make it static const. Also makes the object code a little smaller.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
The MadCatz variant of the MMO7 mouse has the ID 0738:1713 and the same
quirks as the Saitek variant.
Signed-off-by: Samuel Bailey <samuel.bailey1@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
Newer DualSense firmware supports a revised classic rumble mode,
which feels more similar to rumble as supported on previous PlayStation
controllers. It has been made the default on PlayStation and non-PlayStation
devices now (e.g. iOS and Windows). Default to this new mode when
supported.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Link: https://lore.kernel.org/r/20221010212313.78275-4-roderick.colenbrander@sony.com
|
|
Provide initial support for the DualSense Edge controller. The brings
support up to the level of the original DualSense, but won't yet provide
support for new features (e.g. reprogrammable buttons).
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
CC: stable@vger.kernel.org
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Link: https://lore.kernel.org/r/20221010212313.78275-3-roderick.colenbrander@sony.com
|
|
Ensure we don't schedule any new output work on removal and wait
for any existing work to complete. If we don't do this e.g. rumble
work can get queued during deletion and we trigger a kernel crash.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
CC: stable@vger.kernel.org
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Link: https://lore.kernel.org/r/20221010212313.78275-2-roderick.colenbrander@sony.com
|
|
Under certain conditions the Magic Trackpad can group 2 reports in a
single packet. The packet is split and the raw event function is
invoked recursively for each part.
However, after processing each part, the BTN_MOUSE status is updated,
sending multiple click events. [1]
Return after processing double reports to avoid this issue.
Link: https://gitlab.freedesktop.org/libinput/libinput/-/issues/811 # [1]
Fixes: a462230e16ac ("HID: magicmouse: enable Magic Trackpad support")
Reported-by: Nulo <git@nulo.in>
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Link: https://lore.kernel.org/r/20221009182747.90730-1-jose.exposito89@gmail.com
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
Pull input updates from Dmitry Torokhov:
- a new driver for IBM Operational Panel
- a new driver for PinePhone keyboards
- RT5120 PMIC power key support
- various enhancements and support for new models in xpad (Xbox) driver
- a new compatible ID for Elan touchscreen driver
- rework of adp5588-keys driver to support configuring via device
properties (OF, ACPI, etc) instead of platform data, and proper
support of optional gpiochip functionality (and removal of
gpio-adp5588 driver)
- improvements to firmware update handling in Synaptics RMI4 driver
- support for double key matrix in mt6779-keypad
- support for polled mode in adc-joystick driver
- other assorted driver fixes, cleanups and improvements
* tag 'input-for-v6.1-rc0' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: (90 commits)
Input: i8042 - fix refount leak on sparc
Input: i8042 - add LoongArch support in i8042-acpipnpio.h
Input: i8042 - rename i8042-x86ia64io.h to i8042-acpipnpio.h
Input: pinephone-keyboard - support the proxied I2C bus
Input: pinephone-keyboard - add PinePhone keyboard driver
dt-bindings: input: Add the PinePhone keyboard binding
dt-bindings: input: Convert hid-over-i2c to DT schema
input: drop empty comment blocks
Input: xpad - add X-Box Adaptive Profile button
Input: add ABS_PROFILE to uapi and documentation
Input: xpad - add X-Box Adaptive XBox button
Input: xpad - add X-Box Adaptive support
Input: ims-pcu - fix spelling mistake "BOOLTLOADER" -> "BOOTLOADER"
Input: ibm-panel - add missing MODULE_DEVICE_TABLE
Input: icn8505 - utilize acpi_get_subsystem_id()
Input: xpad - decipher xpadone packages with GIP defines
Input: xpad - refactor using BIT() macro
Input: synaptics-rmi4 - convert to use sysfs_emit() APIs
Input: twl4030-pwrbutton - add missing of.h include
Input: applespi - replace zero-length array with DECLARE_FLEX_ARRAY() helper
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid
Pull HID updates from Benjamin Tissoires:
- handle of all Logitech Bluetooth HID++ devices in the Logitech HID++
drivers (Bastien Nocera)
- fix broken atomic checks in hid-multitouch by adding memory barriers
(Andri Yngvason)
- better handling of devices with AMD SFH1.1 (Basavaraj Natikar)
- better support of Nintendo clone controllers (Icenowy Zheng and
Johnothan King)
- Support for various RC controllers (Marcus Folkesson)
- Add UGEEv2 support in hid-uclogic (XP-PEN Deco Pro S and Parblo A610
PRO) (José Expósito)
- some conversions to use dev_groups (Greg Kroah-Hartman)
- HID-BPF preparatory patches, mostly to convert blank defines as enums
(Benjamin Tissoires)
* tag 'for-linus-2022100501' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid: (38 commits)
HID: wacom: add three styli to wacom_intuos_get_tool_type
HID: amd_sfh: Handle condition of "no sensors" for SFH1.1
HID: amd_sfh: Change dev_err to dev_dbg for additional debug info
HID: nintendo: check analog user calibration for plausibility
HID: nintendo: deregister home LED when it fails
HID: roccat: Fix use-after-free in roccat_read()
hid: topre: Add driver fixing report descriptor
HID: multitouch: Add memory barriers
HID: convert defines of HID class requests into a proper enum
HID: export hid_report_type to uapi
HID: core: store the unique system identifier in hid_device
HID: Add driver for PhoenixRC Flight Controller
HID: Add driver for VRC-2 Car Controller
HID: sony: Fix double word in comments
hid: hid-logitech-hidpp: avoid unnecessary assignments in hidpp_connect_event
HID: logitech-hidpp: Detect hi-res scrolling support
HID: logitech-hidpp: Remove hard-coded "Sw. Id." for HID++ 2.0 commands
HID: logitech-hidpp: Fix "Sw. Id." for HID++ 2.0 commands
HID: logitech-hidpp: Remove special-casing of Bluetooth devices
HID: logitech-hidpp: Enable HID++ for all the Logitech Bluetooth devices
...
|
|
- convert to use dev_groups (Greg Kroah-Hartman)
|
|
- compilation warning fix (Jiangshan Yi)
|
|
- Simplify comments (Christophe JAILLET)
|