I just came back from the annual OpenEmbedded Developer Meeting (OEDEM) which happened to be in Cambridge, UK. It was a very productive meeting and we agreed on some important things to move OpenEmbedded forward as a whole. Please see the mailing lists for meeting minutes and summaries. We also elected a new board for the e.V. and despite the grief that led to me leaving the OE core team (which subsequently lead to the dissolving of it), I have volunteered (and been reelected) to serve a 2nd year as board member.
As written in a previous installment of this column, I have dedicated the lion’s share of 2009 to the reimplementation of the freesmartphone.org APIs in Vala. Please see the wiki for architectural details, as I don’t want to repeat this here. This is an overview of the current status:
fsousaged has been fully completed and is being used for quite a while now in distributions. All of the plugins are working:
dbus_service: Implementation of resource handling as per org.freesmartphone.Usage.lowlevel_kernel26: Low level suspend/resume handling for Linux 2.6.lowlevel_openmoko: Low level suspend/resume handling for Openmoko Smartphones GTA01/GTA02.fsodeviced has been fully completed, but is not yet being used in any distributions. All of the plugins are working:
accelerometer: generic accelerometer handling, needs one of the device-specific accelerometer plugins.accelerometer_lis302: lis 302 accelerometer support.alsa_audio: alsa audio PCM output and routing (scenario) support.kernel_idle: system idle notifications.kernel_input: system input handling.kernel_info: kernel information.kernel26_display: display class-device based brightness control.kernel26_rtc: realtime clock, wakeup alarm.kernel26_leds: LED class-device based brightness control.kernel26_powersupply: peripheral power supply control.openmoko_powercontrol: device-specific power supply controls for Openmoko devices.thinkpad_powercontrol: device-specific power supply controls for IBM Thinkpad devices.fsotimed is about half-way complete compared to frameworkd. The working plugin is:
alarm: DBus alarm service as per org.freesmartphone.Time.Alarm.fsonetwork is done with the same level of functionality as in frameworkd. The working plugin is:
sharing: internet connection sharing.fsogsmd has been on hold since end of April due to waiting for more Vala language features. When they finally appeared in September, I picked up where I left and furiosly worked on what i perceive as the prime subsystem of FSO :)
The basic infrastructure is more or less complete now and we cover about 50% of the DBus API as per org.freesmartphone.GSM.*, i.e. device info, sim access, network registration, sms, and call handling is working. All work has been done in a generic way, i.e. without taking any care of modem specifics yet – which is what will be my next task before I go on covering the missing API.
I have added a skeleton of that to the repository and adapted some lower-level classes in libfsotransport to work both for fsogsmd and fsogpsd. I would have done more work, but I’m not keen on implementing the Gypsy API, since I think it’s not a particular good DBus API
All these have not been started, not even been thinking much about ’em. fsopreferencesd will probably have to wait until dconf / gvariant / gsettings have finally landed in glib. fsopimd is waiting for a redesign of the opimd API. fsoeventsd needs a new architecture, but I have to discuss this with the others before we can start cranking.
will be a very interesting year for Linux on mobile devices, even more so for freesmartphone.org. Due to the lack of someone funding FSO, I will probably not find much time to work on FSO in 2010 – that’s why I’m so furiously working on getting most of it to a state where others can jump in before the end of this year.
Apart from that, I hope we can get FSOSHRCON’10 happening very early in 2010 and uplevel kernel support for some of the more interesting semi-open devices such as the Palm Pre, Nokia N900, and the HTC family. FSO would be more than happy to add device-specific support for this hardware once the kernel is up to par.
Cheers!