Re: Wayland design principles (Re: wayland and gambas)

On Tuesday 2024-04-30 07:23, Carsten Haitzler wrote: >> >> Although gambas provides a Settings.Write(window_name) / >> Settings.Read(window_name) that saves/restores the window placement and >> size. It's bearable Wayland does not handle this. > >YOU should never be handling this. It's like

Re: [ANNOUNCE] weston 12.0.0

On Wednesday 2023-05-17 23:01, Jan Engelhardt wrote: >On Wednesday 2023-05-17 21:14, Marius Vlad wrote: >>This is the official release for weston 12.0.0. > >Fails to build, it misses properly adding the output from xkbcommon.pc to the >compiler command line:[...] Patch follo

Re: [ANNOUNCE] weston 12.0.0

On Wednesday 2023-05-17 21:14, Marius Vlad wrote: >This is the official release for weston 12.0.0. Fails to build, it misses properly adding the output from xkbcommon.pc to the compiler command line: [5s] FAILED: libweston/libgl-borders.a.p/gl-borders.c.o [5s] cc

Re: How to fix screen-resolution detection?

On Saturday 2022-01-08 20:57, Alan Stern wrote: >The screen resolution on my laptop is not reported accurately. Here's >an extract from the output of xdpyinfo (under Xwayland): > >screen #0: > dimensions:3200x1800 pixels (847x476 millimeters) > resolution:96x96 dots per inch > >The

Re: Proxying Wayland for security

On Wednesday 2021-07-28 12:30, Carsten Haitzler wrote: > >> Please read the (lengthy) discussion at [1]. >> >> [1]: https://gitlab.freedesktop.org/wayland/weston/-/issues/206 >> >> In particular, the "get_credentials → PID → executable path" lookup is >> racy. PID re-use allows a malicious

Re: Change default Wayland branches to 'main'

On Thursday 2021-04-08 16:04, Daniel Stone wrote: >On Thu, 8 Apr 2021 at 14:02, Jan Engelhardt wrote: >>On Thursday 2021-04-08 13:20, Daniel Stone wrote: >>>following the leads of e.g. GitHub and GitLab, [...] >>>I propose that we do this for all the wayland/* repositori

Re: Change default Wayland branches to 'main'

On Thursday 2021-04-08 13:20, Daniel Stone wrote: > >I propose that we do this for all the wayland/* repositories, either this >weekend or next; I'm happy >to make the changes (rename 'master' to 'main' and retarget all open MRs). >Does anyone have any >opinions or suggestions? That could be

Re: Rethinking the clipboard?

On Monday 2020-12-28 20:51, Aaron Hillegass wrote: >I'm a Mac programmer who has been spending more and more time on Linux, and I >have become frustrated with the way clipboards work on Linux applications. Which aspect of it? ___ wayland-devel mailing

Re: [ANNOUNCE] Weston 9.0 release schedule

On Wednesday 2020-07-01 20:49, Jan Engelhardt wrote: > >On Wednesday 2020-07-01 19:03, Simon Ser wrote: >>On Wednesday, July 1, 2020 5:41 PM, Jan Engelhardt wrote: >> >>> However, when trying to retrieve >>> https://wayland.freedesktop.org/releases/ &

Re: [ANNOUNCE] weston 8.0.91

On Thursday 2020-07-30 23:19, Simon Ser wrote: >git tag: 8.0.91 > >https://wayland.freedesktop.org/releases/weston-8.0.91.tar.xz >MD5: 0148f669da7decede0156e2c6bee833a weston-8.0.91.tar.xz >SHA1: 477a705bd1d7d79066820abfc26fed5cc3ff17f2 weston-8.0.91.tar.xz >SHA256:

Re: [ANNOUNCE] Weston 9.0 release schedule

On Wednesday 2020-07-01 19:03, Simon Ser wrote: >On Wednesday, July 1, 2020 5:41 PM, Jan Engelhardt wrote: > >> However, when trying to retrieve >> https://wayland.freedesktop.org/releases/ >> all I get is a 404 ("The resource that you are attempting to access &

Re: [ANNOUNCE] Weston 9.0 release schedule

On Wednesday 2020-07-01 17:07, Simon Ser wrote: >Hi all, > >Here is the release schedule for Weston 9.0, the next major version: > >- Alpha: July 30th, in 4 weeks > >Package maintainers are encouraged to pick up the pre-releases to make >sure packaging can be tested (and fixed) before the stable

Re: The Wayland Protocol [Book]

On Tuesday 2020-05-05 05:16, Drew DeVault wrote: >Hiya all, just writing to share that I have removed the paywall from my >(WIP) Wayland book: > >https://wayland-book.com > >I have also made it available under CC-BY-SA. The source code is >available here: >

Re: gitlab.fd.o financial situation and impact on services

On Friday 2020-02-28 08:59, Daniel Stone wrote: > >I believe that in January, we had $2082 of network cost (almost >entirely egress; ingress is basically free) and $1750 of >cloud-storage cost (almost all of which was download). That's based >on 16TB of cloud-storage (CI artifacts, container

FTBFS weston 8 test-ivi-layout.so

More weston 8 fallout. [ 42s] [352/358] cc -o tests/test-ivi-layout.so 'tests/59830eb@@test-ivi-layout@sha/meson-generated_.._.._protocol_weston-test-protocol.c.o' 'tests/59830eb@@test-ivi-layout@sha/ivi-layout-test-plugin.c.o' -Wl,--as-needed -Wl,--no-undefined -shared -fPIC

Re: FTBFS weston 8.0

On Monday 2020-01-27 11:37, Pekka Paalanen wrote: > >> It was forgotten to add the pkg-config cflags from wayland into the >> test-runner command. This causes the weston-8 build to fail, given right >> system conditions. >> >> [6s] [221/358] cc -Itests/59830eb@@test-runner@sta -Itests

FTBFS weston 8.0

It was forgotten to add the pkg-config cflags from wayland into the test-runner command. This causes the weston-8 build to fail, given right system conditions. [6s] [221/358] cc -Itests/59830eb@@test-runner@sta -Itests -I../tests -I. -I../ -Iinclude -I../include

Re: XDG_RUNTIME_DIR on a system with no "logins"

On Thursday 2019-12-19 11:13, Guillermo Rodriguez Garcia wrote: >> >> If you used systemd, Weston has integration for that, both startup >> notification to ensure dependent services are started only after >> Weston is ready and socket activation should you choose to want >> that. > >Uhm. I am

Re: XDG_RUNTIME_DIR on a system with no "logins"

On Tuesday 2019-12-17 18:55, Guillermo Rodriguez wrote: >Hi all, > >Weston requires XDG_RUNTIME_DIR to exist. The specification for this >(https://specifications.freedesktop.org/basedir-spec/latest/ar01s03.html) >says: > >=== >$XDG_RUNTIME_DIR defines the base directory relative to which

Re: [ANNOUNCE] weston 6.0.93

On Friday 2019-08-16 17:54, Simon Ser wrote: >This is the RC1 release for weston 7.0. > >https://wayland.freedesktop.org/releases/weston-6.0.93.tar.xz 16:04 linux-37v5:~ $ wget https://wayland.freedesktop.org/releases/weston-6.0.93.tar.xz --2019-08-18 16:04:56--

Re: State of network transparency & a possible approach

On Sunday 2019-03-31 08:20, Simon Ser wrote: >On Sunday, March 31, 2019 12:29 AM, Manuel Stoeckl wrote: >> Hello all, >> >> 1.) I'd like to inquire about the state of network transparency for >> Wayland; has there been any notable work since the >> Wayland-over-Wire patches and krh's 'remote'

Re: [ANNOUNCE] weston 6.0.0

On Friday 2019-03-29 12:48, Pekka Paalanen wrote: >> >https://gitlab.freedesktop.org/wayland/weston/merge_requests/138 fixes >https://gitlab.freedesktop.org/wayland/weston/merge_requests/141 That works. The next change that causes a stop now is: [ 20s] + make BACKEND=headless-backend.so check

Re: [ANNOUNCE] weston 6.0.0

On Thursday 2019-03-28 11:33, Pekka Paalanen wrote: >> >> Fails to build. Someone's forgetting the pkg-config flags for xkbcommon. >> autotools gets this right. >> >> [5s] cc -Ilibweston/2b98b6d@@session-helper@sta -Ilibweston >> -I../libweston -Ilibweston/.. -I../libweston/.. -Ilibwes >>

Re: [ANNOUNCE] weston 6.0.0

On Thursday 2019-03-28 02:25, Derek Foreman wrote: >Weston 6.0 is released with only a trivial build change since RC2. Fails to build. Someone's forgetting the pkg-config flags for xkbcommon. autotools gets this right. [5s] cc -Ilibweston/2b98b6d@@session-helper@sta -Ilibweston

Re: [ANNOUNCEMENT] Weston builds with Meson, grace period for autotools

On Wednesday 2018-12-12 18:16, Pekka Paalanen wrote: > >here is an early Christmas / NewYear present / bomb (take your pick). I just >merged https://gitlab.freedesktop.org/wayland/weston/merge_requests/8 which >adds Meson build system to Weston. > >Most build options are equivalent to their

Re: Launch Weston at tty1

On Wednesday 2018-09-26 06:08, deepan muthusamy wrote: >I can able to launch Weston at tty7 but not able to launch at tty1. Why?? Probably because the tty is already allocated. (man deallocvt) ___ wayland-devel mailing list

Re: [PATCH] cursor: use memfd_create or shm_open for anonymous in-memory files

On Thursday 2018-08-16 12:41, Emil Velikov wrote: >On 15 August 2018 at 15:14, Simon Ser wrote: >> On Linux, try using memfd_create and file sealing. Fallback to >> shm_open on old kernels. >> >> On FreeBSD, use shm_open with SHM_ANON. >> >> Otherwise, use shm_open with a random name, making

Re: [PATCH libinput] util: abort if we try to allocate more than a MB

On Wednesday 2018-06-20 02:22, Matheus Santana wrote: >Reviewed-by: Matheus Santana > >The check for negatives isn't needed anymore? It indeed is not, since a (size_t)-1 is generally greater than 1048576. > Let's put a cap on for one MB, anything above that is likely some memory >

Re: [PATCH weston] build: honour libinput header location

On Thursday 2018-03-15 13:20, Pekka Paalanen wrote: >> diff --git a/Makefile.am b/Makefile.am >> index b5c29c04..8de40e51 100644 >> --- a/Makefile.am >> +++ b/Makefile.am >> @@ -43,7 +43,8 @@ AM_CPPFLAGS = \ >> -I$(top_builddir)/protocol \ >>

Re: [ANNOUNCE] libinput 1.10.1

On Wednesday 2018-02-28 01:27, Peter Hutterer wrote: >libinput 1.10.1 is now available. This release fixes three crashers, one >during tapping, two on startup/resume when the device node or seat weren't >assigned correctly. Is this one of them?

Re: New paths for Wayland sockets (Re: Enabling Android-style per application user ids)

On Friday 2017-11-03 10:37, Pekka Paalanen wrote: > >> Summary of (individual) proposals follows. >> >> >- modify WAYLAND_DISPLAY to support absolute paths which overrides >> > any search paths >> >> - introduce new WAYLAND_SOCKET >> - modify WAYLAND_DISPLAY to reject '/' > >What would be

Re: New paths for Wayland sockets (Re: Enabling Android-style per application user ids)

On Friday 2017-11-03 08:33, Pekka Paalanen wrote: >> > > >> > > wl_display_connect() always attempts to contact a server socket living at >> > > ${XDG_RUNTIME_DIR}/${WAYLAND_DISPLAY}. > >> > Modifying the meaning of WAYLAND_DISPLAY environment variable to >> > support also absolute paths has been

Re: [PATCH libinput] evdev: replace null sentinel with ARRAY_SIZE

On Wednesday 2017-05-10 17:20, Dima Ryazanov wrote: > +#define ARRAY_SIZE(a) (sizeof(a)/sizeof(a)[0]) > > >I'm guessing this works, but "sizeof(a)[0]" looks very unintuitive to me. I >think "sizeof(a[0])" is >the convention? If going with the sizeof(T) syntax, then the answer would be

[PATCH] doc: compact installation instructions

* Drop version-specific SO version from source-install command where this is not needed. * Less typing for the user: use zypper short forms. * Less typing for the user: libtool implies automake implies autoconf, so trim the install command. * Just specify the requirement for a root shell

Fwd: wayland 1.13 testsuite fails on s390x

>From https://bugzilla.opensuse.org/show_bug.cgi?id=1029452 : > >wayland fails to run the testsuite on s390x since the update to 1.13. >The failing test is: > >[ 24s] connection-test: tests/connection-test.c:163: >argument_from_va_list: Assertion `args[5].n == 105' failed. >[ 24s] test

Re: [PATCH weston] Update COPYING

On Wednesday 2017-02-15 16:02, Derek Foreman wrote: >> diff --git a/COPYING b/COPYING >> index faefd8f..418b4b4 100644 >> --- a/COPYING >> +++ b/COPYING >> @@ -1,8 +1,35 @@ >> +Copyright © 2008 Tungsten Graphics, Inc. >> +Copyright © 2008-2013 Kristian Høgsberg Since © already means Copyright,

Re: [RFC PATCH 0/8] Meson build system

On Friday 2016-12-02 19:28, Daniel Stone wrote: >On 2 December 2016 at 18:25, Emil Velikov wrote: >> >> The above seems like a strange mix of build tools and (runtime) >> dependencies. > >I was just trying to understand your 'distributions and/or builders >simply cannot

Re: [RFC PATCH 0/8] Meson build system

On Wednesday 2016-11-30 09:54, Pekka Paalanen wrote: >I'm looking forward to hearing your war stories on trying to beat sense >into autotools. I would never dare even approach it. Maybe it's FUD you >can show to be false, but I kind of doubt it. > >One huge convenience of Meson is (the

Re: [RFC PATCH 0/8] Meson build system

On Tuesday 2016-11-29 17:59, Daniel Stone wrote: >This patchset provides a working port to Meson, a Python-based build >system with a Ninja backend. Do you have this available in a convenient-to-download git repo somewhere? ___ wayland-devel mailing

Re: [PATCH weston 2/2] Makefile.am: Link modules to libweston.la

On Monday 2016-11-21 12:00, Daniel Stone wrote: >On 18 August 2016 at 10:15, Quentin Glidic > wrote: >> @@ -116,7 +116,9 @@ libweston_@LIBWESTON_MAJOR@_la_SOURCES = >>\ >> lib_LTLIBRARIES += libweston-desktop-@LIBWESTON_MAJOR@.la >>

Re: [PATCH wayland] Makefile: build also test programs during a normal build

On Wednesday 2016-11-16 17:16, Daniel Stone wrote: >> noinst_PROGRAMS = \ >> + $(built_test_programs) \ >> + exec-fd-leak-checker\ >> fixed-benchmark >> >> check_LTLIBRARIES = libtest-runner.la > >Doesn't this

Re: Weston versioning (Re: [PATCH weston 6/6] libweston: do not use weston version in libweston.pc)

On Friday 2016-07-15 15:30, Pekka Paalanen wrote: >> >OTOH, would adding a new libweston MAJOR in an already stable and >> >released binary distribution be absolutely forbidden? It would by >> >definition not affect anything the distribution was released with, >> >unless libweston's dependencies

Re: Weston versioning (Re: [PATCH weston 6/6] libweston: do not use weston version in libweston.pc)

On Thursday 2016-07-14 17:33, Emil Velikov wrote: > >The keypoint here is that one should _not_ need to uninstall >libdb-4_5-devel in order to have libdb-4_8-devel and vice-versa. >This is what parallel installability is all about (afaict). It is indeed what it is about. But is it _necessary_ to

Re: Weston versioning (Re: [PATCH weston 6/6] libweston: do not use weston version in libweston.pc)

On Wednesday 2016-07-13 13:54, Pekka Paalanen wrote: > >I think Quentin raised a good point, though. In source-based >distros, well, in Gentoo at least which I use almost exclusively, >there are no separate -devel packages. A package is, abstractly, merely a selected subset of `make install`

Re: Weston versioning (Re: [PATCH weston 6/6] libweston: do not use weston version in libweston.pc)

On Monday 2016-07-11 16:44, Emil Velikov wrote: >> Without pkgconfig supporting some new alias tag (hint, hint) to cover >> such a case, >No idea what such a "alias tag" is supposed to do/look like. Do you >have examples ? Proposed concept would be to make pkgconfig recognize a new Alias

Re: Weston versioning (Re: [PATCH weston 6/6] libweston: do not use weston version in libweston.pc)

On Monday 2016-07-11 16:44, Emil Velikov wrote: >>>http://ometer.com/parallel.html. I would strongly recommend giving it >>>a look. >> >> I read it now, and I do not buy it - at least not for 2016 standards. >> According to the page, it was written in 2002, and I can confirm that >> the situation

Re: Weston versioning (Re: [PATCH weston 6/6] libweston: do not use weston version in libweston.pc)

On Sunday 2016-07-10 13:13, Quentin Glidic wrote: > > If we install only one .pc file: > - You cannot develop against an old version. I do not feel that is true. If you have Berkeley DB 4.5 in tarball form, you can build and `make install` it. Provided the SONAME is different (it is;

Re: Weston versioning (Re: [PATCH weston 6/6] libweston: do not use weston version in libweston.pc)

On Sunday 2016-07-10 12:46, Emil Velikov wrote: >> PKG_CHECK_EXISTS([gtk-3.0], [PKG_CHECK_MODULES([gtk], [gtk-3.0])], [ >> ...repeat the fun... >> ])] >> >Yes, it's one line of fun for each version that you want to be >compatible with. It's not ideal, but it's a price to pay, for keeping >things

Re: Weston versioning (Re: [PATCH weston 6/6] libweston: do not use weston version in libweston.pc)

On Saturday 2016-07-09 18:24, Pekka Paalanen wrote: >> >> First, what kind of parallel installability is sought? >> >> * just runtime >> * parallel development environment (like what e.g. libabw, >> librevenge.. do) > >everything that is about libweston including development enviroment >has

Re: Weston versioning (Re: [PATCH weston 6/6] libweston: do not use weston version in libweston.pc)

On Thursday 2016-07-07 11:46, Pekka Paalanen wrote: >> >> +AC_SUBST([LIBWESTON_VERSION], >> >> [libweston_major_version.libweston_minor_version.libweston_patch_version]) >> >> >> > >> > That makes packaging a pain. Although the whole libweston (supposedly >> > parallel-installable) is already

Re: [PATCH wayland-protocols] unstable: Add the Wayland Wobbly Windows protocol

On Friday 2016-04-01 18:19, Daniel Stone wrote: >> + >> +Copyright C 2016 Samsung Electronics > >It's 2016: we have Unicode copyright codepoints. More specifically, since © is the same as the word 'copyright', one of them is, in fact, completely redundant. (Means: Either write © 2016

Re: [PATCH weston v4] refactor x11-backend configuration API

On Monday 2016-03-21 22:58, Benoit Gschwind wrote: > struct x11_output { >@@ -130,6 +127,11 @@ struct window_delete_data { > > struct gl_renderer_interface *gl_renderer; > >+static void >+weston_x11_backend_config_init_default(struct weston_x11_backend_config * >ths) { >+ bzero(ths,

Re: wayland 1.6.91 testsuite failure [Re: [ANNOUNCE] wayland 1.6.91]

On Monday 2015-02-02 11:17, Marek Chalupa wrote: Sent a patch that fixed it for me. I meant to send it as a reply to this, but something went wrong. Here it is: [PATCH wayland] test-runner: wait for concrete pid  Does it fix it on your side? Nope, the patch does not address my issue. However,

wayland 1.6.91 testsuite failure [Re: [ANNOUNCE] wayland 1.6.91]

From openSUSE's attempts to build wayland 1.6.91: [ 98s] [ 98s] Timeout was set to 3 seconds from now. [ 98s] test threading_errors_tst: exit status 0, pass. [ 98s] [ 98s] unable to open lockfile

[PATCH] build: honor results obtained by pkg-config libinput

The error was: src/libinput-seat.c:30:22: fatal error: libinput.h: No such file or directory --- Makefile.am | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index b2d6893..7f3e5d3 100644 --- a/Makefile.am +++ b/Makefile.am @@ -34,7 +34,8 @@

[PATCH 1/2] build: symbol ck_assert_ptr_ne requires check-0.9.10

openSUSE 12.3 ships with check-0.9.9 and subsequently fails to build the tests. Change the call to look for check = 0.9.10 where that symbol is available. Signed-off-by: Jan Engelhardt jeng...@inai.de --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] build: use symbol versioning

Symbol versions provide a means by which ELF utilities can determine whether a program is incompatible with a too-old library version so that package management tools can autodetect version-based dependencies and suggest upgrade paths. Signed-off-by: Jan Engelhardt jeng...@inai.de --- The name

libinput: build system, symbol versions

to aaa0272d0f2f54b1b6dc9f0596a6ec627540877c: build: use symbol versioning (2014-09-10 01:25:05 +0200) Jan Engelhardt (2): build: symbol ck_assert_ptr_ne requires check-0.9.10 build: use symbol versioning configure.ac | 2 +- src/Makefile.am | 3

[PATCH 2/2] build: use symbol versioning

Symbol versions provide a means by which ELF utilities can determine whether a program is incompatible with a too-old library version so that package management tools can autodetect version-based dependencies and suggest upgrade paths. Signed-off-by: Jan Engelhardt jeng...@inai.de --- src

Re: [PATCH 2/2] build: use symbol versioning

On Thursday 2014-09-11 23:28, Peter Hutterer wrote: This sounds like a good idea. I have not pushed it yet though because I'd want to avoid adding the symbols that will be deprecated in the coming release (libinput_device_get_keys and libinput_device_calibrate). can we run the symbols

Re: [PATCH 2/2] build: use symbol versioning

On Thursday 2014-09-11 22:55, Jonas Ådahl wrote: On Wed, Sep 10, 2014 at 01:32:25AM +0200, Jan Engelhardt wrote: Symbol versions provide a means by which ELF utilities can determine whether a program is incompatible with a too-old library version so that package management tools can autodetect

[PATCH] build: symbol ck_assert_ptr_ne requires check-0.9.10

openSUSE 12.3 ships with check-0.9.9 and subsequently fails to build the tests. Change the call to look for check = 0.9.10 where that symbol is available. --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index bb702c0..b3d2446 100644

Re: Wayland and Weston 1.0.3 releases out

On Wednesday 2012-12-19 08:27, Pekka Paalanen wrote: make[3]: Entering directory `/home/abuild/rpmbuild/BUILD/weston-1.0.3/tests' FAIL: surface-test.la [..]. == 6 of 6 tests failed could we see the logs from the tests? I

Re: Wayland and Weston 1.0.3 releases out

On Friday 2012-12-14 23:20, Kristian Høgsberg wrote: f71a3fb5b6534cce35ac7456a5fd540fc3806fc1 wayland-1.0.3.tar.xz ce1f41251a07600ed8c6b2e3dc1e868008aeb33a wayland 1.0.3 tag 583589cf7dd8f3300eef2bfb7b1968875a155e2a weston-1.0.3.tar.xz b61f7d27738b73d27b03b8982b37ec78df52976e

Re: Wayland and Weston 1.0

On Wednesday 2012-10-24 13:51, Pekka Paalanen wrote: A few folks around me, and myself included, have pondered... It would seem that wayland and its possible compositors all require 3D support, which may require, if no accelerating GPU is installed, the use of software rendering when doing

Re: [PATCH] Add version info to the shared libs

On Friday 2012-11-09 18:54, Mikko Levonmaa wrote: Right, so if the first api version is 0 then it make sense, sort of, matter of preference I guess. So, the original patch was wrong, however the new suggestion was actually geared towards the future  and the next release(s), so if I'm not

Re: [PATCH] Add version info to the shared libs

On Tuesday 2012-11-20 20:59, Mikko Levonmaa wrote: What I was actually trying to propose in my previous mail is that even when the current api version is 0 we could already have the mechanics in place to increment the api version when the time comes, or is that automatically handled? It is not

Re: 1.0 Branch created

On Friday 2012-11-09 17:16, Thiago Macieira wrote: On sexta-feira, 9 de novembro de 2012 10.37.06, Kristian Høgsberg wrote: I've created 1.0 branches in the wayland and weston repos. I found it confusing the use the 'master' and 'next' terminology when replying to patch emails and being able

[PATCH] Use a library symbol version map

This helps package managers recognize when a new version of libxkbcommon (with same SONAME) is required due to new symbols. Signed-off-by: Jan Engelhardt jeng...@inai.de --- Makefile.am |4 +++- libxkbcommon.map | 66 ++ 2 files