On Sun, Dec 16, 2018 at 05:42:53PM +0000, Robert Burcham wrote: > More information: > > hid_magicmouse is driving the device: > > [Tue Nov 13 08:40:35 2018] magicmouse 0005:05AC:030D.0005: unknown main item tag 0x0 > [Tue Nov 13 08:40:35 2018] input: rburcham’s Mouse as /devices/virtual/misc/uhid/0005:05AC:030D.0005/input/input25 > [Tue Nov 13 08:40:35 2018] magicmouse 0005:05AC:030D.0005: input,hidraw4: BLUETOOTH HID v3.06 Mouse [rburcham’s Mouse] on [redacted] > > hid_magicmouse is reporting the params: > > $ grep "" /sys/module/hid_magicmouse/parameters/* > /sys/module/hid_magicmouse/parameters/emulate_3button:Y > /sys/module/hid_magicmouse/parameters/emulate_scroll_wheel:Y > /sys/module/hid_magicmouse/parameters/report_undeciphered:N > /sys/module/hid_magicmouse/parameters/scroll_acceleration:N > /sys/module/hid_magicmouse/parameters/scroll_speed:32 > > > libinput wants to do the right thing: > > $ xinput list-props 19 > Device 'rburcham’s Mouse': > Device Enabled (155): 1 > Coordinate Transformation Matrix (157): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 > Device Accel Profile (286): 0 > Device Accel Constant Deceleration (287): 1.000000 > Device Accel Adaptive Deceleration (288): 1.000000 > Device Accel Velocity Scaling (289): 10.000000 > Device Product ID (279): 1452, 781 > Device Node (278): "/dev/input/event21" > Evdev Axis Inversion (595): 0, 0 ftr, if the properties start with "Evdev", you're using the evdev driver, not libinput. for libinput testing, I recommend using 'libinput debug-events' anyway, it takes X out of the picture and narrows down where things don't work. [...] > $ xinput get-button-map 19 > 1 2 3 4 5 6 7 > > > But issuing 'xinput test 19' and attempting any touch-scroll or middle > click results in no events being received by libinput. So I have to > conclude hid_magicmouse is not sending them, despite the state of the > module's parameters. file a bug against libinput with an evemu recording attached (or libinput record, it does the same job). Could still be a libinput bug. Cheers, Peter > > > On Sun, 2018-12-09 at 13:50 -0600, Robert Burcham wrote: > > In 4.19 kernels I have been unable to drive a bluetooth gen-1 > > magicmouse as anything other than a stock 2-button mouse. Regardless of > > config or params the driver refuses to send events for middle button or > > any touch v-scroll and h-scroll actions. > > > > I think this patch last year introduced proper middle button and touch > > scroll support: > > > > https://lkml.org/lkml/2017/4/7/109 > > > > This patch moves the __set_bit calls for touch and tap events to a > > higher scope when setting up the device. However sometime since then > > there has been some sort of regression. There appears to have been > > some general refactoring around magicmouse_raw_event and > > magicmouse_setup_input that I suspect has reintroduced the more > > restrictive scope for those __set_bit calls. > > > > I post this in the hope that it might jog the memory of someone > > familiar with the hid-magicmouse diver, so we can get a proper magicmouse support restored to the kernel.
