Lines Matching +full:libinput +full:- +full:test +full:- +full:suite +full:- +full:pointer
5 Contributing to libinput
9 So you want to contribute to libinput? Great! We'd love to help you be a part
15 ------------------------------------------------------------------------------
17 ------------------------------------------------------------------------------
19 As a freedesktop.org project, libinput follows the `freedesktop.org
27 ------------------------------------------------------------------------------
29 ------------------------------------------------------------------------------
32 `wayland-devel@lists.freedesktop.org
33 <https://lists.freedesktop.org/mailman/listinfo/wayland-devel>`_ mailing
36 For IRC, ping user ``whot`` (Peter Hutterer, the libinput maintainer) though
42 <https://gitlab.freedesktop.org/libinput/libinput/issues>`_. It's usually the
45 ------------------------------------------------------------------------------
47 ------------------------------------------------------------------------------
49 If you don't already know what you want to improve or fix with libinput,
51 tag in our `issue tracker <https://gitlab.freedesktop.org/libinput/libinput/issues?label_name%5B%5D…
53 possible future feature to libinput.
61 ------------------------------------------------------------------------------
63 ------------------------------------------------------------------------------
70 $> git clone https://gitlab.freedesktop.org/libinput/libinput
71 $> cd libinput
72 $> meson setup --prefix=/usr builddir/
73 $> ninja -C builddir/
74 $> sudo ninja -C builddir/ install
76 You can omit the last step if you only want to test locally.
78 ------------------------------------------------------------------------------
80 ------------------------------------------------------------------------------
83 `pre-commit <https://pre-commit.com/>`_ with these commands::
85 $> pre-commit install
86 $> pre-commit install --hook-type pre-push
91 libinput has a roughly three-parts architecture:
93 - the front-end code which handles the ``libinput_some_function()`` API calls in ``libinput.c``
94 - the generic evdev interface handling which maps those API calls to the
96 - there are device-specific backends which do most of the actual work -
97 ``evdev-mt-touchpad.c`` is the one for touchpads for example.
100 get implemented in the device-specific backend. You only need to touch the
104 <https://who-t.blogspot.com/2019/03/libinputs-internal-building-blocks.html>`_
107 Documentation is in ``/doc/api`` for the doxygen-generated API documentation.
108 These are extracted from the libinput source code directly. The
110 sphinx. Simply running ``ninja -C builddir`` will rebuild it and the final
113 ------------------------------------------------------------------------------
115 ------------------------------------------------------------------------------
117 libinput provides a bunch of :ref:`tools` to debug any changes - without
118 having to install libinput.
120 The two most useful ones are :ref:`libinput debug-events
121 <libinput-debug-events>` and :ref:`libinput debug-gui <libinput-debug-gui>`.
123 quick test iterations::
125 $> sudo ./builddir/libinput-debug-events --verbose
126 $> sudo ./builddir/libinput-debug-gui --verbose
130 trying to debug pointer movement or placement. ``libinput debug-gui`` will
131 also visualize the raw data from the device so you can compare pointer
134 These tools create a new libinput context and will not affect your session's
135 behavior. Only once you've installed libinput and restarted your session
139 :ref:`test-suite`::
141 $> sudo ./builddir/libinput-test-suite
143 This test suite can take test names etc. as arguments, have a look at
144 :ref:`test-suite` for more info. There are a bunch of other tests that are
147 $> sudo ninja -C builddir check
154 ------------------------------------------------------------------------------
156 ------------------------------------------------------------------------------
159 <https://docs.gitlab.com/ce/gitlab-basics/add-merge-request.htm>`_)
160 in the `libinput GitLab instance hosted by freedesktop.org
161 <https://gitlab.freedesktop.org/libinput/libinput>`_.
164 replace `learning git <https://git-scm.com/doc>`__ but they should be
167 - `Register an account <https://gitlab.freedesktop.org/users/sign_in>`_ in
169 - `Fork libinput <https://gitlab.freedesktop.org/libinput/libinput/-/forks/new>`_
171 - Get libinput's main repository. git will call this repository ``origin``. ::
173 git clone https://gitlab.freedesktop.org/libinput/libinput.git
175 - Add the forked git repository to your remotes (replace ``USERNAME``
178 cd /path/to/libinput.git
179 git remote add gitlab git@gitlab.freedesktop.org:USERNAME/libinput.git
182 - Create a new branch and commit your changes to that branch. ::
184 git switch -C mynewbranch
187 git commit -s
194 - Push your changes to your fork and submit a merge request ::
201 https://gitlab.freedesktop.org/USERNAME/libinput/merge_requests
203 Select your branch name to merge and ``libinput/libinput`` ``main`` as target branch.
205 - Verify that the CI completes successfully by visiting the merge request
209 <https://docs.gitlab.com/ee/ci/pipelines/#pipeline-mini-graphs>`__). For
211 and/or click the ``Expand`` button in the box for the test summaries.
216 - If changes are requested by the maintainers, please **amend** the
217 commit(s) and **force-push** the updated branch. ::
221 git commit --amend
222 git push -f gitlab mynewbranch
224 A force-push will re-trigger the CI and notify the merge request that new
229 <https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History>`__
233 ------------------------------------------------------------------------------
235 ------------------------------------------------------------------------------
237 libinput strives to have a
238 `linear, 'recipe' style history <http://www.bitsnbites.eu/git-history-work-log-vs-recipe/>`_
239 This means that every commit should be small, digestible, stand-alone, and
244 better transformed-view iteration (thanks Hannah!)
246 tests: add new spline test
256 tests: add view-transform correctness tests
274 ------------------------------------------------------------------------------
276 ------------------------------------------------------------------------------
278 When you re-send patches, revised or not, it would be very good to document the
280 merge request. If you have already received Reviewed-by or Acked-by tags, you
286 `'on commit messages' <http://who-t.blogspot.de/2009/12/on-commit-messages.html>`_
289 ------------------------------------------------------------------------------
291 ------------------------------------------------------------------------------
294 <https://gitlab.freedesktop.org/libinput/libinput/blob/main/CODING_STYLE.md>`_
297 ------------------------------------------------------------------------------
298 Tracking patches and follow-ups
299 ------------------------------------------------------------------------------
301 Once submitted to GitLab, your patches will be reviewed by the libinput
308 You should use ``git rebase -i`` to make revisions, so that your patches
315 libinput's core which you need to fix to progress. Separating these changes
323 that they still individually look good, then force-push your new branch to
333 ------------------------------------------------------------------------------
335 ------------------------------------------------------------------------------
341 <https://docs.gitlab.com/ee/ci/pipelines/#pipeline-mini-graphs>`_ to know which
347 Committed gitlab-ci.yml differs from generated gitlab-ci.yml. Please verify
352 ``ci-fairy generate-template`` wasn't run.
354 ``.gitlab-ci.yaml`` is auto generated, changes should be made in:
356 - ``.gitlab-ci/ci.template``
358 - ``.gitlab-ci/config.yaml``
361 `ci-fairy <https://freedesktop.pages.freedesktop.org/ci-templates/ci-fairy.html#templating-gitlab-c…
362 to update ``.gitlab-ci.yaml``: ::
364 ci-fairy generate-template
366 Finally, force-push you changes. See :ref:`contributing_submitting_code` for
376 In order to fix this kind of problems, you can compile libinput using the same
379 For example, if an error is found in the ``build-no-libwacom`` step, open the
383 + rm -rf 'build dir'
384 + meson 'build dir' -Dlibwacom=false
388 Use the same flags to fix the issue and force-push you changes. See
392 Test errors
395 The test suite is run for your merge request to check for bugs, regressions and
400 :: Failure: ../test/test-touchpad.c:465: touchpad_2fg_scroll_slow_distance(synaptics-t440)
402 See :ref:`test-suite` to learn how to run the failing tests.
404 Once the tests are fixed, force-push you changes. See