Update to match xorgproto 2024.1

[wysiwys]

Hello,

This pull request provides an updated version of xkeysym to match the latest xorgproto release (2024.1) and the latest version of libxkbcommon (1.7.0). Currently, xkeysym is only in sync with an earlier xorgproto release, 2022.1.

The changes in this pull request reflect the new keysym definitions added by xorgproto 2024.1 and 2023.1 . Additionally, xorgproto 2023.1 deprecated several keysym names and added their new, preferred names (e.g. guillemotleft becomes guillemetleft), although the old names are kept for compatibility, in order to not break applications that depend on these older symbol names.

One question relates to the choice of environment to fetch the most recent keyboard symbol headers, and generate the keyboard symbols from them. The rust:slim image, which is currently used by this crate to set up the environment to generate Rust code from headers, only has x11proto-core-dev 2022.1.1 (corresponding to xorgproto 2022.1) as the latest version available in apt. This means that the current symbol set is only consistent with that, older release, and does not reflect recent changes. The other Rust official Docker images all only have older versions of xorgproto available through the package manager, except rust:alpine which has a somewhat more recent xorgproto version at 2023.2.

As a way to work around this, this pull request shows that the archlinux:base image can be used instead, since Arch's pacman has xorgproto 2024.1 available. However, this choice makes the code generation step slower, since cargo must now be installed in the container first.

Would there be a better way to accomplish this, or is this fine? I thought it could be possible instead to automatically generate directly from the downloaded raw header files, without installing a package, although this would require a significantly different setup process and might have its own downsides.

Thanks

[kchibisov]

The generated file is fine.

There's also one place where update might be needed, though, I haven't checked myself. We have a KEYSYM tab that matches what is present in libxkbcommon, so we might need to update it as well.

See the from_char and the top level comment where it came from in src/lib.rs.

--

I'm fine with using e.g. arch since the thing is generated manually.

[wysiwys]

@kchibisov

Glad to hear that. The main advantage of an Arch container that I can see is that its xorgproto package is updated very quickly, generally within a few days of release, so it is easy to get the latest version.

I have taken a look at the file keysym-utf.c in libxkbcommon to check if any changes to the unicode keysym table are needed. A look through the commits that have happened since libxkbcommon 1.4.1 (which is the version that xkeysym's KEYSYM table matches) confirms that there are no new entries in that table since the current standpoint.

[kchibisov]

Will wait for @notgull for a while.

[notgull]

Sorry for the delay, this looks good to me

[wysiwys]

Hi, thanks for the approvals. However, before merging, there is one small improvement to this PR that that does not affect the generated keysyms, but makes the pacman commands a bit better:

• The two pacman commands are condensed into one to avoid refreshing the package database twice (since pacman -Sy <packages> already refreshes the database before installing the new packages)
• Added the -u flag, which updates all packages on the system that are out of date. Although the install was previously fine without this flag, I have meanwhile learned that this flag is important, because it avoids the possibility of a partial upgrade in Arch which could cause packages to break in this container.

Although the previous pacman commands worked, I have learned in the meantime that pacman -Syu <packages> is generally considered to be the best way to upgrade the package database and then install packages under Arch.

After making this change, I checked that re-running the keysym generation gives the same result.