On Windows, most programs with large, scrollable text containers (e.g. all browsers, most word processors and IDEs) let you press the middle mouse button and then move the mouse to scroll. This scrolling is smooth and allows you to scroll very quickly using just the mouse. When I've used Linux on *laptops*, two-finger scrolling performs roughly the same function; it's easy to scroll down a page quickly (much more quickly than one can by scrolling a mouse wheel) but the scrolling remains smooth enough to allow precise positioning. I am unsure how to achieve the same thing when running Linux on a Desktop with a mouse. As far as I can tell after a whole bunch of Googling, there are neither application-specific settings to swap to Windows-style middle mouse button behaviour, nor any system-wide settings to achieve the same effect. Just to make this concrete, let's say - if it's relevant - that I'm asking in the context of Firefox, Google Chrome, Gedit and Eclipse on a recent version of either Mint (what I use at home) or Ubuntu (what I use at work). I suspect this is a fairly distro-agnostic and application-agnostic question, though. As far as I can tell, my options for scrolling are: * Scroll with the mousewheel - slow! * Use the PgUp / PgDn keys - jumps a huge distance at a time so can't be used for precise positioning, and is less comfortable than using the mouse * Drag the scroll bar at the right hand side of the screen up and down like I used to do on old Windows PCs with two-button mice. This is what I do in practice, but it's just plain less comfortable than Windows-style middle-mouse scrolling; on a huge widescreen, it takes me most of a second just to move the cursor over from the middle of the screen to the scrollbar, and most of a second to move it back again, and I have to take my eyes off the content I'm actually scrolling to do this. None of these satisfy me! This UI issue is the single thing that poisons my enjoyment of Linux on desktops and almost makes me wish I was using a laptop touchpad instead of a mouse. It irritates me enough that I've concluded that either I'm missing some basic Linux UI feature that solves this problem, or I'm just an oversensitive freak and it doesn't even bother anyone else - but I'm not sure which. So my questions are: 1. Does Windows-style middle mouse button scrolling exist anywhere in the Linux world, or is it really purely a Windows thing? In particular, do any Linux web browsers let you use Windows-style scrolling? 2. Are there any mechanisms for scrolling pages that exist in Linux but not in Windows, especially ones that perform the role I've described? 3. Any other solutions that I'm missing?

So, my Scroll Lock key doesn't have much use, while I keep hitting Ctrl+S with no intention of stopping control flow. I know how to disable Ctrl+S from locking scroll (stty -ixon), but can I use Scroll Lock key instead for the same use? **- UPDATE -** In my terminal Scroll Lock does not stop control flow. My question is how to assign that function to that key.

In a terminal, are there any shortcuts to jump to a previous/next prompt? Scrolling up and trying to find the start of a log slows down my workflow. I'm using iTerm on OSX, but this should be applicable to any Unix terminals. A solution in Tmux would help as well.

I'm having difficulty finding an explanation for allowing the OS default copy/paste capabilities (i.e. highlight a portion of text and then use standard shortcut or right-click menu) and allow mouse scrolling at the same time. Mouse mode turns on tmux's own copy/paste system, but leaving it off removes the mouse scrolling. As I'm switching between an IDE, browser, and terminal with tmux I would like the controls to be consistent between all of them. Is there a way to have the standard OS copy/paste controls while also allowing the mouse to scroll in tmux? _(Note: I originally asked, but deleted, this question on SO. I decided it was more appropriate here.)_

My mouse scrolling is inverted I have taken a look at this post: https://jamesmcdonald.com/2011/07/invert-mouse-scroll-wheel-in-debian/ But my config is like this: Section "InputClass" Identifier "evdev pointer catchall" MatchIsPointer "on" Option "ButtonMapping" "1 2 3 5 4 6 7 8" MatchDevicePath "/dev/input/event*" Driver "evdev" EndSection With the Option "ButtonMapping" "1 2 3 5 4 6 7 8" I have also enabled "natural scrolling" but no luck Anyone has come accross the same issue and solved it¿? Thank you in advance

When I use Dolphin File Manager in Detail View mode, for some reason there is an unnecessary horizontal scrollbar if I adjust my columns to fill the screen. The only way to get rid of the scrollbar is to make my columns much narrower and leave a huge gap on the right edge. I have tried turning "Side Padding" on and off, but it only seems to affect padding on the left side, not on the right. The undesired scrollbar is visible in the screenshot across the bottom edge of the main window panel. How can I eliminate this? I am on Dolphin 25.04.0 with KDE Plasma 6.3.5 on Arch Linux (kernel 6.14.5-arch1-1).

Mouse scroll performance is poor in Linux and there is no built-in method to control the same. Hence, I did some digging and came across IMWheel. I followed this tutorial How to Adjust or Increase Mouse Scroll Wheel Speed in Linux and set my mouse scroll speed to 5. This seemed to fix my physical mouse scroll speed. However, scrolling using the touchpad of my laptop is anything but perfect. The page seems to behave erratically and jumps every time a certain amount of page is scrolled and is very unpleasant. On disabling IMWheel, the touchpad behavior seems to return back to normal. Is there any method to have a decent scroll speed for physical mouse and yet keep the existing scrolling experience for the touchpad in Linux? Like it is there in Windows? If there is, please guide me on how to fix this issue. This problem literally keeps me from using Linux at all! Given below are my current mouse and touchpad settings: Current Mouse settings: Current Touchpad settings: Hardware and Software Details: - OS: Linux Mint Cinnamon 19.1 - Laptop: HP AB032TX (Dual Boot: Windows 10 & Linux Mint) - Software in question: IMWheel - Touchpad Driver: Synaptics (Default drivers that came with Mint) - Physical Mouse: Logitech normal optical mouse

**Stop reading if uname -r returns a Linux version greater than 5.9**, since scrollback has been simply removed (1 , 2 ). ---- My keyboard does not have separate PgUp and PgDown keys. They are in the numpad, sharing their position with KP_9 and KP_3. Scrolling terminals with Shift+Pg{Up,Down} was not possible either with Numlock on or off. Since I don't care for the keypad numbers but do care a lot for scrolling, I have successfully remapped them in X11 to "Prior" and "Next" regardless of Numlock state, and now Shift+{PgUp,Down} both work in Xterm. However, I can't achieve the same in the TTY. With other keyboards that had exclusive Page keys, I could use Shift+PgUp to scroll back after cating a large file, for example. ### Original keycodes As of showkeys:

KP_3/KP_PgUp   = 73
KP_9/KP_PgDown = 81
Slash          = 89
Right Shift    = 54

As of dumpkeys:

PgUp   = 104
PgDown = 109

Slash and Right Shift were also listed because I will also swap them just for testing. ### Attempts - Modified /etc/console-setup/remap.inc to exactly this:

keycode 73 = Prior
    shift keycode 73 = Scroll_Backward
    shift shiftl  keycode 73 = Scroll_Backward
    shift shiftr  keycode 73 = Scroll_Backward
    shift shiftl  shiftr  keycode 73 = Scroll_Backward
    shift ctrll keycode 73 = Scroll_Backward
    shift shiftl  ctrll keycode 73 = Scroll_Backward
    shift shiftr  ctrll keycode 73 = Scroll_Backward
    shift shiftl  shiftr  ctrll keycode 73 = Scroll_Backward 
  keycode 81 = Next
    shift keycode 81 = Scroll_Forward
    shift shiftl  keycode 81 = Scroll_Forward
    shift shiftr  keycode 81 = Scroll_Forward
    shift shiftl  shiftr  keycode 81 = Scroll_Forward
    shift ctrll keycode 81 = Scroll_Forward
    shift shiftl  ctrll keycode 81 = Scroll_Forward
    shift shiftr  ctrll keycode 81 = Scroll_Forward
    shift shiftl  shiftr  ctrll keycode 81 = Scroll_Forward  
  keycode  89 = Shift
  keycode  54 = slash
    shift keycode  54 = question
    altgr keycode  54 = degree
    shift altgr keycode  54 = questiondown

- Followed the instructions of How to change console keymap in Linux? .

dumpkeys > pageupdown

Then swapped

keycode 73  keycode 104
  keycode 81  keycode 109
  keycode 54  keycode 89

in that file and issued loadkeys -s pageupdown. ### Results In both experiments, - Although the two keypad keys don't print numbers anymore and PgUp still works (it scrolls in less) as desired, Shift+PgUp does not scroll the TTY. - Right Shift and Slash have been correctly swapped. ### Additional notes - Toggling Numlock does not help in any of the configurations. The Fn key also does not have any effect in those keys. - I have also tried mapping more ordinary keys, namely l and p, to the Page actions, without success. - If it helps in any way, this is the XKB map that works in the X session:

partial keypad_keys
  xkb_symbols "noKPNumbers" {
      key   {	[  Prior,	Prior	]	};
      key   {	[  Next,	Next	]	};
  };

How can I map the keypad PgUp and PgDown keys in such a way that Shift+Pg{Up,Down} scroll the TTY buffer? Is it possible at all?

I'm using less to parse HTTP access logs. I want to view everything neatly on single lines, so I'm using -S. The problem I have is that the first third of my terminal window is taken up with metadata that I don't care about. When I use my arrow keys to scroll right, I find that it scrolls past the start of the information that I do care about! I could just delete the start of each line, but I don't know if I may need that data in the future, and I'd rather not have to maintain separate files or run a script each time I want to view some logs. ### Example This line: > access.log00002:10.0.0.0 - USER_X [07/Nov/2013:16:50:50 +0000] "GET /some/long/URL" Would scroll to: ng/URL" ### Question Is there a way I can scroll in smaller increments, either by character or by word?

Gnome (or GTK) has introduced something I would personally hesitate to call a feature, since it looks and behaves like a bug, where when you grab a scroll bar thumb you're suddenly no longer moving it at the speed of your cursor (i.e. the way everything else in the entire mouse interface paradigm behaves) but you instead start moving it at some arbitrary slower speed. Apparently it's called *Smooth Scrolling* . This creation makes it difficult for me to scroll, because even if I hadn't found its actual design decisions highly questionable, it almost certainly also has a defective implementation which makes it needlessly disruptive — hence my question: **How do I turn this off?** The linked answer from 2020 above is to a distinctly different question, but mentions that it was not possible to disable it at the time. It seemed like a good idea to ask specifically for how to do this.

I'm usually inside GNU Screen or tmux, and that doesn't give me great scrolling functionality. Is there an alternative to tail -f that allows me to quickly scroll up? A tool that is like most is to less and more. *[This question](https://unix.stackexchange.com/questions/21808/tail-f-equivalent) is related but far from specific. I'm really looking for something that lets me scroll.*

Out of the box, this Logitech M325 mouse works great with one issue: cannot use the scroll wheel for horizontal scrolling. It acts as forward or back in the browsers or does nothing in other windows.

Sometimes if I git checkout, or even make, I end up with some unexpected output that makes me ask: > Wait, what? Let's see that again. My options are usually: 1. Move my hand over to the mouse and start scrolling in the terminal. - For commands like dpkg-buildpackage which fail due to a cmake configuration error, they print a massive amount of debug data after the error, so you REALLY have to scroll back a long long ways. 2. Rerun the command through | more. - but this doesn't work well for commands that change your local state like git checkout. - it's less useful for commands that take a really long time to complete. Is there a terminal that makes it easy to navigate the output of previous commands?

Apologies if this is a redundant post - I haven't found one specific name for the issue, nor one post describing the same triggers to the problem or solutions that work on my end. **Symptoms**: any mouse connected to the laptop will have a "deadzone"/null zone in scrolling whereas scrolling up and down by one click repeatedly won't do anything - e.g. in order to reverse my scrolling direction, I'll have to click the wheel *twice* in order to scroll once in the opposite direction. When scrolling continuously in any direction (after escaping the deadzone), each scroll notch corresponds correctly to one movement; the issue is purely when switching directions. This behavior seems to only ever happen in Firefox and Minecraft. I have yet to find other problematic programs. **Hardware**: The laptop is an Asus Zenbook 14 (UX3402ZA) dual booted, Windows 10 and Ubuntu, though I've had the same issue with Debian 12. The mouse I'm troubleshooting with is a Corsair Katar Wireless (paired via bluetooth), though the issue seems to behave exactly the same with other bluetooth, 2.4GHz, and wired mice. **Triggers**: As far as I can tell with bluetooth; once I pair the mouse successfully, all behavior is as expected *until* the touchpad is used to scroll. From that point, the above symptoms begin. A reboot and repairing of the mouse seems to revert behavior to normal (until the touchpad scrolls). Oddly, I could not replicate this behavior when booted to the Ubuntu live ISO which I had used for installation. When running Windows 10, the problem doesn't exist. **My Troubleshooting:** I've asked/searched around to no success, but I've read a few things; - The computer may not have enough resources or wiggle room to allocate (almost the same words I read - I didn't really understand this one) - According to this post , a user started experiencing this problem after upgrading to kernel 6.1. I subsequently installed Ubuntu 22.04.1 with kernel 5.15.0-43, in which the behavior remains unresolved. - Previously, when I had Debian 12 installed, I ran evtest while triggering the behavior - both before and and after, the mouse scroll appeared to be detected the exact same, whereas one click, regardless of "direction," showed one positive or negative reaction (for lack of better terminology) - like the normal behavior I would expect in Firefox/Minecraft. Below is an evtest clip from scrolling the mouse down/up/down/up, while the behavior was present;

Event: time 1722654009.094229, -------------- SYN_REPORT ------------
Event: time 1722654009.701843, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
Event: time 1722654009.701843, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), value -120
Event: time 1722654009.701843, -------------- SYN_REPORT ------------
Event: time 1722654010.519376, type 2 (EV_REL), code 8 (REL_WHEEL), value 1
Event: time 1722654010.519376, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), value 120
Event: time 1722654010.519376, -------------- SYN_REPORT ------------
Event: time 1722654011.299353, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
Event: time 1722654011.299353, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), value -120
Event: time 1722654011.299353, -------------- SYN_REPORT ------------
Event: time 1722654012.102271, type 2 (EV_REL), code 8 (REL_WHEEL), value 1
Event: time 1722654012.102271, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), value 120

As mentioned in the linked reddit post, there seems to be both high resolution and "normal" inputs being registered. My guess would be that using only the "normal" inputs would solve the problem, but I'm still a linux beginner and wouldn't want to start an XY problem lol. While I currently have Ubuntu installed, I'm also having this issue in Debian 12 (and possibly some other distros as well?) so I wouldn't mind having the issue resolved in either OS. Again, note that the issue was somehow not present in the live ISO before installation. **Update 1:** when using Xorg [X11?], the issue doesn't seem to exist (although I also realized that gestures only work in Wayland). I'll be troubleshooting the issue in Wayland. **Update 2:** firefox decided to update itself and it's no longer affected by the bug (while Minecraft is still affected). Smooth ["pixel-perfect"?] touchpad scrolling is also working in Firefox (as opposed to 3 lines at a time), which I think is new behavior. So maybe the problem is that Minecraft just doesn't properly recognize/handle high resolution scroll events?

I am using Debian Bookworm; Gnome 43.9; Wayland windowing system; Kernel 6.1.0-18-amd64 I was able to use xinput list xinput set-prop 11 "libinput Scroll Method Enabled" 0, 0, 1 # This is button xinput set-prop 11 "libinput Button Scrolling Button" 2 # This is middle mouse. Already 2 by default 11 is the ID of my rf mouse (found through xinput list) in cinnamon but this requires libinput also Xwayland doesn't play nicely with xinput for some reason. could someone please help me find a way to achieve the same result through Xwayland without installing libinput if it is possible?

I'm a relatively-new Linux user (Ubuntu 22.04) and something has recently started to bug me immensely - the lack of kinetic scrolling in many apps. After doing some digging, it seems that kinetic scrolling (at least in Ubuntu) *must* be implemented at the level of the applications. Contrast this with say, MacOS, which features kinetic scrolling as part of the operating system itself. That said - are there any distros that come "pre-packaged", as it were, with kinetic scrolling? EDIT: Hell, I'll even lower the bar - if anyone knows of a distro that allows me to simply *modify* something so that I use kinetic scrolling regardless of the app I'd be eternally in your debt.

I'd like to use the scroll wheel (xterm mouse escape codes) to scroll through man pages, like I can in emacs with xterm-mouse-mode. less doesn't seem to have support for that and short of recompiling it I can't find a way to add it. Is there a different pager I could use that supports the scroll wheel (or a way I could get less to do it)? I'd rather not give up bold and underline if possible. My emulator is iTerm2 on Mac OS X Yosemite, if that helps.

In Windows, I'm used to clicking the center button and it offering a "fast scroll" option up or down. How can I get this behavior on Linux? It currently seems to use the back button upon center click instead. I use Gnome under CentOS.

I am using the below configuration - setw -g mouse on to use mouse scrolling within tmux sessions. However, I notice the scrolling is not as smooth as an the Terminal. Is there any tweaking/configuration i need to apply in tmux config to make the user experience better?

I am using Fedora 14. Gnome Terminal 2.32.0. But there is no box for "unlimited scrolling". In fact, the number of lines I can scroll back is capped at 10,000. If I set it any higher, it will reset to 10,000. Also, I went to gconf-editor, and found a key "/apps/gnome-terminal/profiles/Default/scrollback_unlimited". I toggled this value, but still I am limited to 10,000 lines of scrollback. I read online unlimited scrollback was introduced in Gnome Terminal 2.28. Is there some sort of system-wide or security conf entry that I am not aware of? If so I can talk to the sysadmins to get that changed.