Regardless of wireless mouse I use: Logitech(M510, M705, or MX Master 3)... With the mouse wheel in freewheel mode, flicking the wheel for fast scroll up or down works well. However, slow scrolling _up_ works acceptably; but trying to scroll _down_, I can roll the wheel and may get slight movement if at all. I can roll the wheel several times with no movement. This occurs only on a sheet. It is so intermittent, that the sheet often can't decide whether to move up or down when scrolling down. Opening Tools>Customize...>Menus' Available Commands list scrolls beautifully. Tools>Options... & expanding all the selections to get a scrollable list also works flawlessly. Only scrolling a sheet has this issue (that I've found) -- have not found any other application with this issue. This usually requires I grab the scroll bar to scroll reliably. My daughter is not seeing this issue on Windows with MX Master 3.
Testing with xev, button 4 (up) and button5 (down) show no sign of this problem. The reported button is correct. xev is not the easiest to monitor mouse events with; but the MX Master 3 mouse appears to provide an event every 15 degrees of rotation (24 events per rotation). ButtonRelease event, serial 40, synthetic NO, window 0x6800001, root 0x6ba, subw 0x0, time 433266337, (146,146), root:(2066,177), state 0x810, button 4, same_screen YES ButtonRelease event, serial 40, synthetic NO, window 0x6800001, root 0x6ba, subw 0x0, time 433249417, (146,146), root:(2066,177), state 0x1010, button 5, same_screen YES gdb has not helped me see mouse events. strace shows too much. After close observation and selective grep'ing, nothing obvious/useful. More info: All of the following scroll smoothly in both directions. Font selector and font aize All Gallery images Control wheel to increase/decrease cell size to maximum/minimum size Fast scroll sheet in either direction. (Puzzling why this is not affected) Scroll up seems fine. The only scroll issue I see is scroll down of the sheet. This makes little sense; but that's what I see... This is on a brand new, very capable Dell: Operating System: Mageia 9 KDE Plasma Version: 5.23.4 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.2 Kernel Version: 5.16.18-server-1.mga9 (64-bit) Graphics Platform: X11 Processors: 20 × 12th Gen Intel® Core™ i7-12700K Memory: 62.5 GiB of RAM Graphics Processor: AMD Radeon RX 6600 XT
More info... This issue occurs regardless of mouse or its communication mode via: - Logitech Unifying Receiver - Bluetooth Problem does not occur on LO 7.2.5.2.0+ running on Dell M6800 laptop running Mageia 8. However, if I ssh from mga9 system to mga8 and start LO remotely, the problem occurs. So the issue seems localized to whatever LO 7.3.1.3 component(s) is needed to display spreadsheet locally.
Pierre do you have another mouse with a cable for testing?
Wired mice; none of which have fast or freewheel mode: OK - no-name MO-5013U OK - Sunsonny T-M30 OK - Dell MS116t1 ...but keep reading... :) Wireless mice: ** - Logitech wireless MX Master 3 via any Unifying Receiver [1] [5] Wireless PID : 4082 Protocol : HID++ 4.5 Polling rate : 8 ms (125Hz) Serial : BE8AC05F Bootloader : BOT 95.01.B0015 Firmware : MPM 19.01.B0015 ** - Logitech wireless MX Master 3 via Bluetooth [1] [3] [5] Address: E4:7C:21:41:6E:3C ** - Logitech wireless M705 via any Unifying Receiver [1] [5] Wireless PID : 406D Protocol : HID++ 4.5 Polling rate : 8 ms (125Hz) Serial : 8A4D80FB Unit ID : EBBD0AEF Bootloader : BOT 59.00.B0002 Firmware : RQM 67.10.B0009 OK - Logitech wireless M510v2 via any Unifying Receiver [1] [2] [4] Wireless PID : 4051 Protocol : HID++ 2.0 Polling rate : 8 ms (125Hz) Serial : 7FC9DEE6 Firmware : RQM 62.01.B0015 I also have a really low-end Logitech M215; but it uses a dedicated receiver, and doesn't have fast scroll, so I won't waste my time with it. I expect it will act as the wired mice and the M510v2. ** Only these two mice have fast/freewheel mode. Unifying Receiver A: (MX Master 3, M705[++], M510v2) Path : /dev/hidraw1 USB ID : 046d:C52B Serial : 56099AD8 Firmware : 12.11.B0032 Bootloader : 04.16 Other : AA.AA Unifying Receiver B: (MX Master 3[++], M705, M510v2) Path : /dev/hidraw1 USB ID : 046d:C52B Serial : E05593CA Bootloader : BOT 95.01.B0015 Firmware : MPM 19.01.B0015 Other : Unifying Receiver C: (MX Master 3, M705, M510v2[++]) Path : /dev/hidraw1 USB ID : 046d:C52B Serial : 7FC9DEE6 Firmware : 12.11.B0032 Bootloader : 04.16 Other : AA.AA [++] indicates the mouse this UR was paired with in the respective package. [**] slow scrolling issue in both freewheel and ratchet modes; BUT fast freewheel scrolling (via finger flick) works fine. [1] Down scrolling is as reported. However, scrolling this bug report in Firefox Nightly 101.0a1 is smooth in both directions, as in any other application, including within oocalc's font/font-size selectors, Gallery>Diagrams, or anything else that is scrollable in oocalc. [2] No freewheel mode on this one. [3] This mouse can be paired with 3 receivers -- any combination of UR and/or Bluetooth to 1, 2 or 3 computers; there's a selector to switch between hosts. [4] The Logitech M510v2 wireless mouse does not have fast/freewheel mode, so it acts just like the wired mice. [5] Scrolling down fails in both freewheel and ratchet modes. HTH... LOL... I'm reminded of "be careful what you ask for". Seriously, the only common denominator (so far) is fast/freewheel capable mice. Ruminating... This reminds me of interrupt handlers that don't re-enable interrupts fast enough; but will keep processing queued ones without have to re-enable because there's still work to do... Does calc have code that is "uninterruptable" (some form of software lock)? But darn, this is a super fast machine... Other than positive/negative values for direction, scrolling should be using the same code paths... hmm... are they?
[Automated Action] NeedInfo-To-Unconfirmed
No surprise: System Settings > Input Devices > Mouse: Scrolling: [X] Invert scroll direction changed the direction of the problem. Only scrolling cells is affected; all other scrollable items in LO calc are fine.
Installed Apache OpenOffice. It does not have this scrolling issue.
Opened a PDF file in oowriter and the missing mouse events occur in both directions when slow-scrolling. Fast scrolling works; but it is more important to be able to hone in with slow scroll.
Issue still present in LO 7.3.3.2
Another clue... Using the Logitech MX Master 3 mouse, using the thumb wheel for horizontal scrolling works as expected. Using Shift+wheel (the usual wheel) for horizontal scrolling, up becomes left which works fine. Right(down) is problematic as above.
This issue is still present in 7.5
Last version tested was about 2 weeks ago. This version is working fine so far: Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: 24087697d5cf78aac346d4dcea0596373e15a95c CPU threads: 20; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Jumbo However, it appears this may be due to multiple mouse models... I purchased a Logitech MX Master 3S which works fine. The original MX Master 3 (not 3S) still exhibits the issue... MX Master 3S info: Path : /dev/hidraw5 Index : 255 Product ID : 046d:B034 Protocol : HID++ 4.5 Serial : Unit ID : 0A0BDDC3 Bootloader : BL1 69.00.B0003 Firmware : RBM 22.00.B0003 Other : Notifications: (none) Looks like MX Master 3 is the source of this issue. No idea if this is problematic with this particular mouse or the entire production...