[Openslate-brainstorms] FreeBSD on tablets

[OpenSlate C. <ope...@gm...>]

Back in 2012 there was a valuable thread on the main FreeBSD mailing list
concerning FreeBSD on tablets. What makes modern tablets different from
conventional laptops are 1) multi-touch finger activated digitizer (think
low resolution), and 2) other-than-Intel CPU, mostly ARM. The tablet in
question was an ExoPC, which does use an Intel CPU.

This morning I checked with the developer, and based on his response I have
to say that FreeBSD is still not ready for projects like ours. All it would
take is some talented programmers and a bit of cash to pay them. Thinking
about making that a goal for us. The task would be far easier if we had an
open-source hardware design, as all of the problems described below are due
to poor hardware implementations that just magage to work on Windows.

Here is his report. My questions are preceded by ">":

> The thread you started last year popped up again on the mailing list. I
was
> wondering how that project is doing.

It's not a project really. I'm just trying to make the thing work for
personal
use.

> How is battery life?

It lasts about 2 hours. Not great, but then FreeBSD isn't very power
frugal. I
do have powerd running on it.

["power d" - the FreeBSD power management system, primarily for CPY clock
throttling -- gd]

> Are ACPI modes working, esp does it come out of sleep mode ok?

It doesn't come out of sleep mode properly, so I never put it to sleep. But
I've *never* had that work right with FreeBSD on *any* laptop I've ever
owned.

> What window manager are you using?

KDE4

> Are there instructions somewhere on how to do this?

Most of the important files I have for it are at:

http://people.freebsd.org/~wpaul/exopc

But most of this is in my head. Most people don't run FreeBSD on this thing.
Mine came with MeeGo.

Things that need to be tweaked:

graphics support
----------------
There's a bug in the xf86-video-intel video driver related to the Pineview
graphics in the ExoPC Slate. The i830_disable_fb_compression_
8xx() function
attempts to check a status bit which never clears. As a result, when this
function is called during the X server start-up, it stalls forever with a
black screen. (The machine is still running, but you can't see anything.) I
modified the code to only test the status bit a fixed number of times before
giving up. The patch is i830_display.c.diff. With this fix, I can get
accelerated graphics working properly. You can apply this patch to
/usr/ports/x11-drivers/xf86-video-intel and rebuild the driver to fix this.

bluetooth
---------
You need to load the ath3k-2.fw firmware file to get the built-in Atheros
bluetooth interface to work correctly. This is a little unusual in that most
devices seem to need ath3k-1.fw instead. But I can tell you for a fact,
ath3k-1.fw won't work. You must use ath3k-2.fw.

If you have FreeBSD 9.0 or 9.1, you need this file, and you need to patch
the
ath3kfw.c program to handle the interface properly (it looks for the wrong
USB
vendor/device ID by default). The firmware and patch for the ath3kfw.c
program
are at the URL above.

touch screen
------------
The eGalax touch screen on this tablet advertises a mouse-emulation mode
which
should work with the ums(4) driver, but doesn't. The ums(4) driver is unable
to correctly handle the X and Y coordinate descriptors for some reason. I
don't understand the HID spec well enough to fix it. The result is that by
default, you can simulate a button press by tapping the screen, but you
can't
get the cursor to move.

To get around this, I had to do the following:

1) recompile the kernel so that the uhid(4) and ums(4) drivers are excluded.

2) patch the uhid.c driver so that it will bind to mouse class devices. (By
default, uhid(4) ignores HID devices that obey the mouse protocol so that
ums(4) can claim them, but in this case we purposely want to prevent ums(4)
from claiming control on the touch screen.)

3) add the following to /boot/loader.conf:

uhid_load="YES"

This forces the patched uhid.ko module to be loaded along with the kernel at
boot time. I found that even if you don't compile ums(4) into the kernel,
ums.ko will be automatically loaded to handle mouse devices unless someone
else grabs them first. Loading uhid.ko from loader.conf ensures that the
uhid(4) driver gets first crack at claiming the tablet device.

4) patch the xf86-input-mouse driver with the patch-zz-input-mouse9 (for
9.0)
or patch-zz-input-mouse9.1.7.1 (for 9.1) file. This allows the mouse input
driver to handle HID devices directly via USB instead of through sysmouse.

5) use the xorg.conf.intel_touchscreen file at the URL above. This uses the
Intel video driver and uses the USB protocol for the mouse instead of
sysmouse. Note that it selects collection #2 on the touch screen, rather
than
the default of 1.

With these steps, the touch screen is recognized by the kernel as a generic
human interface device, and the mouse input driver is modified to access it
directly. The touch screen works in X, but only in mouse emulation mode. The
'Option "Collection "2"' line in xorg.conf mentioned above forces this. If
you
don't include this line, it tries to use the gesture-based modes which don't
seem to work. But then, by default X doesn't support gestures so this is
really the best you can do. (If you know different, please tell me.)

The cursor follows your finger, and you can tap to do a button press. It can
be frustrating at times if you try to click on something small on the
screen.
It's not perfect, but it saves you from using an separate mouse.

I found out about this patch from this thread:

http://lists.freebsd.org/pipermail/freebsd-x11/2011-July/011011.html

The following stuff doesn't need tweaking:

built-in camera
---------------
The built-in Chicony USB webcam works out of the box with FreeBSD 9.0/9.1.
Just install the webcamd, cuse4bsd-kmod and pwcview packages. Don't forget
to
set webcamd_enable="YES" in /etc/rc.conf. You can run pwcview to see the
input
from the camera and take pictures with it. Note that by default, webcamd
will
create /dev/video0 such that you need to be root to access it with pwcview.
If
you do chmod 666 /dev/video0, you can access it as any user. I don't know if
there are any other video-aware apps that will work with this arrangement.

wifi
----
The built-in Atheros wifi works out of the box with FreeBSD 9.0/9.1.

sound
-----
The built-in RealTek audio hardware works out of the box with FreeBSD
9.0/9.1.
Note: the tablet has a headphone jack, but no speaker jack. The speaker is
built in -- it works, but tends to pick up noise from the fan when it's
running.

SD card slot
------------
The built-in SD card slot works out of the box with FreeBSD 9.0/9.1. It's
handled as a standard USB mass storage device. Just plug and play.

The only device which I haven't gotten to work with FreeBSD is the
accelerometer, however I don't have much use for it. (With the original
MeeGo
install that came with it, the tablet could sense when I rotated it and
shift
the display orientation automatically. I don't know if there's a way to
make X
do that though.)

The ExoPC uses an N450 Atom processor which supports 64-bit extensions. This
means you can use either FreeBSD/i386 or FreeBSD/amd64 on it. I've run
both. I
recommend FreeBSD/i386 because overall graphics performance seems better. (I
can't explain exactly why, but I think there's some part of graphics
acceleration that doesn't work properly with FreeBSD/amd64.) The tablet only
has 2GB of RAM so you don't lose much by running in 32-bit mode anyway.

I use a bluetooth keyboard with my ExoPC since X doesn't have an on-screen
keyboard. I could use a bluetooth mouse too, but I try to avoid that. I've
also used USB keyboards, a USB ethernet controller, and a USB Soundblaster
sound device. (I use that so that I can have a mic input jack, since the
ExoPC
doesn't have one built in.) I've also been able to tether my Blackberry Bold
9900 to it for network access, using both wifi and bluetooth. (It's possible
to tether over USB too using the Barry software, but doing over
wifi/bluetooth
is easier.) I've used audacity with the sound interfaces and it works fine.

The one thing about the ExoPC that irritates the hell out of me is the auto-
dimming feature on the screen when you're running it with the AC cable
unplugged. It's designed to sense ambient light and automatically adjust the
screen brightness, but there doesn't seem to be any rhyme or reason to how
it
works. Worse still, when you plug the AC cable back in, the screen does not
automatically return to full brightness. I think this is just due to buggy
firmware.

-Bill

> Thanks in advance!

-- 
Gary Dunn
Open Slate Project
http://openslate.org/