LEdoian's Blog - technology

Creating own XKB tweaks

2024-04-17T15:18:00+02:00

Debugging this took me a bit too long, so I want to write about the caveat.

My problem: My laptop does not have PageUp and PageDown keys, and many other keyboards I use have similar deficiencies. And I use various environments and various systems, some of which are shared with other people who don't need/want my tweaks. IOW: I want something generic, but it must be confined to my user – no system-wide daemon, no udev remapping. (I mostly ended up with these solutions when I searched for a way to remap keys on Wayland.)

Requirements: xkbcommon implementation of XKB with utilities. It is quite common these days (duh…), but you could probably just compile this yourself if you don't have it.

The tweaking

The xkbcommon guide tells us that we can inspect the files in [1] /usr/share/X11/xkb for the source files and just write our bits to ~/.config/xkb/symbols/ledoian. In particular, I added this snippet to remap keyboard brightness controls to PageUp/Down:

partial
xkb_symbols "qs" {
    key <I238> {[ Prior ]};
    key <I237> {[ Next ]};
};

The key identifiers are taken e.g. from xkbcli interactive-wayland. However, this is KcCGST [2] description, but layouts are configured using RMLVO, so I need to define an option and tell what it should do. The guide wants me to create ~/.config/xkb/rules/evdev with:

! option = symbols
  ledoian:qs    = +ledoian(qs)
! include %S/evdev

Now I just add ledoian:qs [3] to my keyboard configuration and… it does not work. For this, at all, but if I remap e.g. the L key, that gets applied. The problem? That included file says that the default keyboard model always includes inet(evdev) symbols. Those symbols set the default meaning of the keys, but since that got applied later, it overrides my tweak.

Solution: first include, then add my option.

How to debug: read stuff that xkbcli compile-keymap --verbose tells you (pass your config as --layout, --variant, --options, …). At the top it says what it does:

xkbcommon: DEBUG: Include path added: /home/ledoian/.config/xkb
xkbcommon: DEBUG: Include path added: /usr/share/X11/xkb
xkbcommon: DEBUG: Compiling from RMLVO: rules 'evdev', model 'pc105', layout 'us', variant '(null)', options '(null)'
xkbcommon: DEBUG: Compiling from KcCGST: keycodes 'evdev+aliases(qwerty)', types 'complete', compat 'complete', symbols 'pc+us+inet(evdev)'

My option would appear before the inet(evdev) part.

A note about X11

X11 uses a separate implementation of XKB (the original one, in fact), which does _not_ look into the user directory, just the system ones. However, you can compile the keymap yourself using xkbcli compile-keymap [KEYMAP OPTIONS] > my_layout.xkb and load it into the X server with xkbcomp my_layout.xkb $DISPLAY.

[1]	This is not technically accurate, really the paths reference `$XDG_something` variables. I am lazy and just copied my system, so YMMV (probably won't, though).

[2] There are two levels of describing the keymap: the lowlevel one is called KcCGST (short for keycodes, compat, geometry, symbols, types) and is considered to be an implementation detail; the user-facing one is RMLVO (rules, model, layout, variant, options) and that is what you use in the configs, with setxkbmap &c.

[3] While both this example and the upstream layouts name the symbols and options similarly, I think they don't need to be related – you should be able to put whatever you want in your options to the left of =, the right hand side is the name of the symbol file and if a non-default layout from that file is used, its name is put in the parentheses.

Print your stuff on Möbius bands!

2024-03-02T18:07:00+01:00

I found a fun and useful way of printing stuff to ~~both~~all sides of a paper. I just need to find the right printer!

Quick recap: how to conventionally print stuff two-sided

A typical way is just sending the page to get printed two-sided (with setting the correct way of flipping pages). That is, on the other side of page 1 is page 2, next sheet contains pages 3,4, then 5 & 6, …

This is usually trivial to print on duplex printers, a bit hard to simulate on one-sided printers (but some drivers can do that) and has drawbacks when you need to look at stuff on other pages at the same time – you need to flip the sheet often, as you only can put half of the pairs of pages next to each other (even one and the following odd one).

Ordinary two-sided printing. Red arrows show sheet flips between consecutive pages.

A slight improvement hack is putting two pages on the same side of the paper (works well with A-series of papers, I don't know for Letters &co.) – you can put up to four pages of the original document next to each other, if they are the right ones, but there are still pairs of pages that need turning sheets. Also only works if the original pages do not have too tiny features on them. [1]

Booklets are fun and approachable, but still suffer from the same issues as the conventional duplex print. They might be a bit hard to print, but programs like pdfbook or paperjam make it easy to prepare for the classic duplex printing. Also, it is maybe hard to tell which page ends up where, as the order is: last+first, second+penultimate, third-from-end+third, … until the pages meet in the middle.

The most common booklet order with two pages per side for landscape orientation. (Note that we show more pages, and thus more sheet-flips; the number of sheet-flips is in fact the same as for two-sided printing.)

The improvement for seeing multiple consecutive pages

In order to be able to look simultaneously at many consecutive pages of the original, I think the order of first+first-past-half, second+second-past-half, … middle+last is much better (or maybe even the best). Since consecutive pages end up on different sheets (whenever there are at least three pages), if the original has e.g. figures on different page or long code listing, you can see it all!

The "Möbius order" of pages.

And this is really easy to use: You read a page and when you don't need it anymore, you flip it and put to the end of the page stack [2]. If you need to look at several pages, just rotate them in the same order as they go the first time. [3]

Need to print this? For one-sided printers this is rather easy, too: just print the first half (the bigger one) on the sheets, then put them back into the tray and print the rest on them. You might need to experiment which side the sheets should be put in and whether you need to print the rest in reverse order, but that is it.

Got the pages shuffled? Sort them by the first half, as if the print was one-sided.

The only annoying thing for me is that there is not much software that could reorder the pages for two-sided printing, so that you don't need to re-insert the sheets back in the tray. So I patched paperjam to enable this. [4]

And the best part? If you would try to glue consecutive pages side-to-side, you'd end up with a Möbius band! So if you get a Möbius paper, you can just print this one-sided (duh :-D)

Honorable mention: leporello

Printing leporellos (aka concertina folded) also has many of the same benefits, since there is only one pair of consecutive pages that need a page flip. The order is first+last, second+penultimate, … and the original pages can be shuffled this way with paperjam or simply using the other order for the second side printing, than for the Möbius band. But there is a bit of fun topology missing here :-)

A leporello order is also quite good, with only one sheet-flip in the entire document.

Is this the best order?

Yes, if "best" means "the minimum difference of numbers of pages that get put on the same sheet is as big as possible". The proof is left as an exercise for the reader.

Of course, this holds for a set of pages with no additional assumptions. In ordinary print, having a sheet-turn between chapters is fine and under similar guarantees other approaches may yield better results.

Cheat sheet: paperjam commands

Various commands for ordering pages for duplex printing with paperjam.
Order	Command
Classic two-sided	`null`
Two pages per side	`nup(2)`
Booklet	`book` (follow with `nup(2)` for actual booklet print)
Leporello	`modulo(2) {1 2} modulo(1,half) {1 -1}` (The first `modulo` just adds blank pages to the end.)
Möbius (with patch)	`interleave(2)`
Möbius (known page count)	`select {1..5 10..6} modulo(1,half) {1 -1}`
Multiple Möbius bands, odd-even	`modulo(4) {1 3 2 4}`
Multiple bands, "modulo 3"	`modulo(6) {1 4 2 5 3 6}`
Second half (smaller) of pages in reverse order	`modulo(1,half) {-1}`
Second half (smaller) of pages in normal order	`modulo(1,half) {-1} modulo(1) {-1}`
First half (bigger) of pages	`modulo(2) {1 2} modulo(1,half) {1}`

I might create more patches for avoiding the weird modulo commands…

[1]

Most of the figures in this article are drawn with a single page per a side of a sheet. I consider putting more pages on a single side of paper to be an implementation detail, because it is not always possible (e.g. with too small font) and sometimes you could put more than two pages on a single side of paper, which leads to the fact that if you put everything on one side of the paper, you can see everything at once and save the other side. Not very useful though… My only exception is the booklet printing below, because that one seems to be rather common.

[2]	See how this neatly puts the first-past-half page right after the half of the stack? Awesome!

[3]	Also, if you flip the page around the wrong edge, you can just rotate the rest of the stack and end up with the correct orientation.

[4] A slight variation for which I can generate the order with upstream paperjam is using this order on small subsets of pages. For example, if you only want to be able to see any two consecutive pages, you can do this for just four pages – the order is then 1+3, 2+4, 5+7, 6+8,… Since each sheet either contains two odd or two even pages, the following page is on different sheet than the previous one. And you can do this "modulo 3" to see three pages: 1+4, 2+5, 3+6, 7+10, … This "simulates" multiple smaller Möbius bands, but will be probably harder to use.

About this blog

2024-01-10T16:47:00+01:00

This is my blog and this article describes its setup and other details about my intentions. The actual setup is probably the most interesting tech-wise.

What is this?

My own space on the internet where I can post whatever and link others to it. It might end up containing rants, guides, ideas, or maybe nothing at all in the end. Only the future will tell.

The blog might even serve as my personal web page/introduction. Maybe. Maybe not…

The main motivation is to have low-effort way to post random stuff. Which leads to my requirements for this thing.

Requirements

(The requirements are a bit too idealistic, so not all of them were satisfied…)

low-effort, me-friendly, low-maintenance – I don't want to have to learn too many new technologies to use this. This includes the required technologies: Python, Markdown/reStructuredText, Jinja2, git, …
Technical and math content ~~friendly~~ compatible – I expect that to appear here.
Static site – for security, coolness factor and control. Also static on the front-end, because I don't like JavaScript and/or running untrusted code on my machine (even when in a sandbox). The SSG should likely be aimed at creating blogs, not documentation. Also, self-contained, as in not depending on third-party sites.
No moving parts in the infrastructure (or as few as possible) – if it works on my machine, it should just get mirrored to the public site with as few modifications as possible.
Transparent – I should be able to understand it, maybe others could also use it as a resource or take inspiration. (At one point, this deployment itself started being interesting, so if I can share the background as well as the final webpage, it would be cool.)
Followable – I know you internet guys like to ~~stalk~~ follow people :-)
Aligned with my values: minimalist, simple, extensible/hackable, FLOSS
If the platform could distinguish translations and do strikethroughs, it would be nice, but that is not a hard requirement.

There are several features of conventional blogs that I consider to be a non-goals or even anti-goals. Mostly it is about interactivity – I don't aim for having any kind of comments here, or really anything that would require JavaScript or complex HTML/CSS. And appearance goes past me as well, I instead try to let the browser decide how to display this page – more on that below.

The workflow I wanted to achieve is something like: Write the content, git it, build it (locally, no CI/CD), push it, done. Single write, single push, very simple.

And I managed to achieve something like that, via learning (too much?) about git.

The setup

Naturally for a sysadmin/netadmin, the setup consists of 7 ~~ISO/OSI~~ layers:

Physical layer: cheap Hetzner VPS. Not physical, but whatever.
Network layer: Nginx
Persistence layer: this git repo. I will elaborate below why can you see this both rendered here and in the source form in Forgejo.
Content layer: Markdown or reStructuredText files.
Business logic layer: Pelican. It's rather popular and written in Python, I didn't look further.
Presentation layer: I hacked my own theme, because I didn't like any in the pelican-themes repo. I was a bit inspired by the layout of eevee's blog, but I wanted a dark theme. And as you can see, I can't do quality frontend, so it ended up horrible… :-D
Stalking layer: Pelican's built-in RSS and Atom feed generators. Not linked from anywhere at the moment, but the repo will tell you what hides under the /feeds/ path. Or you can utilize the repo (for personal use – the content's license is not decided at the moment)…

Most of this is straightforward, the fancy part is my repo. The repo contains both source and rendered content, so that I can point Nginx right at a checkout and have Git solve both persistence and deployment without additional moving parts.

There are two tricks in the configuration of Git repositories: pushing to a checked out repo is enabled by configuring receive.denyCurrentBranch = updateInstead in the target repository (which is just a normal repo, not a bare one), and then I just told my source repositories [1] to use two push targets for the remote (the first line replaces the original push address for some reason):

git remote set-url --add --push blog_remote gitea@gitea.ledoian.cz:LEdoian/blog.git
git remote set-url --add --push blog_remote blog_user@blog.ledoian.cz:blog_dir

The blog user is just a user with SSH access via authorized keys, no special sauce there. Nginx is then pointed to serve ~blog_user/blog_dir/output/ at blog.ledoian.cz. (The git-remote(1) manpage requires me to have both repositories in sync, but as long as I configure all my repositories this way, I should be safe, and I think I could get away with my blog checkout getting behind accidentally.)

My workflow and lots of drafts

It's Git so it's only natural for me to use various branches and repositories even for a dumb blog. There are in fact 4 stages an article may go through [2]:

A private draft: lives on a branch priv/something, may contain private infos (like when I would just copy-paste from terminal without redaction) and this branch will probably never be merged to the main repo. Nothing about these branches is guaranteed.
A public WIP draft: uses a branch called pub/something which is pushed to Forgejo (and in fact also to the blog itself, but that is just an implementation detail). The draft is either does not build or is very incomplete and I expect to add stuff in a way that could break the build, so I put it on a separate branch. The branch will be probably merged to the main branch (called blog) when it is ready.

The pub/… branches can be created either manually or by cherry-picking from the respective priv/… branch, but that will likely not be distinguishable. (I am too lazy to keep the references even in the commit logs.)
When a draft is almost ready (or the content has simple syntax), it gets placed on the blog branch. The only thing that designates it as a draft is status: draft in the frontmatter, which means that the article will get rendered and put somewhere on the public blog, but not reachable from the title page ("unlisted").
Of course, eventually (and hopefully) the article gets published for everyone to see. At that point, it is complete (or at least that is what I thought when marking it as published). Possibly it might be updated in the future, but no such update is anticipated at the moment of publishing. [3]

I use Git to synchronize my private branches among machines, so there are actually two "server-side" repositories (private and public one) and thus two remotes. [4]

As for the actual workflow, for the main branch it usually consists of: writing content, committing it, building the web, checking it locally, committing the built blog and pushing it. Sometimes I do the commits together, but I always separate the rendering/building commits from the content-creating ones, so that I can handle those differently if needed (i.e. there is no point in cherry-picking the built content, I can generate it). [5]

For other branches I use some applicable subset of the steps above, probably.

Design considerations

The appearance of the blog is maybe not nice. That is for two reasons: I don't have the right idea about how to make it much better and I want to have a rather simple CSS for the web. The latter wish is because I tend to tweak appearance of sites I visit using my own styles, so I would like you to be able to do the same.

And for the former reason, if you have any ideas / improvements (including user styles), hit me at blog@pokemon.ledoian.cz :-)

My overall idea is a dark-by-default [6] minimalist page with a single menu on the right containig all the relevant links. The page should not dictate too much but rather let the user agent decide the rendering (it does anyway…).

I want my blog to render similarly in Gecko-, WebKit- and Blink-based browsers (e.g. Firefox, Badwolf, Qutebrowser). Others should be usable. Browser-/engine-specific styles are not welcome – let's keep it simple. And no JavaScript…

Work in progress / TODOs

This thing is at the moment very barebones, which is sufficient for the main purpose. However, I would like to have some features here, one day, hopefully:

Dates in the article headers (and maybe more improvements of the theme, see above)
Stable category and tag names and a page with a description of them. As of now I haven't really invented a system of sorting my content, which leads to a mess… Please don't rely on categories having any particular name / URL for now.
Link the RSS feeds from somewhere
Personal info with links to my other profiles
Some linking to the Fediverse and using it for comments (since there will be no comments here)
Sensible translations, maybe (if I/someone ever get to write the same content again in a different language…)
Improve the list of talks I've given (create some kind of sensible table maybe?)
Decide on a licence for the content (If you want to utilize something here before I do that, please ask me, I think we can find a way :-))

If you are so upset with this blog (or maybe bored) that you want to improve it, send me patches / ideas. I don't expect anyone to do that, though :-D (And I do not promise you that I will use the patch, even if it matches all my opinions above. I also have some gut feelings about what I like…)

Also, tell me if you hate something else about my page. I want to at least know whom I upset :-D (but I will probably also think about your gripes and whether I can and should try to avoid them…)

[1]	I also use multiple machines on which I can write stuff.

[2]

I am lazy and chaotic (good), so the stages are optional and non-linear, and sometimes involve paper. This article is a prime example: parts of it were on two different private branches, but at the end I wrote it from scratch directly on the main branch. And the requirements were written on a paper originally.

Nevertheless, the general idea still holds and may inspire others, so it makes sense to keep this part in the article. (Also, this footnote might not make sense before reading the definition of the stages, but I didn't find a better place to put it…)

[3]	Well, given this article contains some future plans, I actually anticipate update of this one, but maybe not in the near future. So the outline is not really correct, but I make the rules :-) (There were some build breaks on the main branch, too :-D)

[4] I would love if my Forgejo could have "private branches", but I understand that the overhead for doing this is not nice, since it would need to be able to decide for any object, whether it is public or not (you can do git fetch <remote> <object-hash>) and somehow keep track even with rebases, merges, force-pushes, many branches, … Having a separate private repository is not a big problem in comparison.

[5] Git purists might want to tell me that committing build artifacts is not good practice. I know and I explicitly don't care in case of this repo, because here I prioritise my own comfort of being able to check everything locally and then be reasonably sure the deployed version will also work, all this with only a single push somewhere. Of course, one could argue that with that there is no reason to create two commits, but it does not really bother me to run something like git commit -m"render" output/ when I am sure it works, and this keeps readable diffs separate from the non-readable ones (i.e. the changes in generated HTML).

[6] Having the page be dark-by-default is my preference, but I respect that others may prefer light sites. However, I have not yet determined what colors should be used (probably still cyan / blue / maybe purple-ish, but I don't know what shade) nor understood how to use @media(prefers-color-scheme) in a maintainable and simple way (in the context of my theme). So naturally, this is postponed to the future…