As an Linux application developer, one might not aware that there could be certain effort required to support Input Method (or Input Method Editor, usually referred as IME) under Linux.

What is input method and why should I care about it?

Even if you are not aware, you are probably already using it in daily life. For example, the virtual keyboard on your smart phone is a form of input method. You may noticed that the virtual keyboard allows you to type something, and gives you a list of words based on what you already partially typed. That is a very simple use case of input method. But for CJKV (Chinese, Japanese, Korean, Vietnamese) users, Input method is necessary for them to type their own language properly. Basically imagine this: you only have 26 English key on the keyboard, how could you type thousands of different Chinese characters by a physical keyboard with only limited keys? The answers, using a mapping that maps a sequence of key into certain characters. In order to make it easy to memorize, usually such mapping is similar to what is called Transliteration , or directly use an existing Romanization system.

For example, the most popular way for typing Chinese is Hanyu Pinyin.

What do I need to do to support Input method?

The state of art of input method on Linux are all server-client based frameworks. The client is your application, and the server is the input method server. Usually, there is also a third daemon process that works as a broker to transfer the message between the application and the input method server.

1. Which GUI toolkit to use?

Gtk & Qt

If you are using Gtk, Qt, there is a good news for you. There is usually nothing you need to do to support input method. Those Gtk toolkit provides a generic abstraction and sometimes even an extensible plugin system (Gtk/Qt case) behind to hide all the complexity for the communication between input method server and application.

The built-in widget provided by Gtk or Qt already handles everything need for input method. Unless you are implementing your own fully custom widget, you do not need to use any input method API. If you need your custom widget, which sometimes happens, you can also use the API provided by the toolkit to implement it.

Here are some pointers to the toolkit API:

Gtk: gtk_im_multicontext_new GtkIMContext

Qt: https://doc.qt.io/qt-6/qinputmethod.html https://doc.qt.io/qt-6/qinputmethodevent.html

The best documentation about how to use those API is the built-in widget implementation.

SDL & winit

If you are using SDL, or rust’s winit, which does have some sort of input method support, but lack of built-in widget (There might be third-party library based on them, which I have no knowledge of), you will need to refer to their IME API to do some manual work, or their demos.

Refer to their offical documentation and examples for the reference:

https://wiki.libsdl.org/SDL2/Tutorials-TextInput

https://github.com/libsdl-org/SDL/blob/main/test/testime.c

https://github.com/rust-windowing/winit/blob/master/examples/ime.rs

Xlib & XCB

Xlib has built-in XIM protocol support, which you may access via Xlib APIs. I found a good article about how to add input method support with Xlib at:

https://tedyin.com/posts/a-brief-intro-to-linux-input-method-framework/

As for XCB, you will need to use a third-party library. I wrote one for XCB for both server and client side XIM. If you need a demo of it, you can find one at:

https://github.com/fcitx/xcb-imdkit/blob/master/test/client_demo.c

Someone also wrote a rust binding for it, which is used by wezterm in real world project. Some demo code can be found at:

https://github.com/H-M-H/xcb-imdkit-rs/tree/master/examples

wayland-client

As for writing a native wayland application from scratch with wayland-client, then you will want to pick the client side input method protocol first. The only common well supported (GNOME, KWin, wlroots, etc, but not weston, just FYI) one is:

https://wayland.app/protocols/text-input-unstable-v3

2. How to write one with the APIs above?

If you use a toolkit with widget that can already support input method well, you can skip this and call it a day. But if you need to use low level interaction with input method, or just interested in how this works, you may continue to read. Usually it involves following steps:

1. Create a connection to input method service.
2. Tell input method, you want to communicate with it.
3. Keyboard event being forwarded to input method
4. input method decide how key event is handled.
5. Receives input method event that carries text that you need to show, or commit to the application.
6. Tell input method you are done with text input
7. Close the connection when your application ends, or the relevant widget destructs.

The 1st step sometimes contains two steps, a. create connection. b. create a server side object that represent a micro focus of your application. Usually, this is referred as “Input Context”. The toolkit may hide the these complexity with their own API.

Take Xlib case as an example:

1. Create the connection: XOpenIM
2. Create the input context: XCreateIC
3. Tell input method your application wants to use text input with input method: XSetICFocus
4. Forward keyevent to input method: XFilterEvent
5. Get committed text with XLookupString
6. When your widget/window lost focus, XUnsetICFocus
7. Clean up: XDestroyIC, XCloseIM.

Take wayland-client + text-input-v3 as an example

1. Get global singleton object from registry: zwp_text_input_manager_v3
2. Call zwp_text_input_manager_v3.get_text_input
3. Call zwp_text_input_v3.enable
4. Key event is forward to input method by compositor, nothing related to keyboard event need to be done on client side.
5. Get committed text zwp_text_input_v3.commit_string
6. Call zwp_text_input_v3.disable
7. Destroy relevant wayland proxy object.

And always, read the example provided by the toolkit to get a better idea.

3. Some other concepts except commit the text

Support input method is not only about forwarding key event and get text from input method. There are some more interaction required between application and input method that is important to give better user experience.

Preedit

Preedit is a piece of text that is display by application that represents the composing state. See the screenshot at the beginning of this article, the “underline” text is the “preedit”. Preedit contains the text and optionally some formatting information to show some rich information.

Surrounding Text

Surrounding text is an optional information that application can provide to input method. It contains text around the cursor, where the cursor and user selection is. Input method may use those information to provide better prediction. For example, if your text box has “I love |” ( | is the cursor). With surrounding text, input method will know that there is already “I love ” in the box and may predict your next word as “you” so you don’t need to type “y-o-u” but just select from the prediciton.

Surrounding text is not supported by XIM. Also, not all application can provide valid surrounding text information, for example terminal app.

Reporting cursor position on the window

Many input method engine needs to show a popup window to display some information. In order to allow input method place the window just at the position of the cursor (blinking one), application will need to let input method know where the cursor is.

Notify the state change that happens on the application side

For example, even if user is in the middle of composing something, they may still choose to use mouse click another place in the text box, or the text content is changed programmatically by app’s own logic. When such things happens, application may need to notify that the state need a “reset”. Usually this is also called “reset” in the relevant API.

Commit: https://invent.kde.org/qt/qt/qt5/-/commit/281044e2541c842f8d0b0bc1a199999bf9d9951c

Commercial release announcement: https://www.qt.io/blog/commercial-lts-qt-5.15.8-released

As usual I want to personally extend my gratitude to the Commercial users of Qt for beta testing Qt 5.15.8 for the rest of us.

The Commercial Qt 5.15.8 release introduced two bugs that have later been fixed. Thanks to that, our Patchset Collection has been able to incorporate the the fix for one of the issues [1] and revert for the other [2]  and the Free Software users will never be affected by it! 

P.S: Special shout-out to Andreas Sturmlechner for identifying the fix of the issue, since I usually only pay attention to "Revert XYZ" commits and this one is not a revert but subsequent improvement

Wayland has a unique way to let clients specify the contents of the cursor. After receiving a wl_pointer.enter event, the client must call wl_pointer.set_cursor request

    <request name="set_cursor">
      <arg name="serial" type="uint" summary="serial number of the enter event"/>
      <arg name="surface" type="object" interface="wl_surface" allow-null="true"
	   summary="pointer surface"/>
      <arg name="hotspot_x" type="int" summary="surface-local x coordinate"/>
      <arg name="hotspot_y" type="int" summary="surface-local y coordinate"/>
    </request>

The wl_pointer.set_cursor request takes an optional wl_surface object that represents the actual contents of the cursor. That’s it, the wl_surface interface is used both by windows and cursors! It opens a whole lot of features that you could use with the cursor, for example use the wp_viewport protocol for fractional scaling or create cursor surface trees using the wl_subcompositor interface. On the other hand, many compositors view the cursor as a simple image. So, let’s see how we improved kwin in this regard.

Cursor source

Currently (as of 5.26.x), kwin assumes that the cursor can show only a QImage. It’s okay for simple cases, but it falls apart once we need to show a wl_surface, e.g. we will hit problems with getting a QImage from a linux dmabuf client buffer.

So the first thing that we need to do in order to move anywhere forward is to choose proper abstractions to represent what is actually in the cursor. For example, if the cursor hovers a window, it obviously needs to present what the corresponding wl_surface contains. But sometimes the mouse cursor is not above any window, for example if the pointer is above a server-side decoration. Server-side decoration can be considered part of the window, but we cannot use client’s wl_surface anymore, the compositor may choose to show a different cursor, which is a QImage.

class KWIN_EXPORT CursorSource : public QObject
{
    Q_OBJECT

public:
    explicit CursorSource(QObject *parent = nullptr);

    QImage image() const;
    QSize size() const;
    QPoint hotspot() const;

Q_SIGNALS:
    void changed();
};

The CursorSource class is the base class for all other “source” classes that can be attached to the cursor. It contains generic properties, e.g. the hotspot, and it also contains the CursorSource::changed() signal to tell the world when the image has changed. CursorSource::image() exists for compatibility and to make the transition to new abstractions easier.

Sometimes, we need to show a static image in the cursor, so let’s add an ImageCursorSource to serve that purpose

class ImageCursorSource : public CursorSource
{
public:
    explicit ImageCursorSource(QObject *parent = nullptr);

public Q_SLOTS:
    void update(const QImage &image, const QPoint &hotspot);
};

On the other hand, some cursors are not static. For example, the loading cursor usually contains some animation, e.g. spinning wheel

class ShapeCursorSource : public CursorSource
{
public:
    explicit ShapeCursorSource(QObject *parent = nullptr);

    QByteArray shape() const;
    void setShape(const QByteArray &shape);
    void setShape(Qt::CursorShape shape);

    KXcursorTheme theme() const;
    void setTheme(const KXcursorTheme &theme);

private:
    void refresh();
    void selectNextSprite();
    void selectSprite(int index);

    KXcursorTheme m_theme;
    QByteArray m_shape;
    QVector<KXcursorSprite> m_sprites;
    QTimer m_delayTimer;
    int m_currentSprite = -1;
};

The ShapeCursorSource class represents a cursor shape from an Xcursor theme. It can be used to show both animated and static cursors. If the given cursor shape is animated, i.e. it has more than one sprite, ShapeCursorSource will start a timer with the timeout as indicated by the cursor theme. When the timer expires, ShapeCursorSource will switch to the next sprite and emit the CursorSource::changed() signal. If it’s the last sprite, it will wrap around to the first sprite.

And last but not least, we need something to represent wl_surface attached to the cursor

class SurfaceCursorSource : public CursorSource
{
public:
    explicit SurfaceCursorSource(QObject *parent = nullptr);

    KWaylandServer::SurfaceInterface *surface() const;

public Q_SLOTS:
    void update(KWaylandServer::SurfaceInterface *surface, const QPoint &hotspot);
};

ImageCursorSource, ShapeCursorSource, and SurfaceCursorSource are the main types that indicate what the cursor shows.

Scene

The CursorSource classes act as data sources, they don’t actually paint anything on the screen. It’s the responsibility of the scene. I’ve already written a little bit about the scene abstraction in kwin, I recommend you to read my earlier blog post about it https://blog.vladzahorodnii.com/2021/04/12/scene-items-in-kwin/

But as a quick recap: kwin breaks up a window in smaller building blocks called items. The DecorationItem corresponds to the server-side decoration if there’s one. The ShadowItem is a server-side drop shadow, for example a drop shadow cast by the decoration or the panel. The SurfaceItem represents the actual window contents. That’s the same strategy that we will follow here. The cursor will be broken in smaller pieces.

If we look closely at our cursor sources, the painting code should handle only two cases – paint a QImage and paint an arbitrary wl_surface tree. The wl_surface case is already taken care by SurfaceItem \o/, so we just need a new type of item to present an image in the scene graph, e.g. ImageItem

The CursorItem type ties both cases together. It monitors what source is attached to the cursor and creates either a SurfaceItem or an ImageItem according to the type of the cursor source

• If a SurfaceCursorSource is attached to the cursor, the CursorItem is going to destroy its child ImageItem (if there’s one) and create a SurfaceItem tree
• If an ImageCursorSource or a ShapeCursorSource is attached to the cursor, the CursorItem is going to destroy its child SurfaceItem (if there’s one) and create an ImageItem child item

Note that SurfaceItems are rendered the same way regardless of their role.

With all of this, kwin can easily handle simple cases such as displaying an image in the cursor and more esoteric things that you can do with a wl_surface.

Cursor layer

The last thing that’s needed to make cursor handling perfect is putting the cursor on its own hardware plane. Imagine that you move the mouse cursor. Ideally, you should not repaint any windows below the cursor, only update the position of the cursor. Unless the windows need to repaint their content because of new pointer position, e.g. add or remove button outlines, etc. It can be achieved by painting the cursor in its own plane.

KWin already attempts to put the cursor on hardware planes, but we would like to clean things up and unify cursor and overlay planes. It is still work in progress. TBA.

Summary

The new cursor design is more powerful and should make it easier to add new fancy features. For example, it would be amazing if you could wire the velocity of the cursor to its scale so you could shake the pointer in order to find the cursor more easily. The new design also fixes longstanding limitations that prevented kwin from displaying cursors rendered by OpenGL or Vulkan.

Happy new year! To get a good start in this new new year, I’m happy to announce that Tokodon 23.01.0 is out! This is a new major release for Tokodon and while it’s been only 2 weeks since the last major release, this release is packed with new features and improvements.

Tokodon is a Mastodon/Pleroma/Nextcloud Social client built with Kirigami that I started back in spring 2021. Tokodon has a great integration with KDE Plasma and Plasma Mobile, but it also work on other desktop environments and even Windows and macOS.

Get it!

You can download Tokodon 23.01.0 from Flathub and from the F-Droid using the KDE repo. Currently we don’t offer binaries for Windows and macOS but if you want to help with that, please get in touch. build

New timeline design

The first thing you will notice, when trying out this new version, is the new layout of the timelines.

I updated it to follow more closely the design of Mastodon web-UI and I also spent some time adjusting the spacing and typographie to be more consistent.

Search

It is now possible to search for posts, accounts and tags directly from within Tokodon.

Hashtag Handling

Tokodon now handles hashtags better. Previously, when clicking on a hashtag, Tokodon would redirect you to the website where you could see the posts that included the selected hashtag. Now you don’t need to leave Tokodon anymore, and the posts are displayed inside the app like any other timeline.

Conversation View

Tokodon now includes a basic conversation view. This shows the list of your last direct conversations. This makes it possible to see your conversation in a much nicer way than with the latest mentions view.

I plan to improve this feature further in the future, as I will be adding support for conversation markers and maybe offer a real chat-like view for conversations (which I will shamelessly steal from NeoChat).

Poll Support

It’s now possible to view and interact with polls. This supports both multiple choice and single choice polls, but creating new polls is still not possible.

Account Editor

I also added an account editor. The merge request was actually 10 months old and I started it during a stream at the last FOSDEM. As you might imagine, it was not that fun to rebase. But it is finally possible to edit your account metadata and preferences directly from Tokodon.

I also submitted a pull request in Mastodon itself to expose more settings in the API.

Real-Time Timeline Update

Tokodon was already handling some real-time events coming from the server, but until now this only included notifications. Now Tokodon will also handle new incoming messages and add them to the timeline. It will also delete messages as soon as the server asks for them to be deleted.

Technical Details

Aside from the many new features, there was several large re-factorings of the code base to cleanup some code that younger-me wrote. The C++ code base now has a coverage of 35%, and I am pretty happy with this increase from 12% of the previous release.

Coming next, I want to focus more on the post editor. The back-end also needs to be cleaned up and several important features are still missing (choosing the language, posting polls and adding alternative textual descriptions to images). I already created a branch for that and you can follow the work on this merge request.

Get Involved

If you are interested in helping, don’t hesitate to reach out in the Tokodon matrix channel (#tokodon:kde.org) and I would be happy to guide you.

I’m also regularly posting about my progress on Tokodon (and other KDE apps) on my Mastodon account, so don’t hesitate to follow me ;)

And in case, you missed it, as a member of the fundraising working group, I need to remind you that KDE is currently running an end of the year campaign. Don’t hesitate to donate!

Packager section

You can find the package on download.kde.org and it has been signed with my GPG key.

Kraft, which was released as version 1.0 after long time of active development, is targetted to the Linux desktop. My firm conviction is that the Linux desktop is very suitable for the target group of Kraft: In the small office of craftsmen for example, a Linux desktop is a great work horse which is stable, very well adoptable and has a great amount of applications that are stable and maintained.

These are only the most obvious points why Kraft is so far only available for Linux.

But often enough switching to Linux is another hurdle that users have to go, coming from a more mainstream world. So it is great to learn that Kraft, as many UI applications, can be run unter the Windows Subsystem for Linux (WSL) on Windows systems quite flawlessly.

It was tried with Windows 11 Home and the Kraft AppImage of 1.0.

The steps to run Kraft in WSL:

• Make WSL running on the Windows installation
• Install a X-server on the Windows machine
• Create a Debian or Ubuntu Linux subsystem
• Install a few extra packages into the Linux installation
• Download and run the Kraft AppImage 1.0

A more detailed howto and discussion can be found in the easy cash & tax forum. Thanks Thomas for bringing up the topic and providing the Howto!

Dear digiKam fans and users,

A new year means new goals, and this one is a challenge: migrating the old digiKam documentation based on DocBook format to a new architecture, more simple and easy to maintain. After 20 years, we left the DocBook manual for the modern Sphinx/ReStructuredText framework. This one is really a pleasure to use by documentation writers.

The content is published in a dedicated web site, internationalized by the KDE translation teams. An EPUB version is also available for the off-line use cases.

Two month ago, in October 2022, KDE's GitLab made me use a two-factor authentication (2FA). Without a second factor, I was no longer able to push code, comment on merge requests, or contribute anything meaningful on KDE Invent.

For a long time, I have known I should use two-factor authentication for my important accounts; especially for those accounts used to commit code other people are executing because they trust me. But I was too lazy to have everything prepared to use the second factor.

Thanks to Ben and the KDE infrastructure team, there were no more excuses and I had to set up a secure login.

Secure login, but don't lock yourself out 

Having a second factor, it is important that I am not locked out, if my second factor is left at home or broken. Here is what I did:

1. The first step is to choose the second factor. I decided against dedicated hardware like a Yubi key. I am familiar with one-time passwords on my mobile phone, thus, I decided to use Time-based one-time password (TOTP). This means a device or mobile app knows a secret to calculate a six-digit one-time password. The password is only valid for a couple of seconds, then a new one can be generated locally. I use Google Authenticator, but there are alternatives from less controversial vendors. Just scan the QR code and verify the secret by once entering a one-time code.
2. I installed Keepass to store the recovery codes in case my TOTP device is broken or stolen. As a side effect, I can now use more complex passwords for less frequently used passwords.
3. I made a backup including the Keepass database.
   
4. As a side-effect, I need to use tokens for checkouts and pushes. A great opportunity to have this aspect of secure development activated, too.
   

Remaining open questions

Some questions remain open for me. Time will tell, how much they bug me and where I need to adjust.

Currently, I only have my personal phone as a TOTP device. Maybe I want to add more phones or my iPad. I am also unsure whether I should install and use a TOTP software on my desktop like KDE Keysmith. It is a weighting of comfort, security, and reliability.

By-product: More security everywhere

Now that I have everything prepared on my side to use TOTP as my two-factor authentication, it was easy to use it for all the other accounts that deserve some extra protection: GitLab.com, GitHub, and independent GitLab instances hosted by FOSS projects similar to KDE Invent. Even my Google account is now protected by a TOTP mechanism and I no longer get text messages to my mobile phone. Further, I stored ten security codes from Google, just in case.

Having a security spree, I also wanted to use TOTP for my banking accounts. Unfortunately, my banks insist on the use of their own app. I think they could benefit from using open and established standards, but they decided to force us costumers to install and use their apps.

Let’s go for my web review for the week 2022-52. Last one before 2023 appears.

2022 was the year of Linux on the Desktop - Justin Garrison

Tags: tech, linux, desktop, foss

There it is… at least for the developers and gamers demographic.

https://www.justingarrison.com/blog/year-of-linux-desktop/

I’m Done With Google

Tags: tech, DRM, vendor-lockin

More DRM anyone? It’s just a pain and locking people out.

https://deijin.bearblog.dev/im-done-with-google/

Here’s who helped Elon Musk buy Twitter - The Washington Post

Tags: tech, business, social-media, politics

As they say: follow the money. That gives an idea about the incentives and various agendas behind this take over.

https://www.washingtonpost.com/technology/2022/12/24/elon-musk-twitter-funders/

Escaping the Algorithms | Commonweal Magazine

Tags: tech, ai, gpt, culture, philosophy

There are a few reasons to worry about the latest strain of generative neural networks. One of them is the trust we can place in new generated content. The other one is indeed the impact on our culture. There’s been already a trend at focusing on what sells rather than what’s truly novel or avant-garde. This could well push it further. We’ll we drown in mediocre content?

https://www.commonwealmagazine.org/artificial-intelligence-AI-social-media-Heidegger

AI: Markets for Lemons, and the Great Logging Off

Tags: tech, ai, neural-networks, gpt, trust, culture

A few compelling arguments for the impact of the latest strain of generative neural networks. The consequences for the eroded trust about online content are clear. I’m less convinced about some of the longer term predictions this piece proposes though.

https://www.fortressofdoors.com/ai-markets-for-lemons-and-the-great-logging-off/

IDN is crazy | daniel.haxx.se

Tags: tech, security, dns

International Domain Names indeed opened a whole can of worms. This creates plenty of opportunities for confusions and mistakes waiting to happen… or to be exploited.

https://daniel.haxx.se/blog/2022/12/14/idn-is-crazy/

Dioxus

User interfaces that run anywhere Tags: tech, rust, frontend, webassembly

Looks like an interesting frontend stack. Still young but probably worth keeping an eye on.

https://dioxuslabs.com/

More use of Rust is inevitable in open source software

Tags: tech, system, programming, safety, rust

Like it or not, this is definitely filling a very unique niche. It’s a very good fit for system software where safety is important and available time limited. There is no better option for now.

https://utcc.utoronto.ca/~cks/space/blog/programming/RustIsInevitable

The Bitter Truth: Python 3.11, Cython, C++ Performance | Agents and Robots

Tags: tech, simulation, python, c++, performance

Python is getting faster but is still far from what you can get with C++ of course. That said, for simulations you likely don’t want everything in Python or in C++. Part of the challenge is to split the subsystems properly and use C++ where it matters.

https://medium.com/agents-and-robots/the-bitter-truth-python-3-11-vs-cython-vs-c-performance-for-simulations-babc85cdfef5

Hash Collision Probabilities

Tags: tech, hash, probability

Nice article. Keep an eye on potential collisions indeed. Depending on the use of your hashes this can be critical.

https://preshing.com/20110504/hash-collision-probabilities/

Golang is evil on shitty networks

Tags: tech, go, networking

This is indeed a strange default used for sockets there… will have bad consequences for sure in more situations than expected.

https://withinboredom.info/blog/2022/12/29/golang-is-evil-on-shitty-networks/

A Gentler, Better Way to Change Minds - The Atlantic

Tags: culture, life, values

Good and reasonable advices… doesn’t make them easy to truly apply though. It’s likely worth trying to live by them still.

https://www.theatlantic.com/family/archive/2022/04/arguing-with-someone-different-values/629495/

Sherlock Holmes will finally escape copyright this weekend - The Verge

Tags: culture, public-domain

Now, rejoice! This is a big body of work entering public domain, at last! Will Mickey Mouse finally be next?

https://www.theverge.com/2022/12/28/23528003/sherlock-holmes-metropolis-to-the-lighthouse-public-domain-day-2023

Bye for now!

What is a vacation without a nice side project? – My small x-mas project was to get my RISC-V Allwinner D1 Nezha board finally into a state that it shows anything on the connected HDMI-port. Any, “yeah!!!”, it works:

This picture shows qmlscene rendering a rotating yellow rectangle at 2 fps (speed is limited due to yet missing HW acceleration support).

A few words about the board

Compared to other embedded boards that I have, this one is surprisingly well documented; given you find the right webpages (list at the end). The vendor page itself is in a rather typical state, where an online translator occasionally comes handy to translate Chinese into something I understand But then, there is the really nice sunxi community wiki with has all extra information that you need.

For the device itself, some months ago I decided to get this one mostly because of the reasons price and delivery date. However, it has a big disadvantage for me when I use it for testing the KDE Yocto layers: There is only a 2D GPU on the board (namely a “G2D” unit) for which also no Kernel drivers are present at the moment (except those from the Kernel source blob by the device vendor). However, for all other parts there is impressive community work. Most notably, coming with Kernel 6.2, there is finally the HDMI driver support that made the above picture possible.

The few steps left for me

As said, there is a really good documentation about compiling a close-to-mainline Kernel and u-boot for this board. Moreover, the meta-riscv Yocto layer provides recipes to build a full device image with Kernel 5.16 and a patched/hacked u-boot (using an older boot sequence) with a nice out-of-the-box experience.

So, to get graphics/HDMI working on the board, all that was left for me was following the wiki documentation and:

• switch to the latest Kernel fork based on 6.1 with all the relevant patches
• and adapt U-Boot to a more recent fork that can boot this more mainline Kernel fork.

The details are summarized in this PR for the meta-riscv layer. It essentially drops as much non-mainline tweaks as possible and adapts the recipes along the way. Simple as it looks, it was quite a fun ride down the rabbit hole until I got my first booting Kernel I really think that this tinkering around with hardware is the best way to learn its concepts. Even though I attended many talks in the past about the steps I did, it is so different when you are doing it yourself.

What comes next

Unfortunately, I do not expect any Plasma or KDE application running on the Nezha board in the sooonish future (at least not accelerated via the G2D chip)… Yet, if you recall, at FOSDEM 2019 Alistair already demonstrated Plasma running on a HiFive Unleashed board, using an expansion board for graphics. Finally, there is right now another very interesting and not too expensive RISC-V board becoming available with on-board 3D GPU and it is already on my shopping list… I am looking forward to 2023

Collected Links

• https://linux-sunxi.org/Allwinner_Nezha – General introduction and bring-up by the sunxi community
• https://linux-sunxi.org/U-Boot – flashing instructions by the sunxi community
• https://fedoraproject.org/wiki/Architectures/RISC-V/Allwinner – Fedora wiki for D1 support (note: it uses the “old” boot up)
• https://www.rvboards.org/mkdocs/en/nezha-d1/ – English documentation by the HW vendor
• https://github.com/YuzukiTsuru/OpenixCard – a nice tool that can convert Allwinner PhoenixCard images to default IMG files that can be flashed via dd on Linux (e..g when you want to test the vendor image)

It is a pleasure to announce that Kraft Version 1.0 was released last week.

What is Kraft?

Kraft is free software to create office documents like offers and invoices in an efficient way. It runs on the Linux desktop and suits small businesses of all kinds.

After countless releases with version numbers 0.x, Kraft finally goes with version number 1.0 with this release. It is in production at several companies since many years, and with this release it got many more improvements that make it a really mature product.

Highlights

Lets take a look on the highlights of of version 1.0.

AppImage Support

Installing software properly is still a challenge for many users. AppImage comes to the rescue there: Single file, easy to download and start with all dependencies included makes it easy for users. For the creator, it is just one-fits-all, which makes it easy to maintain.

The new Kraft AppImage was carefully reworked and has now really all dependencies included, has a complete own icon set and was tested thoroughly. It is ready for production now.

Giro Code

Kraft now can print the EPC QR Code on invoices easily. Users just have to configure the bank account data to use, and Kraft creates the QR code automatically to be included in the documentation template.

User Manual

The Kraft user manual got great improvements again. It comes with even more and improved text, with much more screenshots and improved translations.

This is a community contributions that is so important for Kraft.

Many other Improvements

There were many other improvements: New functionality such as the new day counter for the number cycle templates (allows to have a counter in the document number that resets to 1 every day) or new modes for the watermark functionality to complete the generated PDF documents plus much more details (See Changelog).

How it continues

Kraft is up and running - and maintained. The plan is to keep the 1.0 as a kind of LTS in a stable branch, that only gets urgent fixes for stability.

For master, I am planning to do a couple of more intrusive changes that will take a bit longer.

See the roadmap discussion here.

Curious?

I hope you got a bit curious now about Kraft. Feel free to check it out using the AppImage.

If you find it an useful addition to the Linux application ecosystem that enables more users for Linux we’d very much appreciate your contribution!