Posts

OLED brightness in Linux

Recently I've got a new laptop with OLED panel only to find out that brightness control for OLED panels is not yet supported in Linux. Archlinux wiki page mentions using gamma ramp for controlling perceived brightness using hackish userspace tools (icc-brightness), so my first thought was to implement a hack for i915 driver to expose backlight interface that actually adjusts gamma ramp. So I went to #dri-devel to ask around whether this idea sounds too crazy and it turned out that there are better ways than using gamma ramp. Basically if you use gamma ramp you essentially reduce dynamic range, i.e. if you have 8 bits per pixel at 50% brightness you would get 7 bit, at 25% - 6 bit and that will result in banding artefacts at low brightness levels. To overcome that issue OLED panels actually have an interface to control brightness. There are at least 2 competing "standards" - VESA and Intel proprietary. First one is already supported by i915 driver while latter is not. Unfo

Hacking u-boot for Pinebook. Part #1 - using FEL

It's been a while since I posted to my blog. A lot of things happened since then, I guess the most important is -- I moved to Canada. I've been living in Vancouver (OK, Greater Vancouver) with my wife and cat for more than 2 years now. But enough about me, let's get back to the topic. Recently I've got a Pinebook , mostly for hacking purposes. It's pretty nice device - quad-core Allwinner A64 CPU, 2GB LPDDR3 RAM, eMMC storage, etc, etc. See pine64.org for full specs. But unfortunately it comes with BSP kernel from Allwinner which is pretty ancient - 3.10 (released in 2013, more than 4 years ago!) Hopefully, mainline support for A64 is in pretty decent shape, see  http://linux-sunxi.org/Linux_mainlining_effort . Sure some things are missing - LCD, sound, power management, and that's not all. But it's good - there's something to hack on, right? So I decided to start with u-boot. Hopefully, Allwinner SoCs support boot over USB - it's called FEL,

Access point with Raspberry Pi and rtl8192cu dongle

On Thursday ethernet ports (WAN and LAN1-4) in my Asus WL500GPv1 router have completely died, so I needed a replacement. Hopefully, recently I've got Raspberry Pi, so I decided to use it as a router. I've got TP-LINK TL-WN821NC USB stick from local store which is based on RTL8192CU chipset. Unfortunately, its driver doesn't work with vanilla hostapd, but requires patched ancient version of hostapd from Realtek . I'm using Archlinux on my rpi and I've found manual how to setup AP using this USB stick  here , but I don't want to overwrite binaries from repository packages, since it's not a sane way, and it can (and will) be broken by hostapd update. So I prepared a package, here's source package (just unpack it and build with makepkg directly on rpi), and here's binary package for armv6h (you can install it with pacman -U). I can't put PKGBUILD in AUR, since there's no stable hosting for Realtek's hostapd. If anyone is willing to host

Wayland and software rendering

Image
Recently I spent few evenings for hacking wayland . I like idea of wayland - rendering is done completely on client (in whatever way), compositor (server part) is responsible in rendering buffers from clients on the screen. Issue for me was rendering part of weston (reference compositor for wayland) - it uses GLES for compositing, but I want to try wayland and weston on devices without hw acceleration (pure software rendering), and running software GL on PXA270@312MHz does not sound like a good idea, does it? :) So I asked on #wayland@irc.freenode.org if it possible to implement software renderer, Kristian Høgsberg (khr) responded that in master branch of weston repo there's a nice abstraction of renderer, so it's possible to implement pixman renderer. So I did :) weston with x11-backend and pixman renderer khr and pq from #wayland were very helpful, and described place of renderer in wayland architecture, here're some points renderer just performs rendering of

Hacking on fingerprinting again or AES2550/AES2810 driver for libfprint

Image
Back in 2007 I participated in driver development for AuthenTec AES2501 scanner, driver was later merged into libfprint project. I didn't hack much on libfprint, just sent few bugfixes, but recently AuthenTec announced that they're willing to send fingerprint scanners for opensource enthusiasts who wants to develop driver for those scanners. So far, so good... I've wrote a letter to AuthenTec and they proposed to send AES2550 or AES2810 scanner to me. I chose AES2550. Actually, AES2550 and AES2810 are pretty same (AES2550 driver should work with AES2810), the only difference is missing crypto engine on AES2550 (who needs cryptography anyway? :)) So, I've got parcel with scanner in August, but unfortunately had no spare time for hacking, I only coded driver stub and read datasheet from AuthenTec. So, in September/October I've spent few (5-6?) nights hacking on this driver, and finally got it working on my AES2550. Image quality is much better then on my AE

Reboot instead of shutdown issue

Recently hit subj issue on 2 PCs, on 2 different distros: ubuntu 12.04 on my sister's nettop current archlinux on my mother's-in-law PC Here're symptoms: PC shutdowns on poweroff command and then immediately turns on. Sounds weird, right? It turned out that cause is forcedeth driver (both PCs are based on nVidia chipset). I suspect it's somehow related to WoL implementation (however there's not WoL packets in my network for sure - local segment contains only router + 1-2 PCs). Solution is to 'rmmod forcedeth' somewhere on shutdown path. Can't investigate this issue more broadly, I've no permanent access to those PCs :) But some forcedeth dev is guilty for sure

fheroes2 on zipit

Image
Just got fheroes2 running on z2. Rays of hate to the author for "-I$(PREFIX)/include" in Makefile. PREFIX is usually /usr, so it pulled headers from host and produced weird compile errors. It took half a day to debug and fix it. You'll need data and maps from original heroes 2 in /root/.fheroes2 to play. As usual, here's screenshot: Btw, I've moved to gcc-4.6, so don't forget to get updated openwrt .config Binaries are here: uImage rootfs