Re: Wheel scrolling: config to increase scrolling "distance" for each wheel click
On Sun, 2022-08-07 at 19:59 +0200, Sébastien Wilmet wrote: > with udev and hwdb, maybe? To fake the click angle. Here is what I tried: /etc/udev/hwdb.d/71-mouse-local.hwdb content: ``` mouse:* MOUSE_WHEEL_CLICK_ANGLE=45 ``` # systemd-hwdb --strict update && echo OK OK (then a reboot or a udevadm trigger). But it changes nothing for the scroll "speed" / "distance". Cheers, Sébastien
Re: How to test whether a buffer is in linear format
On 8/6/22, Hoosier, Matt wrote: > Any idea what’s up with some compositors adding code to infer > DRM_FORMAT_MOD_LINEAR semantics when the buffer’s modifiers are set to 0? > Wlroots, for example, added this as a “safety net for drm drivers not > announcing modifiers”. > > https://source.puri.sm/Librem5/wlroots/-/merge_requests/63 For the record, that's an old piece of code from a branch that hasn't been used for a long time already, so don't pay attention to it. See https://github.com/swaywm/wlroots/pull/2090 for details. Cheers, Sebastian
Wheel scrolling: config to increase scrolling "distance" for each wheel click
Hi, In order for me to move away from X11 and to use Wayland, I need a replacement for the imwheel program. With many applications on GNOME, a single wheel click scrolls a too small distance (in pixels). I had a wrist inflammation several years ago, which led me to use imwheel to scroll "faster", to require less wheel clicks to scroll the same distance. I use a multiplier of 3: for each "click", three clicks are sent. So it's as if the scrolling wheel works 3 times faster. I will attach my .imwheelrc config file, it can be useful. I've read the relevant libinput docs, but it seems that this aspect is not configurable. Is it with udev and hwdb, maybe? To fake the click angle. Some programs like Firefox provides a config for that, but not GTK or GNOME, AFAIK. Maybe Qt/KDE provides such a config? In all cases, if this feature is currently lacking (with an easy-to-use configuration GUI, e.g. in gnome-control-center), where is the best place to implement the configuration? imwheel has the advantage that it works for all programs, so my initial thought is that udev, hwdb or libinput would be a good place, then a GUI to tune the config can be written. If you have a link to some docs that I might have missed, or any pointers, these will be much appreciated. I'm not the only person on Linux who wants to configure this, after a quick web search. Thanks in advance, Sébastien # Should use imwheel --kill to restart imwheel, # imwheel must be set to autostart in your DE tools. # First line: match all apps. # '3' is the multiplier # # https://unix.stackexchange.com/questions/307663/change-scroll-speed-with-libinput/307932 # I've tried with the hwdb solution, but it didn't work. # # http://www.webupd8.org/2015/12/how-to-change-mouse-scroll-wheel-speed.html ".*" None, Up, Button4, 3 None, Down, Button5, 3 Control_L, Up, Control_L|Button4 Control_L, Down, Control_L|Button5 Shift_L, Up, Shift_L|Button4 Shift_L, Down, Shift_L|Button5
Window monitor-selection under Wayland
Recently the discussion on window-positions reminded me of an issue that Blender is likely to run into when switching to Wayland (currently work-in-progress). While as far as I can tell window-positions aren't necessary - Blender users frequently run with multiple-monitors and have windows dedicated to a task. Users *really* care about this [see links below], if you're working with an animation time-line on one monitor and your 3D view on the other for example - having to arrange windows on monitors every time you reload your file isn't nice. An argument could be made that the compositor should detect this case and handle it usefully, (a single application creating multiple maximized windows for e.g. could assign each to a separate monitor), although it seems likely the window order wouldn't be maintained. Checking Gnome-shell, multiple windows are assigned to different monitors - but only when full-screen. What would work well for Blender instead of absolute window positioning would be a way to hint which head (monitor) to use. The compositor would be free to ignore the hint, but in situations where the number of physical monitors doesn't change, this would allow users to re-open their projects and have the windows positioned as expected. Some bug reports relating to windows opening on the same monitor, unrelated to Wayland, just an example that users find the functionality important. https://developer.blender.org/T34962 https://developer.blender.org/T34391 https://developer.blender.org/T36707 https://developer.blender.org/T42092 -- - Campbell
Re: Window monitor-selection under Wayland
Hi, The xdg-session-management protocol extension [1] should help with that. Thanks, Simon [1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18
