A work-in-progress tale of my configuring Fedora 14 on a Dell Inspiron Duo (the one with the flippy screen).
The basic installation was fine, and as a netbook it runs reliably except for a kernel oops in ACPI on startup (something to do with two AC adapter entries), but it doesn't seem to affect normal functioning.
Standard intel fare, so supported out of the box. I believe it does 3D (slowly - it has software texturing IIRC), but haven't tried it yet.
Configured as AHCI, so works just fine.
Warning: there are several networking variants. I have the combined wifi/bluetooth set-up with an Atheros chipset. Amazingly this just worked without me having to do anything. It's a bit tetchy if I press the "disable wireless" button, so I try not to do that. It comes right with a restart if needbe.
Worked in Cheese first time round. It's a bit slow.
The touchpad is a Synaptics jobby and was auto-configured.
ACPI handles this fine, despite the kernel oops during ACPI start-up.
When you rotate the screen round the latch it onto the body a "keypress" is generated, and ditto when you move it back again. The kernel reports these as:
[ 254.523974] atkbd serio0: Use 'setkeycodes e073 <keycode>' to make it known. [ 256.970245] atkbd serio0: Unknown key pressed (translated set 2, code 0xf4 on isa0060/serio0). [ 256.970258] atkbd serio0: Use 'setkeycodes e074 <keycode>' to make it known. [ 256.982229] atkbd serio0: Unknown key released (translated set 2, code 0xf4 on isa0060/serio0).
...so you can track e073 for enter-tablet and e074 for leave-tablet.
I added to my /etc/rc.local this line: setkeycodes e073 148
evdev translates this to key XF86Launch1, which in gconf-editor under apps/metacity/global_keybindings I bound to the action run_command_1, and then under the nearby keybinding_commands I configured it to run a program of my choice. Now, as I enter tablet mode the program is run automatically.
snd_hda_intel worked fine for output, but the microphone didn't work. Creating a file /etc/modprobe.d/alsa-duo.conf with the line options snd-hda-intel model=ideapad fixes this after a restart.
It has weird ideas on axes, and similar models are supported but this one isn't in the quirks list. Edit /etc/grub.conf and chuck the following parameter onto the kernel params line: usbhid.quirks=0xeef:0x725e:0x40
This was a devil to get going. It hangs off the i2c bus but hides, so you don't know it's there. There's a driver available, but it doesn't work as-is.
I started with the driver and then had to apply another patch of my own creation to it, to fix an issue on inserting the module, and also to fix the lack of axis-configuration.
Make sure you have the module i2c_i801 loaded to create the sysfs entry /sys/bus/i2c/devices/i2c-2 (note: since I upgraded my install it now appears as /sys/bus/i2c/devices/i2c-14 - you may need to work out which i2c bus has the i801 attached)
Building and loading this module, you can then instantiate the device with: echo lsm303dlh_a 25 > /sys/bus/i2c/devices/i2c-2/new_device and enable it with echo 1 > /sys/bus/i2c/devices/i2c-2/2-0019/mode.
At this point if you view /sys/bus/i2c/devices/i2c-2/2-0019/data it contains three colon-separated hex numbers, which are X, Y and Z values respectively. They were signed ints which have been mangled into unsigned ints, so very large values (starts "ffff") are really negative numbers. I have a script which casts these back, and values of + or - 200 seem to represent a substantial tilt.
Screen rotation with xrandr works fine, but rotating the touchpad to match is tedious - you use "xinput" to set the Evdev Axis parameters. I've combined the above accelerometer with the xrandr and touchpad rotation to create a script which rotates the screen/touchpad to match the orientation. You can try it here. I'm working on something that combines it with a touch UI.
Some people say can get this to work, either with egalax's own driver (a binary blob effort I believe) or with the hid-egalax in newer kernels. I haven't got it going, but haven't really tried very hard yet.
I haven't found out what chip it is yet. It may well lurk on the i2c bus.
Should be fairly easy to get going as it's part of the accelerometer chip and has a driver with should work with some tweaking. The i2c address is on the manufacturer's datasheet.
It's a Broadcom CrystalHD chip. There are open-source drivers for it, and a gstreamer plugin, so ought to be easy. I haven't had time to try it myself.
No driver, although the intel VAAPI driver ought to be tweakable. It's pretty low priority as the HD decoder can do MPEG2 as well.
You can email lr@lukeross.name