Hello,

I am writing to see if the project is interested in using an updated version of 
kmscon. I ran across this information because I have started using kmscon as 
the main interface on my Guix machine, and ended up digging into it a bit. I am 
sending this email only because I think it is polite to offer information 
upstream, if you are not interested in this then I can keep everything locally 
without any problems. I am currently keeping the code in a separate repository, 
but if you are interested in it then I can add it to the Guix repository and 
send a patch. There are 3 areas I will discuss: the elogind dependency, 
updating to a more recent Aetf version, and some additional patches I wrote 
which you may or may not want.

# elogind dependency

As a result of the work I will discuss below, I noticed that the current 
version of kmscon does not actually have multi-seat support enabled, which can 
be seen in the log output on the CI platform (1):

Miscellaneous Options:
                debug: yes (yes: )
        optimizations: yes (yes: )
           multi-seat: no (no: libsystemd)

Although, there is a different line farther up in the file indicating that 
multi-seat support is desired. I assume that this does not cause any practical 
issues because a cursory search of the issue tracker doesn't show anyone 
discussing it. But the substitute* snippets changing the systemd dependency to 
an elogind dependency imply that someone wanted this at some point, so I'm 
mentioning it in case it's relevant. I tried building the tip of Aetf's tree 
with multi-seat support enabled and some changes based on the substitute* 
snippets. However, there was a fatal error when kmscon called 
`sd_login_monitor_new`. I don't know why this happened and I didn't look into 
it because I don't need multi-seat support and I don't have multi-seat 
equipment in any case.

# Aetf version

The current kmscon package uses the Aetf repository as the source, with a note 
that the old one is unmaintained. However, the commit that is specified is from 
the old repository. This means that Aetf's improvements, such as the ability to 
select a color palette, are not available. The package definition needs to use 
the meson-build-system and there are some new or updated dependencies (2). It 
seems to work on my machine, but currently kmscon is used in the installer 
where stability is critical so that users have a good first experience. So it 
might make sense to have a separate kmscon package with the updates and a keep 
the current package for the installer. I don't know how widely Aetf's version 
has been used, and it turns out that the automated test suite does very little 
(there are several files meant for interactive testing, but `meson test` only 
runs one test which checks some string parsing logic).

# Additional patches

I have 3 patches implementing 2 changes in my personal fork (3). The first 
change adds command-line options to set the desired width and height of the 
viewport. I added this because running kmscon in my VM did not fill the 
available space. This is implemented across 2 commits, but I could squash them 
into one patch if you want it. I was careful to preserve existing behavior if 
these options are not specified so it should not cause any regressions. 
However, I don't know if you want to keep a patch that adds a feature in your 
repository. Most of the patches I've seen have been about compatibility with 
Guix, not adding new features. I did open a pull request with the upstream 
repository, but I do not think it is maintained any more. The most recent 
commit is from last year, and there are pull requests more than 6 months old 
which have not received any reply from the developer.

I expect that you will want the other change if you want the updated kmscon. 
There were some warnings emitted by the current version of meson about 
deprecated functionality in the build files, I just changed it to conform to 
the new version. This did not require any functional changes. It just makes the 
build log a little bit quieter, which is generally a good thing.

Sincerely,
Skyler

(1) http://ci.guix.gnu.org/build/1396560/log/raw
(2) 
https://git.sr.ht/~skyvine/personal-code/tree/c525f74c64b27a793aca088489d7c9cfe7090581/item/src/scheme/guile/guix/packages.scm#L81
(3) https://git.sr.ht/~skyvine/kmscon/log

Reply via email to