After posting the Plasma 5.14 “Cluster” wallpaper and asking for feedback there was a huge response, and after a few days of big changes and finer adjustments I hope this will serve as a satisfactory wallpaper. I’d like to thank everyone who offered constructive feedback, pitched in ideas, and even offered examples, you’re amazing!

Cluster and the source SVG file are now available on OpenDesktop and the KDE Store. For those seeking the Krita source file, please contact me directly and I will ensure it’s available somewhere.

The time for a new Plasma wallpaper is here, so for 5.14 I’m excited to offer up “Cluster”.

But first, please allow me to gush for a moment. In tandem with Inkscape, this is the first wallpaper for KDE produced using the ever excellent Krita. For graphic design my computer has a bit of beef to it, but when I work with Inkscape or GIMP things always chug just a bit more than I feel they should. Whenever I’ve had the distinct pleasure of opening Krita, even on my lesser powered laptop, it’s always been productive, rewarding, and performant. I’m looking forward to using Krita more in future wallpapers. *claps for Krita*

Now, with pixmaps there’s always a valid concern that higher-resolution monitors will suffer blurring because of low native resolutions. The master file for this slightly larger than 8k, so hopefully this will not be an issue. The only potential problem this causes is the large size of the master files. The Inkscape source will be published when the final wallpaper is released as per usual (just under 50MB), but the Krita-based assets are only going to be available on request. This is because the .kra is 135MB, and I have a feeling a few people might be angry if I load that onto the shared server. Unless they read this and tell me it’s fine. Who knows!

The wallpaper still has a polish pass, so rough edges or things that might feel awkward will be ironed out before it’s committed. If you have feedback you can comment here or over on the Reddit thread: https://www.reddit.com/r/kde/comments/90syno/plasma_514_wallpaper_cluster/

Here it is;

Click here for 8K image

Earlier this week I got my dirty hands on an RX Vega 64 card to run on my daily workstation. With the aim to eventually run open drivers in the future my main goal for now was to get AMDGPU-PRO running for day-to-day activities, possibly also moving to Wayland from X11. I’m very interested in Wayland as Kwin has several Wayland-only enhancements, and even if I wouldn’t use it now I wanted to be ready for testing.  The Vega card would be replacing an Nvidia GTX 1080 card.

In terms of usage I look to beefy video cards for when I do the odd video-related task, for applications like Krita, and other reasons up to and including general enthusiasm.

Since it’s been a pretty rough experience I figured I’d blog about the state of Vega with Plasma, my opinions, and my hopes for the future.

Hardware

Because of the stock shortages which have been pretty persistent I ordered the standard edition sapphire card when I stumbled across one that somehow hadn’t sold out.

I like the understated design of it, and despite its more simple looking build it does look and feel premium – moreso than it does in review videos. When active the Radeon text on the side glows red, and there is also a “GPU Tachometer” which shows the load on the card. There are also hardware switches which let you recolor or disable the LEDs.

Driver, Kernel, and Installation

This is my first gripe. The AMDGPU-PRO driver installer from the AMD website hardcodes specific distribution names into the installer .sh file. In order to install the AMD driver onto KDE Neon I had to edit the file and change “ubuntu” to “neon”, as otherwise the installer will halt and state that you cannot run the install. It felt a bit wrong and I’m wondering if AMD should add in a warning and continuation option should the string check fail, such as “this us unsupported and could pooch your installation, continue anyway? (y/n)”

With the string change the installer worked without complaint, but I ran into another problem after restarting: the black screen of doom when graphics have failed to start. After researching I found it was caused because my installation of KDE Neon didn’t use the hardware enablement stack or “HWE” as offered by Ubuntu LTS. After I enabled the HWE I was able to get into an X11 session.

Once I was in an X11 session screen tearing was fairly extreme. On researching I found out I could add the “TearFree” option in “10-amdgpu-pro.conf” to solve this issue. At this point I figured I solved all the major adoption problems to get back to my previous baseline from my time on the Nvidia card, so a reboot was in order to try out a clean session.

Usage

Have you picked up that I’m not providing exact instructions on how to run AMDGPU-PRO drivers on Neon with Vega? It’s because as of the time of this writing, the experience is isn’t day-to-day usable and I won’t instruct you into a sub-par session. The drivers are still very new, and after I write this I’ll be re-installing my Nvidia drivers until I can try a Mesa session on stock kernel drivers.

Applications which make use of hardware acceleration will cause the system to stutter and hang, sometimes for a few seconds. My only conclusion given the hardware on my machine is that the PRO drivers have issues. I also find that sometimes opening applications at all will cause a momentary hang, with Kate causing a several second freeze which only fixed itself as I began reaching for the power button. These are also complete system locks at the kernel level, as I’m unable to switch to the TTY interfaces and manually restart the session or kill applications.

Game performance – as much as I “game” – is lackluster and glitchy under AMD. Remembering those reports of “Nvidia only” games on Linux I can suddenly and clearly understand why this is the case. I ran several of my neglected games from Steam and even a game like Factorio had glitches, while others like Rocket League were unplayable. Many were good, but all suffered performance issues. I think there’s an issue with loading and unloading data to the GPU, because the worst hangs seem to be during these steps. Rocket League took nearly 10 seconds to close and locked my entire system at this time. I simply gave up at this point with further game testing, being happy with none of the samples I tried.

I was unable to get Wayland working at this point. I’m sure I could have if I really wanted to, but my initial impressions with an X11 session were so lackluster that I decided anything Wayland would fix are still far outweighed by the general driver itself. For even simple desktop work there have been minor visual glitches, and I’ve caught moments of tearing several times despite being in TearFree mode.

In theory I could have used my Intel graphics to drive my displays, and there are instructions for doing this with Mesa drivers in headless mode on the AMD card. This would have let someone solve these problems, but sadly I didn’t have the outputs on my motherboard to support 2 Displayport displays and an HDMI tablet to try this.

Final Thoughts

I don’t know how much I want to ream on AMDGPU-PRO drivers or Vega at this point. While KDE Neon uses Ubuntu LTS as a base system, technically, the PRO drivers did state they weren’t compatible with my system. At the same time I know in theory they shouldn’t be having problems.

To a large degree I also expected the relatively overpowered card when used in my actual day-to-day activities to make up for any driver performance issues – I was banking on that. I don’t actually play my games so I don’t need Bioshock Infinite to run at 120fps – I need my desktop to run at 60. I either underestimated how badly the driver performs, or simply hit the wrong bugs, because for every minute of smooth operation I had with the driver there’s a hard stutter, hang, or jitter.

If you run Neon I can’t recommend a Vega card at this point, so I recommend you save your time and money until there’s an announcement stating that the generic Linux kernel can output to displays on Vega. At that point maybe even check back on my blog because I’ll be re-visiting Vega on Neon with Mesa, which from what I understand should be the experience I was expecting. Until then I’ll be putting the Nvidia card back into my machine for a stable desktop, as AMDGPU-PRO+Vega+Neon results in an unusable system at this point in time.

After posting the image of the 5.11 wallpaper feedback started coming in and one thing fairly consistently mentioned is how dark/muted it is. Of course, there were mixed opinions on whether it was good to be dark or if it was a little too far, but it was a clear observation, especially compared to the previous wallpapers.

So I took a few minutes to adjust the wallpaper. There were lots of people who liked having something more subtle, so I didn’t stray too far. I adjusted the blues to be more saturated, the browns are lighter towards the bottom to reduce banding, the orange is a bit brighter, and reds on the right were tweaked. I also reduced an “atmosphere” gradient. Lastly, I removed a noise filter used to combat banding.

Overall it’s not that much lighter, but it should be less muddy and washed out. If you didn’t have them side-by-side ideally you may not notice the changes, but hopefully it just feels a bit better.

Here’s the adjusted wallpaper:

Both versions are available on the KDE Store.

Well, it’s that time of the year again where I talk about wallpapers!

For those who watched the livestream of the beach wallpaper, you’ll notice this isn’t what I had been working on. Truth be told after the stream I hit a few artistic blocks which brought progress to a grinding halt. I plan to finish that wallpaper, but for this release I created something entirely different while I decide what to do with it. I enjoyed this “wireframe” effect, and will probably experiment with it again.

This wallpaper is named “Opal”, specifically after wood opal resulting from when water carrying mineral deposits will petrify wood it runs across. Wood opal is pretty special stuff, and often it can often look straight out of a fairy tale.

The Plasma 5.11 wallpaper “Opal” is available on the KDE Store.

[youtube https://www.youtube.com/watch?v=ocK54NsqN2Q]

Today I streamed the first half of the Plasma 5.11 wallpaper production, and it was an interesting experience. The video above is the abridged version sped up ~20x, heavily edited to the actual creation, and should be a fun watch for the interested.

It looks like there’s another full work-day that needs to go into the wallpaper still, and while I think I’ll also record the second half I don’t think I’ll livestream it; while I’m very appreciative of the viewers I had, it was quite a bit of extra work and quite difficult to carry on a one-man conversation for 8 hours, while working, for at most a few people. Like I said, I will still record the second half of the wallpaper for posterity, I simply don’t think I’ll be streaming it. I do think I’ll keep streaming the odd icon batch, as those are about as long as I want, so they can be kept to a digestible hour.

The wallpaper as it is is based on an image of a reef along with a recent trip to the beach during the Blue Systems sprint. There’s still a long way to go, and I can easily see another 8 hours going into this before it’s completed; there’s water effects, tides, doing the rocks, and taking a second pass at the foam – among other things – especially before I hit the level of KDE polish I’d like meet.

Looking at it, I may also make a reversed image with only the shoreline components for dual-screen aficionados.

Within the next week or so I’ll post the next timelapse after I complete the wallpaper. 😀

It’s getting to be that time of the release cycle where I’ll be making a new wallpaper for the next Plasma release. For the 5.11 cycle I’ll be doing things a bit differently owing to a request on Reddit several weeks back; this wallpaper is going to be done over a livestream!

The wallpaper livestream will be on Saturday the 20th, and start ~10:00am Eastern Daylight time, or 2:00pm GMT. I’m going to estimate the stream to last ~8-10 hours, with a couple short breaks somewhere in the middle.

The aim will be to get the majority of the wallpaper done during the stream (they take that long!), with anything done beyond the stream falling into tweaks and correction territory. There’s also the chance you may see a few attempts until I settle, as I have a few designs in mind and there may be some experimentation there along with some spectacular failures along the road.

I’ll keep a chat open, and I’ll field any questions I get, but beyond that I figure it will be the kind of stream people might like as background noise. I also suspect it might be the kind of thing people will want to minimize now and again – I think it will be a passive viewing experience. When the livestream is over I’ll go back and create a sped-up version which I’ll post on YouTube.

Which brings me to an important question I have for everyone who does or is into livestreams; I’ve never streamed before! I know about Twitch and YouTube, even Hangouts, and have heard about OBS; are there any recommendations for which streaming service/software I should broadcast with? Comment here (or on Reddit, I’ll be posting there) with input as to the best way to stream a fairly long art session. Also, I’m considering using a webcam as well – please let me know if that’s of interest, and if there’s software for a total rookie to do it. I’ll post the info on where I’ll be streaming once I figure out where it will be.

Lastly, if the stream is fairly successful at least on a technical level, I’ll look into shorter episodes featuring Aether icon development which would probably see rounds of 3-4 icons being completed in the space of a shorter session.

Earlier this week the decision was made to switch from Drupal to WordPress as the CMS used for the KDE.org main website. While Drupal is certainly a fine system, the decision to switch was borne when my quick work to update a WordPress asset turned into a serious venture much more successful than my work with Drupal. Prior to my contributing to KDE I used to develop on WP, and I was surprised to find out my experience largely held in this new version. In hindsight, WordPress was the obvious option considering this.

A round of discussion about formally switching ensued, and many other great reasons to use WordPress were present, including the much larger number of KDE websites on the platform. I won’t get into it too much as I’d instead like to go over the work done over the past week and some of the features coming to KDE.org Aether template which are already complete; today I’ll focus on the header, which had the most love.

The header will feature an up to 3-level menu, and in the future it may be made to not restrict the number of levels. But, for now, 3. It nicely scales back to two or one levels as appropriate. Currently the theme will pull featured images from root navigation elements and display them in the dropdown, but in the future this will likely become a navigation-specific setting for more control. As expected, the navigation is completely customizable. It is also responsive, and when it can no longer accommodate the number of menu items for the width of the given screen it will switch into ‘hamburger mode’ which works very well on mobile.

My personal favorite feature so far is the live search. This probably had the most work this week, and I really wanted to nail it down well. It’s a search-as-you-type system, but has several built-in features to avoid overloading servers, such as an adaptive delay until it performs a request and temporary localstorage caching.

Lastly, the theme is being built to be completely customizable for suitability on not only KDE.org itself, but even as far down as personal blogs which may not demand the full range of features being built into the design.

The design itself is forked from KdeTheme theme, which in turn was forked from Activello. It features thoughtful localization, and work is being done to make the individual components more modular so maintenance will be a cinch over the long game. There are still many features, options, and utilities being poured into the design, and I’ll be posting updates semi-regularly as the progress continues.

Ultimately, the KDE.org theme itself will be generic enough for use on any KDE-related site. As it matures enough to be in use on regular websites, the design will also be loaded onto the WordPress theme directory, allowing sites which may not enjoy the full KDE infrastructure (such as personal developer blogs) to easily install and keep the theme updated.

If you maintain a KDE-related website and are using Drupal, depending on the breadth of your content, we still have options for you. If you have a smaller website, I’ll be offering to port to WordPress if you desire. If you have features required which can be folded into the larger theme I will do so as appropriate, otherwise we can evaluate if a small site-specific plugin could serve that use-case. If you have a Drupal site too large to move – or you simply wish to stick on Drupal – after the KDE.org wordpress work is considered complete, the existing Drupal 7 theme will be updated to service existing websites. For anyone else maintaining a website looking to use this design I’m also taking feature requests for the theme and design elements at this point. Please send inquiries and requests to the kde-www mailing list.

Beyond the design itself, we have some exciting plans for managing content and applications which I’ll be posting about later.

What does everyones second-favourite Canadian developer do when he wakes up in the morning? First he makes coffee, usually by pouring coffee grounds and hot water directly into the sugar jar then drinking the resulting syrup. After that while he waits for the resulting diabetes and caffeine to kick in, he usually warms up for work by drawing a few icons to get into the productive mindset… This has been going on for a while.

So I’m pleased that this non-project has become complete enough that I believe I can share it around with the world a bit. Before I go on, I would like to express that this set is not an official project at this time. It may also randomly go totally unmaintained at any moment if the right people decide to strangle me.

Because I’ve been naming everything I get my hands on “Aether”, without further adieu I’m excited to present the Aether Icon Set;

Everything needs a logo.

The Aether icon set takes cues from several existing icon specifications, along with heavy influence from Material icons. My hope is that icons from this set could present on Android and other platforms without seeming too out of place. As KDE applications make use of our mobile and convergent frameworks, it will in time become just as important for our artwork to be as portable as our applications.

The general design of the icons includes the use of folds, scores, and simple linear gradients inspired in equal parts by the concept of Kirigami and Material. Folds which visibly protrude from the icon may cast simple shadows. Icons generally aim for a middle-level of detail seeking clean and bold designs, and while there are keyline shapes it is encouraged to break from them for more dynamic silhouettes.

System settings and devices. Still a long way to go in this department.

The icons set is based on the ever steadfast Breeze icon set, and the intention is to retain the monochrome icons from Breeze while injecting a new set of full-colour icons to compliment them. Currently Aether requires breeze be installed on the system, as it will request Breeze icons in the manifest. It also lacks the coverage we enjoy in Breeze, so it’s also good to have it filling the gaps in Aether. While I do intend to use the Breeze monochrome icons, in some instances monochrome will eventually be overridden with colour icons for things like places and mimetypes for consistency purposes.

Folders in a variety of colours.

The Aether icon set currently contains over 150 new colour icons at 64px in scalable vector format. Of these, the vast majority use entirely original art, with a handful taking matching assets from Breeze and undergoing modification to fit the Aether aesthetic. The icons are designed so they can render quickly on the web with no loss in quality, as the modern web demands high-quality low-impact imagery in extreme DPI situations. I believe this is the most important aspect of design pulled from Breeze.

Applications, including Libreoffice and Qt development suites.

The Aether icon has a strict set of guidelines, along with a keyline template and an entirely new colour palette. The specification of the icon set allows the 64px icons to scale to 32px and remain pixel-perfect, with some icons scaling down to as low as 16px remaining completely readable.  This is not the long-term plan, and smaller sizes are already receiving partial coverage.

Folders are the most complete icons in Aether, with 16, 22, 32, and 64+ size icons available.

You can get the aether icon set via a scratch repository here:
https://cgit.kde.org/scratch/kvermette/aether-icons.git/

Even though I haven’t added the license to the repository yet, these are being placed under the Creative Commons Attribution-Share Alike 3.0 Unported license at http://creativecommons.org/licenses/by-sa/3.0/.

The scratch repo contains some working files and resources for those interested in contributing, but currently I have not written down the specifications. By reading the Google Material icon guidelines you will be roughly halfway there, but there are enough subtle differences to trip anyone up. In the scratch repo there is also a set of resource files with working master files, inkscape palettes, and extras.

If there is contributor interest let me know and I will write down the guidelines along with examples. Until then, I’ll accept contributions directly and simply adjust them as necessary if I’m able to fit them into Aether; this is still a very informal side project.

This is a neat little trick that’s been making the rounds, and after seeing success with several people on Reddit I thought it was worth posting somewhere more visible. This will look at removing screen tearing (often entirely) when using Nvidia Proprietary graphics on the Plasma Desktop.

First, you should only do this if…

1. You are running Proprietary Nvidia drivers.
2. You are experiencing nasty screen tearing.
3. You are using a recent driver version.
4. You trust instructions from the internet.

The trick is enabling a feature called “Force Composition Pipeline”, or “Force Full Composition Pipeline”. What this does is essentially a driver-level vsync, but I haven’t found particularly good documentation on the feature. Most instructions you can find online will instruct you how to do this manually via config files, but I’ll explain how to do it via GUI as less can go wrong, and the GUI is there to be used. You can do a search online and easily find several manual sets of instructions if the GUI isn’t your thing.

1. Open your favourite launcher and go to Applications -> Settings -> Nvidia X Server Settings.
2. On the left side pane, select “X Server Display Configuration”. It’s second from the top.
3. Select a monitor.
4. Click “Advanced” to show all the options (if they are not already shown)
5. Check “Force Composition Pipeline”.
6. Return to step 3 if you have more than one monitor, until all the monitors are configured.
7. Click “Apply”.
8. If it hasn’t eaten a puppy, you’ll see the confirmation to keep the settings. If things have gone terribly wrong, wait half a minute and it will revert the changes.

If you still experience tearing, you may need to go and “Force Full Composition Pipeline”, which is a more extreme version of the feature.

As a follow-up, if the composition pipeline is on and working, the Nvidia driver is essentially providing its own flavour of vsync. You’ll likely want to turn off Kwins vsync otherwise you may experience stutter in several situations, where it essentially halfs your potential frame rate. This mostly applies to games, possibly video, and I only recommend this step if you see stutter too;

1. In your favourite launcher go to Applications -> Settings -> System Settings.
2. Select “Display and Monitor”.
3. On the left side pane, select “Compositor”.
4. Under “Tearing Prevention (‘vsync’)” select “Never”. You may wish to take note of the current setting if you need to revert it later, by default it’s “Automatic”.

Of course, there are some “gotchas” to keep in mind!

First; if you change your displays, rotate them, or anything else, you may experience tearing again, especially if you disabled Kwins Tearing Prevention. You’ll need to go back in and re-apply the settings.

Second; you may see a performance impact with games. I personally haven’t, but several articles on this subject do mention it as a drawback of this feature. Additionally it’s not quite something you can toggle on/off easily if getting your game on is impacted.

Third; on laptops with Nvidia PRIME, you may have difficulty enabling this feature. If you do, you may want to leave Kwin Tearing Prevention alone should it switch to Intel graphics and begin tearing. I’m not an expert on this and cannot test this with a PRIME-enabled machine, so your mileage may vary.

Lastly; these are instructions from someone who doesn’t know a huge amount about drivers and display servers. For all I know this heats up your GPU to 300 degrees and was meant to roast marshmallows. Proceed with caution.

Special thanks to “AbstractOperator” and “cristianadam” for letting me know this works on multiple monitors, and cristianadam for pointing out this youtube video; play this video (ideally full-screen) to test and spot tearing.