Lines Matching +full:libinput +full:- +full:test +full:- +full:suite +full:- +full:log
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
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
373 Usually, checking the CI log is enough to catch this errors. However, your merge
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
380 log and search the build options: ::
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
398 Open the CI error log and search for a message similar to: ::
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