Wow, Lollypop is an excellent GTK+ music player. Album-oriented, just like I prefer. iTunes-inspired in some design elements. Nice. I just wish it was an MPD client.

Discovery of the day: Blender has an SDL2 backend, just build it with -DWITH_GHOST_SDL=ON. If you also have GLEW built for Wayland…

Blender will run on Wayland!

Well, "run" — the window is glitchy as hell. The best thing though is that these glitches showed Dungeon Crawl Stone Soup tiles to me (since I launched DCSS before to test SDL — for some reason I had to downgrade to 2.0.7 to run most apps on Wayland.)

It is well known that Enlightenment/EFL is pretty awful. But I had to build it on my FreeBSD box since I'm testing a LuaJIT update and EFL does include LuaJIT support. So while I'm at it, I decided to add Wayland support to the port.

So at least it works, but its behavior is indeed kinda funny. Running their terminal with GL acceleration (ELM_DISPLAY=wl ELM_ACCEL=opengl terminology) actually does work. Running it without acceleration (ELM_DISPLAY=wl ELM_ACCEL=no terminology) results in the surface not showing up and… this message:

DRM_IOCTL_I915_GEM_APERTURE failed: Invalid argument
Assuming 131072kB available aperture size.
May lead to reduced performance or incorrect rendering.
get chip id failed: -1 [2]
param: 4, val: 0

It's no "SPANK! SPANK! SPANK!" but how exactly did it decide to use an Intel GPU related system call? On my machine that has a Radeon card?!?! When I asked for software rendering??

Camera Canon EOS 600D Lens EF-S18-55mm f/3.5-5.6 IS II Photo parameters 1/200 ƒ/6.3 ISO 200 Software GIMP 2.8.22

I bricked my mainboard… and recovered it using a Raspberry Pi!

So yeah, this is an MSI X370 SLI PLUS. A new firmware update came out, so I unpacked it onto a USB stick and started the upgrade process. With an overclocking profile that sometimes takes a few tries to boot (memory training) and with the stick inserted into a front panel USB port.

The process almost completed (or maybe completed?), the board tried to reboot… and it didn't boot. As in, power comes on, the CPU and RAM debug LEDs turn on and off, then nothing. Clearing CMOS didn't help.

So I looked at this MSI forum thread that contains the pinout and people arguing whether 3.3V is safe for a 1.8V EEPROM chip. I took a 5V-3.3V level shifter (the only one I had), plugging 3.3V into the "5V" side got me down to 2.9V.

And then I tried to connect to the tiny pins of the SPI header (thanks MSI for providing one!) using my large wires. This was rather painful. Couldn't connect ground at all (because that was 3 pins next to each other, it didn't fit). But without GND or VCC, flashrom actually detected an unknown chip! With some random experimentation I found that setting a low speed (1024) and plugging in only VCC totally works! Writing this from the recovered computer :)

LOL. MEGA says "use Chrome to download large files because Firefox has a small buffer". Opened in Chromium… "unzoom or use Firefox because of a zoom rendering bug in Chrome/ium" :D

haha, Phoronix wrote about the stuff I posted on wayland-devel@. So yeah, I'm working on Rust bindings for libweston that would eventually allow me to write the best Wayland compositor ever :)

And fractional HiDPI scaling was pretty easy to add. Wayland apps look awesome. However, X11 apps are blurry now, and bypassing the scaling for Xwayland is not as easy… So I made some changes to my Ports fork to enable Wayland support in more apps. Turns out a lot of complex applications run fine — LibreOffice (!), Inkscape, MyPaint, RawTherapee, Darktable.

The Firefox Wayland support though… is not usable yet :( It looks awesome but EGL isn't working and, even worse, the screen doesn't refresh when it needs to — so you're typing and letters don't appear until you scroll or some time passes. Hopefully this will be fixed soon.

So there's no support in pretty much all Wayland compositors for fancy keyboard mapping utilities like xcape because no one wants a keylogging protocol extension. (Even an access-controlled one!! Why.)

Turns out it's better to just solve this on the evdev level. And I've done it in the coolest way possible: with a tiny sandboxed scripting environment. Meet evscript! It runs Dyon scripts in an environment with evdev, uinput, stdout and nothing else. xcape functionality is already provided in the "standard library" :)

Adventures in printing:

The proprietary blob plugin for HPLIP is ported to FreeBSD by literally saying "this Linux library is actually for FreeBSD" and adding a tiny implementation of a couple glibc functions, amazing! But HPLIP is not necessary for my printer, foo2zjs is an open source driver that supports it.

PostScript is not PostScript, apparently. (Actually my printer wants PDF, it seems — setting generic PDF on the client side when network printing over CUPS worked.)

And if CUPS doesn't see the printer when using the open source drivers, it IS a permissions issue, make sure to restart devd to activate the rule that's included with the cups package. (The fact that HPLIP sees the printer is… odd. Was it running HPLIP stuff as root?)