Opened 2 years ago
Last modified 6 months ago
#18108 new bug
Touchpad (i2c-PIXA3854:00 093A:0274) only recognized as PS/2 mouse, not working after rebooting from other operating systems
Reported by: | taos | Owned by: | PreetpalKaur |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Drivers/Input | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description (last modified by )
With hrev56595 64bit, my touchpad only works (partially - only left click available) after a cold boot into Haiku - or after then rebooting from Haiku into Haiku again. Haiku is usually started via rEFInd (but starting directly from an anyboot image doesn't change the observed behaviour).
Switching (in UEFI BIOS) the touchpad PS/2 emulation from 'automatic' to 'on' or 'off' doesn't change this. I can't find the touchpad model mentioned in syslog (or via listdev
or listusb
- outputs are attached).
The touchpad works as multitouch device in Windows 11 (after driver installation), Linux, and OpenBSD. libinput list-devices
under linux sees it as PIXA3854:00 093A:0274 Touchpad
. dmesg | grep PIXA
then results in:
dmesg | grep PIXA [ 6.511030] input: PIXA3854:00 093A:0274 Mouse as /devices/pci0000:00/0000:00:15.3/i2c_designware.2/i2c-16/i2c-PIXA3854:00/0018:093A:0274.0002/input/input9 [ 6.511234] input: PIXA3854:00 093A:0274 Touchpad as /devices/pci0000:00/0000:00:15.3/i2c_designware.2/i2c-16/i2c-PIXA3854:00/0018:093A:0274.0002/input/input10 [ 6.511470] hid-generic 0018:093A:0274.0002: input,hidraw1: I2C HID v1.00 Mouse [PIXA3854:00 093A:0274] on i2c-PIXA3854:00 [ 11.051765] input: PIXA3854:00 093A:0274 Mouse as /devices/pci0000:00/0000:00:15.3/i2c_designware.2/i2c-16/i2c-PIXA3854:00/0018:093A:0274.0002/input/input27 [ 11.086455] input: PIXA3854:00 093A:0274 Touchpad as /devices/pci0000:00/0000:00:15.3/i2c_designware.2/i2c-16/i2c-PIXA3854:00/0018:093A:0274.0002/input/input28 [ 11.086801] hid-multitouch 0018:093A:0274.0002: input,hidraw0: I2C HID v1.00 Mouse [PIXA3854:00 093A:0274] on i2c-PIXA3854:00
Edit: It might be a PixArt PCT3854QR touchpad.
Attachments (3)
Change History (9)
by , 2 years ago
Attachment: | listdev_hrev56959.txt added |
---|
comment:2 by , 2 years ago
Framework Laptop (12th Gen Intel Core)
According to frame.work it might have a PixArt PCT3854QR touchpad.
comment:3 by , 2 years ago
Description: | modified (diff) |
---|
comment:4 by , 6 months ago
With UEFI BIOS versions 3.06 (in beta state for ~ 1 year) and 3.08 (released as stable last month) PS/2 emulation of the laptop got fixed ('auto' now means on, 'disabled' means off, and 'on' isn't an option anymore) and the touchpad started to work in Haiku as one-button mouse - even after rebooting from another operating system. How well, however, depends on Haiku revision.
At first, you had to press really hard to get a click registered by Haiku, then after a while even tap-to-click started to work (great times!). After an another Haiku update, just touching the touchpad to move the cursor frequently produced unintended right(?) clicks which opened context menus in inconvenient places. Usually, these context menus could be dismissed with the ESC key, so using Haiku with only the touchpad was still okay.
After updating from hrev57719 to hrev57734, the touchpad now stopped working completely (no matter which option is chosen in UEFI BIOS). It is still shown as PS/2 mouse in Input (if PS2/emulation is set to 'auto'), but doesn't react to any touch, tap or hard press. It is necessary to plug in a USB mouse for everything that can't be done with the keyboard alone.
I don't have another laptop that uses PS/2 emulation, so I can't check if this is hardware-specific or not.
follow-up: 6 comment:5 by , 6 months ago
comment:6 by , 6 months ago
Replying to waddlesplash:
Yep :-) Sorry.
I've updated to hrev57737 and the former behaviour of the touchpad after rebooting from Windows/OpenBSD/Linux to Haiku is restored (touching/moving the cursor frequently results in unintended right-clicks, and each tap-to-left-click also immediately produces a right-click). So, just an unfortunate race condition, timing issue, or similar?
output of listdev