Install openSUSE Tumbleweed + KDE on MacBook 2015

It is pretty easy to install openSUSE Linux on a MacBook as operating system. However there are some pitfalls, which can cause trouble. The article gives some hints about a dual boot setup with OS X 10.10 and at time of writing current openSUSE Tumbleweed 20170104 (oS TW) on a MacBookPro from early 2015. A recent Linux kernel, like in TW, is advisable as it provides better hardware support.

The LiveCD can be downloaded from www.opensuse.org and written with ImageWriter GUI to a USB stick ~1GB. I’ve choose the Live KDE one and it run well on a first test. During boot after the first sound and display light switches on hold Option/alt key and wait for the disk selection icon. Put the USB key with Linux in a USB port and wait until the removable media icon appears and select it for boot. For me all went fine. The internal display, sound, touchpad and keyboard where detected and worked well. After that test. It was a good time to backup all data from the internal flash drive. I wrote a compressed disk image to a stick using the unix dd command. With that image and the live media I was able to recover, in case anything went wrong. It is not easy to satisfy OS X for it’s journaled HFS and the introduced logical volume layout, which comes with a separate repair partition directly after the main OS partition. That combination is pretty fragile, but should not be touched. The rescue partition can be booted with the command key + r pressed. External tools failed for me. So I booted into rescue mode and took the OS X diskutil or it’s Disk Utility GUI counter part. The tool allows to split the disk into several partitions. The EFI and the rescue ones are hidden in the GUI. The newly created additional partitions can be formatted to exfat and later be modified for the Linux installation. One additional HFS partition was created for sharing data between OS X and Linux with the comfortable Unix attributes. The well know exfat used by many bigger USB sticks, is a possible option as well, but needs the exfat-kmp kernel module installed, which is not by default installed due to Microsofts patent license policy for the file system. In order to write to HFS from Linux, any HFS partition must have switched off the journal feature. This can be done inside the OS X Disk Utility GUI, by selecting the data partition and holding the alt key and searching in the menu for the disable journaling entry. After rebooting into the Live media, I clicked on the Install icon on the desktop background and started openSUSE’s Yast tool. Depending on the available space, it might be a good idea to disable the btrfs filesystem snapshot feature, as it can eat up lots of disk space during each update. An other pitfall is the boot stage. Select there secure GrubEFI mode, as Grub needs special handling for the required EFI boot process. That’s it. Finish install and you should be able to reboot into Linux with the alt key.

My MacBook has unfortunedly a defect. It’s Boot Manager is very slow. Erasing and reinstalling OS X did not fix that issue. To circumvent it, I need to reset NVRAM by pressing alt+cmd+r+p at boot start for around 14 second, until the display gets dark, hold alt on the soon comming next boot sound, select the EFI TW disk in Apple Boot Manager and can then fluently go through the boot process. Without that extra step, the keyboard and mouse might not respond in Linux at all, except the power button. Hot reboot from Linux works fine. OS X does a cold reboot and needs the extra sequence.

KDE’s Plasma needs some configuration to run properly on a high resolution display. Otherwise additional monitors can be connected and easily configured with the kscreen SystemSettings module. Hibernate works fine. Currently the notebooks SD slot is ignored and the facetime camera has no ready oS packages. Battery run time can be extended by spartan power consumption (less brightness, less USB devices and pulseaudio -k, check with powertop), but is not too far from OS X anyway.

High DPI with FLTK

After switchig to a notebook with higher resolution monitor, I noticed, that the FLTK based ICC Examin application looked way too small. Having worked in the last months much with pixel independent resolutions in QML, it was a pain to see the non adapted FLTK GUI. I had the impression, that despite of several years of a very appreciated advancement of monitor technology, some parts of graphics stacks did not move and take advantage. So I became curious on how to solve high DPI support the hard way.

First of all a bit of introduction to my environment, which is openSUSE Linux and KDE-5 with KF5 5.5.3. Xorg use many times a hardcoded default of 96 dpi, which is very unfortune or just a bug? Anyway, KDE follows X11. So the desktop on the high resolution monitor looks initially as bad as any application. All windows, icons and text are way too small to be useable. In KDE’s system settings, I had to set Force Font with DPI and doubled its size from 96 to 192. In the kscreen module I had to set scale 2.0 and then increased the KDE task bars width. Out of the box useability is bad with so many inconsistent manual user intervention. In comparision with the as well tested Unity DE, I had to set a single display scaling factor to 2.0 and everything worked fine and instantly, icons, fonts and window sizes. It would be cool if DE’s and Xorg understand screen resolution. In the tested OS X 10.10 even different screen resolutions of multiple monitors are scaled correctly, so moving a window from a high DPI monitor screen to a traditional low resolution external monitor gives reasonable physical GUI rendering. Apples OS X provides that good behaviour initially, without manual user intervention. It would be interessting how GNOME behaves with regards to display scaling.

Back to FLTK. As FLTK appears to define itself as pixel based, DPI detecion or settings have no effect in FLTK. As a app developer I want to improve user experience and modified first ICC Examin to initially render physically reasonably. First I looked at the FL::screen_dpi() function. It is only a helper for detecting DPI values. FL::screen_dpi() has has in FLTK-1.3.3 hardcoded values of 96DPI under Linux. I noticed XRandR provides correct milimeter based screen dimensions. Together with the XRandR provided screen resolution, it is easy to calculate the DPI values. ICC Examin renderd much better with that XRandR based DPI’s instead of FLTK’s 96DPI. But ICC Examin looked slightly too big. The 192DPI set in KDE are lower than the XRandR detected 227 DPI of my notebooks monitor. KDE provides its forced DPI setting to applications by setting Xft.dpi in XResources. That way all Xft based applications should have the same basic font scaling. KDE and Mozilla apps do use Xft. So add parsing of a Xlib XResources solved that for ICC Examin. The remainder of programing was to programatically scale FLTK’s default font size from 14 pixels with: FL_NORMAL_SIZE = scale(14) . Some more widget sizes, the FtGl font sizes for OpenGL, drawing line widths and graphics scaling where needed. After all those changes, ICC Examin takes now advantage of high resolution rendering inside KDE. Testing under Windows and OS X must follow.

The way to program high DPI support into a FLTK application was basically the same as in QML. However Qt’s QML takes off more tasks by providing a relative font unit, much like CSS em sizes. For FLTK, I would like to see some relative based API’s, in addition to the pixel based API’s. That would be helpful to write more elegant code and integrate with FLTK’s GUI layout program fluid. Computer times point more and more toward W3C technology. FLTK would be helpful to follow.

Image Editing with 30-bit Monitors

Payable hardware for professionals is capable of 30-bit throughput since quite some years. And costs continue to go down. This means even budget setups are possible with this kind of gear. So lets follow the question why, who and how monitors capable of displaying 30-bit alias 10-bit per red, green and blue channel can be used. This blog article will first touch some basics, followed by technical aspects below.

Why is it useful to display graphics on a 30-bit monitor setup?
It is essential for graphical editing, to see what effect a editing step has. It is pretty common that low resolution monitors impose a barrier to reliably predict the intended output. This is true for geometrical resolution like for colour resolution and for gamut. The rule of thumb is, the graphics editor needs the most information available to do here/his job and spot artefacts and issues early in the process. This principle is deployed for print, web, film and video editing to reduce costs. You know, redoing something costs time and is part of the jobs calculation. More image information means as well more certainty to reach a graphical result. The typical artefact caused by low colour resolution is reduced tonal range. Colour conversions can reduce the tonal range further. So a sRGB image will look different on a 8-bit per channel monitor with a native gamma close to 2.2 compared to a pipeline with 10-bit per channel. The 8-bit output imposes a bottleneck resulting in loosing some tonal steps known as banding, which must not necessarily be present in the observed sRGB image. One very often read argument against higher bit depth is, that editing hardware shall be as close as possible to customers ones. But that is a illusion. The wide diversity of media and devices makes this nearly impossible. But simulation of end customer hardware is of course an issue and many graphics software has implemented simulation capabilities to address that concern.

Who is most interested in 30-bit colour editing on Linux?
Graphics professional and ambitious users closely observe Linux since many years and deploy it. Many block busters are produced and rendered on Linux machines. Web graphics is well supported since years and camera raw programs implemented a impressive level of features in the last years. So Linux is a potential content creation platform beside content consumption. The typical work flow for content creating people is to generate and edit their art work in high geometrical and colour resolution and down convert to lower resolutions as fits for the job, be that web, print, catalog previews and more flexible high quality delivery depending on actual contract. For instance many photographers archive their shootings in the cameras native format to preserve all available information for later editing or improved rendering. This is a important investment in the future for non short lived work, where old files can shine in new light. Motion picture productions are often rendered and color graded in floating point space by using the OpenEXR intermediate file format and output to 12 bits per component for playback in a cinema. Video production uses in parts raw workflows for advertisements. Medical-, scientific- and archival imaging are potentially interested too and require in parts 30-bit setups like in the DICOM standard. The benefit of 10-bit per channel versus 8-bit does not matter to everyone. Most consumers will not spot any difference while watching web video. But in more demanding areas it is a small but helpful improvement.

How to deploy 30-bit displays on Linux?
That feature was implemented by several companies starting on low level software components like X11, Cairo and pixman. However desktops where pretty slow to adapt software to the new needs and fix bugs. That was in part of the initially higher costs for the hardware. Only few developers in the open source community had early access to suitable gear. I do not write here about suitable graphic cards and monitor combinations. You should consult the web for this. Search for 30-bit monitor. Many early adopters observed psychedelic colours, not working graphics areas and more. Here the state on the well known KDE X11 desktop in release 4.11 on a openSUSE-13.1 . The login screen colours are broken. The splash screen after login looks correct and after some period the desktop becomes visible with again broken colours. To manually fix most of that, one have to tell that Qt shall use native colours. Create following text into a file called ~/.kde4/env/qtnative.sh .

$ kwrite ~/.kde4/env/qtnative.sh

#!/bin/sh
export QT_GRAPHICSSYSTEM=native

With the above variable the desktop should look reasonably in KWin, which is really great. Automating that in Qt would be appreciated.

However 30-bit monitors typical aim at high quality setups. Beside colour resolution they often enough offer a wider gamut than usual monitors. This results in partially heavily saturated colours, which burns in sensible eyes. Those people who do colour grading or photo editing are mostly affected, otherwise they can not easily play this work. So desktop colour correction is an other important feature to enable here. KWin supports ICC based colour correction through KolorManager, which would be useful for the colour saturation. But KWin disables all effects for 30-bit OpenGL visuals. The alternative Compiz-0.8 series has the CompIcc colour server plug-in, which provides the same ICC colour correction feature. To make use of it, one needs to install following packages: compizconfig-settings-manager, CompIcc-0.8.9. Unfortunedly the KDE decorator is no longer available. So use the Emerald decorator from X11:Compiz with the 30-bit-shadow.patch in order to avoid artefacts in the shadow code. Compiz can be used as a default window manager application. Use the system settings to switch to Compiz. Use ccsm to switch on Color Management if not done automatically. And voila the 30-bit desktop should be ready to explore.

What works and what not?
The Plasma desktop is fine including all menus. Dolphin, KWrite, and other applications work. Thunderbird shows some artefacts due to not properly supporting the R10G10B10A2 pixel format. The same is true for Firefox, which lets in parts shine through content behind the Firefox window. Gwenview and ShowFoto work fine within their 8-bit drawing. Only the preview is broken in ShowFoto. Krita supports with the OpenGL backend even native 10-bit per colour component. Menus in Sketch are black. Krita shows minimal artefacts through twice colour converting from image to sRGB by Krita and from sRGB to the monitor colour space by CompIcc. But this effect is much lesser visible than the improvements through its 30-bit support. Applications which try to code 24-bit colour themselves are broken like Konqueror. Gtk and hence Gnome applications with graphical areas do not work. They show black areas. VLC works fine. So daily work should be fine in with 30-bit in the KDE application family depending what you do, with some minor glitches. Valuable Gtk applications as is like Inkscape and most Gtk applications are unusable in a 30-bit setup, with Gimps drawing area being a exception. Thunderbird/Firefox are guessedly affected by the same Gtk bug for which a patch was created some time ago. A patched libgtk-2 is available for testing on openSUSE, which appears to have fixed the problem almost for me.

Beside the need to exchange a windowmanager, to patch a few components and do some manual settings, Linux appears almost there in support of 30-bit setups. Polishing of that feature needs testing of patches and finally acceptance for distribution. Your feedback about bugs, tests and patches can make a difference to developers.

Wayland/Weston on oS-12.3

After Richards recent patch about adding a colour management system to wayland, I was interested to build a Oyranos CMS connection module for wayland. The patch is in a initial stage, but might get to a similar level like what is already in CompICC and KWin colour servers.

First I substituted all openSUSE-12.3 distro packages with the adequate packages from tobijk and obtained a version 1.0.6 . Keeping the distro Mesa package resulted in a missed EGL Wayland extension and some crashes. On the Wayland website are some instructions on how to setup the environment. Especially the XDG_RUNTIME_DIR variable needs attention. I skipped the part of adding a special weston-lauch group and run the application simply by root. However the a symbol in cairo was missed “cairo_egl_device_create”. After cloning and building pixman and cairo following the Wayland instructions everything went fine. Here a simple ~/.config/weston.ini file to start with:
[wayland-desktop-shell]
locking=true

[launcher]
icon=/usr/share/icons/oxygen/32×32/apps/utilities-terminal.png
path=/usr/bin/weston-terminal

Weston launches on my system into a multi monitor setup with nouveau. There is still heave tearing, while moving the terminal. After Strg+Alt+Entf (Ctrl+Alt+Del) weston quits.

Linux Color Management Hackfest Brno 2012 ended

Around a dozen people met inside the Red Hat offices in Brno last weekend. The attendees came from various distributions and projects to discuss and work on color management for Linux. Most people arrived at Thursday and we started immediately to brain storm ideas and share information.

I was quite shocked as I heard Dantii could not join us. Fortunately the last messages about him sound very encouraging. It is great that our community could in different ways help him and his family.

The basic concept we worked with during the hackfest, was the opt-out of colour management approach. That was visible in printing and in window manager colour management.

Printing people discussed the PDF/X OutputIntent. The concept was developed to overcome the current short commings in the cupsICCprofile, which is primarily a vendor solution for CUPS print servers and the colord user session hook inside CUPS server. The implementation of the concept was done inside libCmpx, which is basically a wrapper around Ghostscript, which does the majority of the work, and a interface to Oyranos. From the other side John Layt looked into that work and Krita new print colour management tab to understand the implications for the KDE/Qt print dialog. He discussed lively with Till Kamppeter, Richard Hughes, Chris Murphy and me on how to get forward with that. Richard wrote a proof of concept for on screen print simulation in GTK. Chris talked a lot about osX printing and did some testing there. His experience on other platforms than Linux helped us a lot to figure out, which path we want to go and way the make sense. I searched for some PDF’s showing the features we need. They can now be found on ColourWiki. Jaroslav Reznik printed them and Till tested them. Michael Vrhel from the Ghostscript project fixed already after the event all of the bugs, which Till worked on in Brno. We had the idea, that some PDF printers might be able to do the right thing with the OutputIntent themselves. While discussing on how to know about that capability, Till and Richard had a nice idea how to reduce code duplication inside the current set of Linux CUPS filters. In parts the Color Management Hackfest crossed over into a Printing Summit.

Jan Grulich started coding on KolorManager. He implemented a widget to show a 2D graph of a ICC profile inside the information tab. Sirko Kemter was not very happy about the colours inside the graph. So I adjusted them, but after the hackfest.

While working on that, Jan profiled his monitor using Dantii’s colord-kde. Yes, Lukáš Tinkl fixed it, so it can now create ICC profiles. We needed to hand massage the profile to get it into Taxi DB, and then thought, it would be good to download the fresh profile later through Oyranos. That worked fine on the command line. But inside KolorManager a selection that a profile is available for download from Taxi DB would be more appealing. Jan wanted to look into that, and I worked later on a API and code snippet for Oyranos.

By the way, the above screen shot is done using the new colour correction feature for KDE-4.10. You might see the strong colour cast in it. Dan Vrátil worked on undoing that cast inside KSnapshot using the actual monitor profile. The initial coding was fast. But he likes to get that working for multiple outputs too.

Casian Andrei, who did the KWin Color Correction project during this years GSoC, wrote some documentation about that newly added feature. While writing that and clarifying some points, we discussed the opt-out inside KWin and found that it is not yet present. Sig. But Casian had played with the idea already and said that per region opt-out would be trivial inside KWin and started to write on that feature during Sunday. In case that works out, it would be trivial to opt out inside existing applications. But we found as well, that for a perfect results only a blending in the correct colour space is needed during compositing. That can be implemented inside toolkits, which is not trivial, and can then be used together with the per window opt-out. That buys us some valuable time for the toolkits to become ready for full colour management support. Whether the same per region approach is easy enough to implement in Wayland needs to be seen.

Now back to profile distribution. Oyranos obtained a new backup tool for Taxi DB. And we counted already over 200 different ICC profiles in the online data base. Sirko Kemter and Daniel Jahre grabbed the taxi sources, installed MongoDB and worked on mostly basic stuff to add later more features. The online front end to the DB can be used on every platform for download and upload. Daniel and Sirko discussed how to temporarily store a ICC profile from the ColorHug LiveCD. We found that the data base can be used for very different things, e.g. distribution of spectral data sets for camera sensors.

Pippin worked since some time on improving the display of gradients on 8-bit driven monitors. He came up with a dithering approach and tested that using the Taxi DB profiles for the analysis of his implementation. That helped him to make the algorithm more robust even with strongly distorted monitor gamma curves. There is quite some interest inside the graphics designers community for his work to solve banding problems. We talked a bit about gegl and I found babl especially interesting. The small library does, what I call pixel layout conversions. Those are in part colour space conversions and encoding conversions. For better separating encoding, 8-bit versus 16-bit etc., from colour spaces, e.g. linear gamma + Rec709 primaries versus sRGB etc., we need better ICC profile analysis. Especially gamma analysis can be improved inside rendering pipelines. Beside discussing hardware stuff, spectral imaging, video processing and so on, he gave a small and very helpful introduction into colour theory, which was a eye opener for many of the colour management newcomers and thus very welcome.

We had a interesting discussion about financial implications of colour measurement hardware. My impression is the high costs and thus reduced availability for good colour measurement gear nags on the success and acceptance of ICC colour management in consumer and professional markets.

During the hackfest it was really a pleasure to have so many experts in the field in one room and work together in a highly productive atmosphere. Some of them I met the first time. So let me thank our sponsors Google, Red Hat and KDE for their generous support of the hackfest idea.

We all worked quite a lot and found such a event should not stay single. So we agreed already to arrange a one day track and one following day at LGM in Madrid / Spain 2013 under the OpenICC umbrella. I hope we will see then even more projects coming.

Colour Management Talk @ LinuxTag 2012

Logo LinuxTagEuropes biggest event arround Linux and Open Source – LinuxTag, is’nt far away anymore and Oyranos will participate on it. LinuxTag take its place in Berlin from 23.-26. May on the exhibition area arround the Funkturm. On saturday the 26th of May I will present together with Sirko an talk about colour management – “Bring Color To The Game“. The talk will not introduce Oyranos as CMS, it will more explain what color management is and about the actual status on free desktops. We want as well to talk about what a user needs to get colour management running. During LinuxTag I will be reachable on the openSUSE booth for questions and introduction into profiling and bring some colorimeters.

Colour Management GSoC projects

Google Summer of Code

There is already much written about Google Summer of Code. I just want to point you to a bunch of cool colour management (CM) project ideas.

OpenICC lists some ideas, which are interesting for cross desktop CM, especially for start in bringing CM to toolkits. Interested students are basically free to select one toolkit, which fits them most.

The CMM’s for Oyranos idea shall ease access to the upcoming spectral imaging capabilities inside the ICC architecture and to use smart CMM’s like ArgyllCMS was demoed doing stand alone and within ColorSync. Smart CMMs allow to optimise colour conversions for a images and devices, which will show up in more lively photographs.

The OpenGTL/OpenCL meta backend for the Oyranos CMM framework will enable us to write CMM’s, which run on the GPU instead of the CPU. That would potentially bring a big speed improvement for deploying applications through a simple CMS API.

One student proposed to work on characterisation based ICC colour correction inside KWin, which will fly over any of the old style per single channel gamma calibration. If you like to get ride of each monitor showing you a different saturated red, green or blue desktop background, then go ahead and propose a similar project for one of your favorite compositing window managers to the openSUSE or OpenICC orgs.

And of course there are printing related CM project ideas. One for CM printing with Krita and one project for general CM print queue setup in KolorManager.

CLT 2012 Impressions

Chemnitzer Linux-Tage was this year again a great event. The mainly german speaking visitors enjoyed a well organised fair of mixed open source community and business booths, talks and workshops.

On the Oyranos project booth discussed old friends various colour management topics and concepts. We felt that colour management terms and concepts inside the open source community are behind the awareness of other comparable graphic techniques like for instance font rendering. The more I find it amazing, that there is a core of users, which try hard to understand ICC techniques.

One topic with neighboring openSUSE people was of course the strong rose awareness around colour management during the recent discussions on the KDE core-devel list. What I found encouraging is, many people inside the KDE community see it important to collaborate. And so I think we in the OpenICC community should accelerate on our formal recommendation efforts for sharing colour data and configurations. An other related point was made, that it would be not helpful to stall projects in a too long wait for constructive discussions to come to live. I tried this sometimes and see now that balance between discussion and start for actual work could be improved. Good to get so many feedback about OpenICC core stuff in great face to face discussions.

With openSUSE’es Tom I discussed his improvements on the new open build service (OBS) search page layout, which is a great ongoing work. But much to my surprise he could point me to a nice and long wanted OBS feature, which I now integrated into the Oyranos download pages. That is, OBS provides embeddable download instructions for each distribution package of a project. These easy instructions show end users, how to install the desired software including all dependencies from OBS. Thanks for this valuable hint, which makes our colour management packages in OBS much more accessible to our users.

Looking around I found the mageia distribution interesting and would find it great to see this distribution integrated into OBS once a successful version 2 comes out this spring. But of course there are other interesting distributions out there to integrate into OBS. One advantage of OBS for me as a maintainer is as well, that I can test my packages prior to release in one go.

On the FFmpeg booth we discussed the idea that 3D lookup textures are a very simple way of exchanging colour transforms. I will surely look deeper into this and want to find a useful format to exchange 3D shader data for OpenGL textures. In CompICC a 16-bit PPM image helped for debugging. Lets see if we can find a more common and useful format to reuse.

CompICC-0.8.5 released

A new version of the compiz plugin for ICC colour correction of monitors is released. This release is a feature release.

Changes Overview:

  • new support per region ICC profiles
  • new switch to X Color Management specification
  • require libXcm-0.5.0 and Oyranos-0.4.0

Changes from 0.8.4:

  • fix alpha blending
  • speed up load time (cache the transformed pixels in memory)

About:
The project brings you instant desktop colour correction on GPU through the compiz window manager (0.7.x/0.8.x). It supports multi monitors and live connecting. The implicite colour conversion appears on the fly. To opt out of colour correction for specialised graphics applications the X Color Management spec 0.4 is supported. Devices can be configured through the Oyranos Colour Management System.

ChangeLog:
http://compicc.git.sourceforge.net/git/gitweb.cgi?p=compicc/compicc;a=shortlog;h=refs/tags/0.8.5

git git://compicc.git.sourceforge.net/gitroot/compicc/compicc
git sha1: c963bdbc7aa4bf9703f3c87f82734d1223ff7d63
package: http://downloads.sourceforge.net/project/compicc/Compicc/compicc-0.8.5.tar.bz2
size: 76548 Byte
sha1sum: 902f2ea6b9c0aabe91297f6b80dd1f5ef9f910d1 compicc-0.8.5.tar.bz2
md5sum: 41a1a08c82ee18025d535c3dbc86aaf8 compicc-0.8.5.tar.bz2
Linux RPM: http://download.opensuse.org/repositories/multimedia:/color_management/

LGM Vienna 2-5 May 2012

The Libre Graphics Meeting is the annual event for open source creative graphics software. It greatly helps in improving the open source software stack through lots of talks, discussions, round tables, work shops and wonderful face to face meetings. There is always a great mixture of developers, artists, writers, translaters and interested people present, who come together in a very friendly and inclusive atmosphere. We had in the past always a OpenICC round table, when I was at LGM, and discussed various topics and planed around colour management. That should happen this year again with many ideas coming up.

To get people from all over the world to Europe, we need your help:

review!

Sirko has created another pledgie: