Update

source/_posts/2015-02-18-upgrading-to-freebsd-10-1-release.markdown

@@ -6,11 +6,16 @@ comments: true
 categories: 
 ---
 
+I endeavoured to upgrade my old FreeBSD 9.3-RELEASE system to brand
+new 10.1. As expected, this was a quite bumpy process, and below are
+a few things I had to find out the hard way.
+
 Ports
 =====
 
 Neither `pkg update` nor `portupgrade` can update all ports.
-Dump all origins, then reinstall manually.
+I had to dump all origins, remove all ports, then reinstall
+everything manually.
 
 Linuxulator
 ===========
@@ -23,25 +28,98 @@ compat.linux.osrelease=2.6.18
 X11
 ===
 
+New Xorg
+--------
+
+As of Apr. 16, 2014, the X server has been upgraded to a new
+release. From https://wiki.freebsd.org/Graphics/WITH_NEW_XORG:
+
+```plain linenos:false
+Note that there's a know regression with syscons and kernel video
+drivers: you can't switch back to a console once an X.Org session is
+started. A new console driver called vt(4) fixes this issue while
+bringing nice features. It's available in FreeBSD 9.3-RELEASE and
+10.1-RELEASE but isn't enabled by default. To enable it, put the
+following line in your /boot/loader.conf:
+    kern.vty=vt
+```
+
+It is a real shame that users essentially have no choice but
+switching from the default syscons to the "new" (unfinished,
+far from functionally complete) vt console driver.
+
+DRI
+---
+
+Both GDM and the GNOME desktop now require DRI access. At least
+for ATI video cards, this means that user `gdm`, as well as anyone
+logging in to a GNOME session, must have access to `/dev/dri/card0`:
+
+``` plain /etc/devfs.rules linenos:false
+add path 'dri/card0 mode 0666
+```
+
 GDM
 ---
 
 Gdm won't work out of the box (black screen):
-
+`gdm_lang` cannot be set to a non-UTF-8 locale anymore
-  * `gdm_lang` cannot be set to a non-UTF-8 locale anymore
 (if the month name in the current date contains an accent,
-    the greeter will abort).
+the greeter will abort). Time to bite the UTF-8 bullet, then.
-  * (at least when using an ATI video card,) user `gdm` needs to be
+
-    able to access `/dev/dri/card0`:
+Oh, and I can't just remove the variable altogether, see below.
-    * create group `dri` containing user `gdm`
-    * add devs rules to give it r/w access to `/dev/dri/card0`
 
 Keymap
 ------
 
-X will now ignore keymap settings from xorg.conf. Keymap settings must
+Interesting issue for GNOME users. I found out that the GDM login screen
-now be supplied through HAL policy (`/usr/local/share/hal/fdi/policy/99local/10-x11-keymap.fdi`).
+would always revert to US layout, no matter what. Initially I thought
+the X server had an incorrect keymap due to HAL device enumeration,
+so I added the following to my setup:
+
+```xml /usr/local/share/hal/fdi/policy/99local/10-x11-keymap.fdi
+<?xml version="1.0" encoding="ISO-8859-1"?>
+
+<deviceinfo version="0.2">
+  <device>
+    <match key="info.capabilities" contains="input.keyboard">
+      <merge key="input.x11_options.XkbLayout" type="string">fr</merge>
+      <merge key="input.x11_options.XkbOptions" type="string">terminate:ctrl_alt_bksp,compose:rctrl</merge>
+      <merge key="input.xkb.layout" type="string">fr</merge>
+      <merge key="input.xkb.options" type="string">terminate:ctrl_alt_bksp,compose:rctrl</merge>
+    </match>
+  </device>
+</deviceinfo>
+
+<!-- Legacy X11 options:
+	Option	"XkbRules"	"xorg"
+	Option	"XkbModel"	"pc105"
+	Option	"XkbLayout"	"fr"
+	Option	"XkbOptions"	"terminate:ctrl_alt_bksp" 
+	Option	"XkbOptions"	"compose:rctrl" 
+  -->
+```
+
+However this happened to be a total red herring, as by default the
+port configures Xorg to use devd, not HAL.
 
-http://www.ping.de/sites/kite/xorg-hal-migration.html
+It appears that the X server setup is actually just fine. And indeed,
+starting it with startx yields the expected French layout.
 
+However, it appears that gnome-shell considers that whatever keymap
+is configured in the X server probably must be unsuitable, and
+changes it on its own to a better default based on the current locale
+(or "us" if no locale is set for gdm).
+
+Printing
+========
+
+I am using an HP MFP1217nfw network printer, which requires the proprietary
+`print/hplip` and `print/hplip-plugin` packages. These install `print/cups` as
+a dependency. `print/cups-filters` is not installed as a dependency, but
+is required anyway, or all print operations will fail with:
+
+```
+D [02/Mar/2015:22:24:01 +0100] Print-Job client-error-document-format-not-supported: Unsupported format "application/pdf".
+```