Plugable

Emacs macro to ease the pain of checkpatchitis

Posted on 19. Feb, 2010 by Bernie Thompson in udlfb

In order to submit patches to the Linux kernel — as I’ve been doing lately to help improve Linux’s DisplayLink driver udlfb — the changed code has to pass a script called checkpatch.pl, which flags violations of the Linux kernel style guidelines.

Style wars (e.g. “tabs vs. spaces”) are a never-ending source of tension on projects, so I actually appreciate automation like checkpatch.pl to just lay down the law, and be done with it.

But .. having to sift through endless warnings when you run checkpatch.pl late in the development process is frustrating. And there’s no way most occasional kernel patchers will remember all the rules (especially if you strongly disagree with some of them — which I do). It’s much better if your editor can just warn you when you step off the golden path of enlightenment. I use emacs, so I looked around for solutions, but they were only incomplete, or not real-time (e.g. checkpatch.pl has an –emacs option to run in the compile window of emacs).

So here’s something a little less incomplete that I’ve added to my .emacs file to catch the majority of checkpatch.pl errors in real-time (by highlighting the offending code in red). Works only on recent emacs versions. Hopefully it’ll be useful to others pounding away on their patches.

;; *** BEGIN highlight checkpatch.pl warnings and errors ***
(add-hook 'c-mode-common-hook
    (lambda ()
      ;; this sets defaults to match many checkpatch.pl guidelines
      (c-set-style "linux")))
;; but doesn't warn us about violations these regexp catch common ones
(custom-set-faces
    '(my-warning-face ((((class color)) (:background "red"))) t))
(add-hook 'font-lock-mode-hook
    (function
        (lambda ()
            (setq font-lock-keywords
                (append font-lock-keywords
		    '(("^.\\{81\\}" (0 'my-warning-face t)))
                    '(("\\/\\/.*" (0 'my-warning-face t)))
                    '((";[_A-Za-z0-9]+" (0 'my-warning-face t)))
                    '((",[_A-Za-z0-9]+" (0 'my-warning-face t)))
                    '(("return[[:blank:]]*(.+);" (0 'my-warning-face t)))
                    '(("([_A-Za-z0-9]+[\\*]+)" (0 'my-warning-face t)))
                    '(("[[:blank:]]+\\)"(0 'my-warning-face t)))
		    '(("^[[:blank:]]+{[[:blank:]]*$" (0 'my-warning-face t)))
		    '(("[_A-Za-z0-9]+\\*[[:blank:]]" (0 'my-warning-face t)))
		)))))
;; exercise to reader - move regexps into c hook
;; *** END highlight checkpatch.pl warnings and errors ***

Any enhancements or corrections are welcome.

Preparing more udlfb patches for linux-next

Posted on 12. Feb, 2010 by Bernie Thompson in udlfb

There are limits on how much a small device company can and should do in contributing to open source driver support. But with a historical connection to DisplayLink and more products coming with the technology included, contributing what we can to the generic DisplayLink driver on Linux makes some sense.

Also note this driver is just a foundation on which other stuff (like X) sits, so it doesn’t mean Linux is easy for real end users yet. But it’s getting closer.

Here’s the announce that went to the list today:

The next patch series for udlfb is “nearly ready” for submission, hopefully will be coming in the next few days.

* The defio rendering problems (e.g. with xf86-video-fbdev X server) are still unsolved
* Still 16bpp only. Pseudo-truecolor 32->16 is on the wishlist.
* No DL 1×5 SKU detection yet (you’ll get a blank screen if your monitor’s res exceeds the adapter)

Linux kernel framebuffer rendering APIs

Posted on 30. Jan, 2010 by Bernie Thompson in udlfb

The Linux framebuffer interface has at least four different sets of APIs for rendering to the screen. Here they are mapped against the some important fbdev client “applications”.

A “no” in the above table means the client application will fail if that’s the only API option supported by the kernel framebuffer driver.

udlfb supports all four, with some limitations (e.g. defio is required to support mmap without damage reports).

The custom displaylink X server is the only client today which supports the last option, which is the most performant option on indirect displays (like USB displays) – and hopefully will become a standard interface as it’s useful in many cases.

Unfortunately for the DisplayLink udlfb framebuffer, each API has different constraints it places on the driver. Those constraints aren’t easily met all at once for a driver rendering to USB. AFAICT, it looks like the driver actually needs to figure out what kind of client it’s dealing with, and assume that client will stick to that sub-set of the API. That seems to be a safe assumption for the major fbdev apps today, but betting on something like this is always ugly.

Any misconceptions?