I am pleased to announce Linux-Stopmotion release 0.8.6! The last release was three years ago and this is the first release since Stopmotion became a KDE incubator project.
About Stopmotion
Stopmotion is a Free Open Source application to create stop-motion animations. It helps you capture and edit the frames of your animation and export them as a single file.
Direct capture from webcams, MiniDV cameras, and DSLR cameras. It offers onion-skinning, import images from disk, and time lapse photography. Stopmotion supports multiple scenes, frame editing, basic sound track, animation playback at different frame rates, and GIMP integration for image. Movies can be exported to a file and to Cinelerra frame lists.
Technically, it is a C++ / Qt application with optional dependencies to camera capture libraries.
Changes in release 0.8.6
This release does not contain new features but provides changes under the hood.
New build system using CMake. The qmake one is deprecated and will be removed.
The test executable can be executed as a CMake test target (make test-stopmotion && make test).
Fixed various warnings from Clang, GCC, and Qt 5.15.
We have a build pipeline executing automated builds and tests.
Future plans
We decided to renamed the application to KStopmotion, as Linux is trademarked.
Transition from Qt 5 to version 6.
We should integrate better to KDE's tech stack: Internationalization, using KDE libraries, update and reformat documentation.
Get involved!
If you are interested, give Stopmotion a try. Reach out to our mailing list kstopmotion@kde.org to share ideas or get involved.
You can also help to improve Stopmotion. For example, we started the transition to Qt 6 and we welcome any helping hand.
Journalists (And Others) Should Leave Twitter. Here’s How They Can Get Started | Techdirt
Tags: tech, attention-economy, twitter, fediverse
Let’s hope journalists hear that call. It’s indeed sad that so far it’s mostly words and not many actions to move away from Twitter in that profession.
The internet wants to be fragmented - by Noah Smith
Tags: tech, social-media, internet
Interesting take, let’s see if it’s true and things will decentralize (or at least audiences fragment, the author seems to confuse both) more in the future.
Interesting piece. It shows quite well what users have lost with the over reliance on HTTP for everything. Moving more and more things in the brother fosters walled gardens indeed. Compound this with branding obsession from most company and you indeed end up with an absurd situation.
Excellent piece, looking back to history to justify why microservices are mostly a fad. Check what your needs really are and depending on them pick the right way to decompose the problem or organize your teams.
Microfeatures I’d like to see in more languages • Buttondown
Tags: tech, programming
Since I’m also a bit of a nerd of nice programming language features, that’s an interesting list (mostly) coming from less known languages. Some of that syntactic sugar would be welcome in more main stream languages I think.
Test Desiderata. Go placidly amid the noise and haste… | by Kent Beck | Medium
Tags: tech, tests, tdd
This what we should strive for with our tests. I like how he keeps it flexible though, again it’s likely a trade-off so you can’t have all the properties fully all the time. Still you need to know what you give up, how much of it and why.
Fast Path to a Great UX – Increased Exposure Hours — UX Articles by UIE
Tags: tech, ux
A bit old but interesting finding. Kind of confirms my own view about it: it’s best when everyone (not just designers) can interact with the users of the system you’re building.
Sign-up Versus Assignment - by Kent Beck - Geek Incentives
Tags: tech, project-management, management
It’s clearly a choice in management style. For such choices, always keep in mind the trade offs this create, maybe it’ll push you to revise your choice.
Like it or not (I’m part of those who don’t like it) but the role of manager will necessarily create power imbalances. This article is thus a must read to managers at any level to know how to deal with it properly.
Very interesting model, I didn’t know about this one. As pointed out you can’t really base policy decisions upon it but that’s still powerful since it explains some of the phenomena at play in the real world. In this way it is enough to debunk some of the assumptions taken a bit too much for granted.
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.
In the screenshot above, user just type “d e s h i j i e”, and the input method gives a list of candidates. Modern Input method always tries to be smarter to predict the most possible word that the user wants to type. And then, user may use digit key to select the candidate either fully or partially.
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.
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:
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:
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:
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:
Create a connection to input method service.
Tell input method, you want to communicate with it.
Keyboard event being forwarded to input method
input method decide how key event is handled.
Receives input method event that carries text that you need to show, or commit to the application.
Tell input method you are done with text input
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:
Create the connection: XOpenIM
Create the input context: XCreateIC
Tell input method your application wants to use text input with input method: XSetICFocus
Key event is forward to input method by compositor, nothing related to keyboard event need to be done on client side.
Get committed text zwp_text_input_v3.commit_string
Call zwp_text_input_v3.disable
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.
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.
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
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.
Red square is the cursor surface, the green square is its subsurface. No idea why you would want to do this, but kwin should handle this fine now
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.
Tokodon main view
Search
It is now possible to search for posts, accounts and tags directly from within Tokodon.
Search field inside 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.
Conversation in Tokodon
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.
Poll in Tokodon
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.
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.
And for those who prefer a full changelog, here it is:
Update year
Update to 23.01
Cleanup notification model
Cleanup loading handling
Fix timezone handling
Remove dead code
Remove refreshing button now that refreshing happens automatically
implemented update notifications
Tweak appstream summary
timelinemodel fix crash if json array is empty
Fix unit tests
Fix loading timelines
Correctly handle streaming event about new and deleted posts
Remove debug output
Release new version 22.12.0
Cleanup and fix account model
Fix search on mobile
Reduce number of warning in logs
TootComposer.qml fix qmlscene issue "missing ":""
Run clang format
Fix rendering of poll when no vote has been submitted
Handle pressing back button with image preview open
Remove dead code
AuthorizationPage.qml authorize token URL should wrap
Add more tests
Cleanup backend code for profile edition
Port to mobileform
Account editor (second try)
fix: No Preview for Hashtag links
Dont't show account switcher when no account is loaded
Fix clazy issues
Fix some compile warning
More testing
Add tests for threading
Improve thread UI
Fix opening thread
Clang format
Add more tests and fix canFetchMore behavior
Fix marking post as pinned
More refactoring
Remove fetching and fully replace by loading
Tag handling
Ship our own icon
Update icon name
Fix checkable state
Add unit test
Use breeze icons
Add conversation view
Remove dead code
Handle case where no spelled is installed
Fix crash in notification view when interacting with post
Propagate visibility in replies
Don't reset timeline when switching account
Fix accountModel returned by follow activity
Display blurhash when loading image
Don't show link preview on mobile
Fix replies count
Improve default debug output
Optimize tooltip in PostDelegate
Fix fetching the global timeline
Fix replying to someone add yourself as mention
Improve spacing of text field
Improve overall spacing
Add more unit tests
Implement searching for accounts and posts
Add a NetworkProxy page to settings
Port AuthorizationPage to MobileForm
Improve layout of already voted polls
Add more tests
Implement polls in the frontend
Add poll implementation in backend
Fix test
Reduce spacing between action and author
Update post layout
Remove duplicate headers between cpp/h files
Workaround kirigami regression
Don't show drawer handle when showing full screen image
Fix crash when loading own account
Fix appdata version
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!
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
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:
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.
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.
I made a backup including the Keepass database.
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.
I have not yet made up my mind, how to handel the tokens for checkout and pushes. Having them in an open document in Kate might be more harmful then using my password as in the past. I consider storing them in Keepass, too.
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.
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?
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.
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.
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.
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.
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
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)
ervin
It was tried with Windows 11 Home and the Kraft AppImage of 1.0.
But then, there is the really nice 
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.