Debian Patches
Status for bucklespring/1.5.1-3
| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| cross.patch | Fix FTCBFS: hard codes build architecture build tools | Helmut Grohne <helmut@subdivi.de> | no | debian | 2026-08-31 | |
| libinput-mouse-click.patch | libinput: click on mouse buttons and the scroll wheel The X11 backend plays the ff-*.wav click sound on the left and right mouse buttons; the libinput backend only ever looked at keyboard events. Handle pointer buttons there too, so that the two backends behave the same. Sound the scroll wheel as well, which neither backend did. A wheel reports in the v120 units libinput took from Windows, 120 to a detent, and a high resolution wheel sends fractions of that, so the remainder is carried to the next event rather than rounded away. A detent has no press and release of its own, so it makes a single click. Only a wheel is followed, not the smooth two finger scrolling of a touchpad, which has no detents to click for. |
"Barak A. Pearlmutter" <bap@debian.org> | no | 2026-08-31 | ||
| 0003-add-Library.patch | add Library | Matin6725 <Matin6725@gmail.com> | no | 2025-03-21 | ||
| 0004-fix-stereo-width-option-not-working.patch | fix --stereo-width option not working | Danilo Rezende <50598421+returnDanilo@users.noreply.github.com> | no | 2024-02-03 | ||
| usage-text-typos.patch | fix a couple of typos in the usage text The long option is spelled --audio-path, not --audi-path, and the library is OpenAL. This matters more than it used to, as the manual pages are generated from this text, so a wrong option name here becomes a wrong option name in buckle-x11(1) and buckle-libinput(1). |
tensorknower69 <latesight20@protonmail.com> | no | upstream, https://github.com/zevv/bucklespring/commit/3178013 | 2021-10-29 | |
| usage-text-help2man.patch | capitalise Usage: and Options: in the usage text The Debian packages generate buckle-x11(1) and buckle-libinput(1) from this text with help2man(1), so that an option added to the program turns up in its manual page without anyone having to write it down a second time. help2man recognises the synopsis line and the start of the option list by matching "Usage:" and "Options:", case sensitively, and puts everything it does not recognise in one undifferentiated DESCRIPTION. Capitalising the two headings is also what the GNU coding standards ask for. |
"Barak A. Pearlmutter" <bap@debian.org> | no | 2026-09-07 | ||
| repeat.patch | play a sound each time a held key auto repeats Holding a key down made one click and then silence, however many characters it went on to produce. Click for every repeat instead, and add --no-repeat for those who preferred it the other way. The two backends learn of a repeat differently. The X server marks the KeyPress events it generates while a key is held, which the backend already recognised and then deliberately threw away, and sends no KeyRelease in between, so there it is a matter of no longer discarding them. libinput drops the kernel's repeat events outright, "ignore kernel key repeat" in evdev-fallback.c, and leaves repeating to its caller, so that backend has to keep its own clock, and the question becomes how fast to run it. Wayland is no help in the way X11 is: a compositor sends no event per repeat at all. It tells each client the delay and the rate once, in wl_keyboard.repeat_info, and every client then runs a timer of its own, so the repeats that put characters on the screen exist only inside whichever client holds the keyboard focus and there is nothing for a bystander to follow. The two numbers can be had for the asking, though, and they are worth asking for, because a compositor keeps its setting to itself: the kernel's repeat, which is what EVIOCGREP on the device reports, stays at its 250 ms and 33 ms default however the desktop is configured. Here GNOME is set to 500 ms and 30 ms, so timing the clicks off the device would start them a quarter of a second before the first character appeared and leave them running ahead for as long as the key was held. So the libinput backend connects to the compositor for the sole purpose of reading repeat_info, and keeps the connection polled, since the setting can change while we run. Failing that it asks the device, which is the right answer on a console, and failing that it falls back to the kernel defaults. --repeat-delay and --repeat-rate override the lot. The kernel repeats modifiers too, unlike XKB, so the libinput backend leaves them out; hearing shift chatter while it is held would be odd, and it also keeps a held key from drumming out the mute sequence of three taps on scroll lock. |
"Barak A. Pearlmutter" <bap@debian.org> | no | 2026-09-07 | ||
| mouse-event-selection.patch | --mouse, to choose which mouse events click Both backends now sound the scroll wheel as well as the buttons, and between them they can see rather more of a mouse than the two buttons the X11 backend started with. Not everybody wants all of it: a wheel that clicks is charming until you scroll a long page, and the thumb buttons are not what anyone remembers a Model M for. Add --mouse, taking a comma separated list of left, middle, right, side, extra, wheel and hwheel, with all, the default, and none at the ends of it. The list is parsed once into a bit set that both backends consult through mouse_enabled(), so the same name means the same thing whichever flavour is running, even though X numbers the buttons from one and the kernel calls them BTN_LEFT and friends. This also fills in what the X11 backend had been ignoring. It played only buttons 1 and 3; it now knows the middle button, the wheel as buttons 4 to 7, and the thumb buttons as 8 and 9. A wheel detent reaches X as a press and a release together, so only the press is sounded, one click per detent, which is what the libinput backend does with the v120 units it gets instead. |
"Barak A. Pearlmutter" <bap@debian.org> | no | 2026-09-08 | ||
| version-option.patch | add --version Every other program has one, and help2man wants one: without it the version in the manual page footer has to be passed in on the side, from the packaging, where it can quietly fall out of step with the program. The output follows the GNU coding standards, so help2man makes the COPYRIGHT and AUTHOR sections of the page out of it and neither can drift. It goes to stdout, as the standards say. The version and the package name are taken from PACKAGE_VERSION and PACKAGE_NAME, the names autoconf uses, behind the customary #ifdef HAVE_CONFIG_H #include <config.h> #endif and #ifndef fallbacks to what the shipped Makefile passes in. Should the build ever move to autoconf and automake, AC_CONFIG_HEADERS is then the whole of the change: the fallbacks stop being reached and nothing here is touched. The include sits above the system headers, which is where it has to be, as config.h is where autoconf puts the feature test macros that decide what those headers declare. |
"Barak A. Pearlmutter" <bap@debian.org> | no | 2026-09-08 | ||
| usage-to-stdout.patch | print the usage text on stdout when it was asked for --help went to stderr, which makes it awkward to pipe into a pager or a grep and is not where the GNU coding standards put it: output asked for belongs on stdout, and only a complaint about the command line belongs on stderr. Pass the exit status down to usage() and pick the stream from it, the usual arrangement, so --help still reads as an answer while an unparseable option still reads as an error. --version already went to stdout. Programs that document themselves with help2man no longer need to be run with --no-discard-stderr once both do. |
"Barak A. Pearlmutter" <bap@debian.org> | no | 2026-09-08 |