Intel Software Network articles feed

Intel Software Network TV Goes Live June 9th

Thu, 04 Jun 2009 22:25:01 -0700

Social Media Release:

Intel® Software Network TV - Live, Interactive TV for Developers - Launches June 9, 2009.

On June 9, Intel® Software Network TV, a new 24/7 live, interactive TV channel for software developers will go "on the air" at the Intel Software Network.

http://intel.com/software/tv/

Intel Software Network TV launches with a lineup of regularly-scheduled live interactive shows on software and developer topics including Parallel Programming and Visual Computing, along with "behind the scenes" access and special event coverage. Additional shows are planned for later in the year. For live shows, you can interact with the show hosts and with other viewers via the chat feature. If a live show isn't currently on air, you'll see encore presentations of previous shows, and you can always browse the On Demand area to watch any past episode.

Here is a sample of a previously recorded show, Visualize This!

Subscribe to the RSS feed in iTunes (or your podcaster of choice) to automatically receive high-quality downloads of new show episodes as they become available. Watch them whenever and wherever you want.

Follow @isntv on Twitter to be alerted when a show or special live event is about to go live. Don't miss out!

Come join us live for our big launch day on June 9!

Here are the shows and specials we have lined up:

June 9, 8 AM Pacific: Parallel Programming Talk with hosts Aaron Tersteeg, Dr. Clay Breshears and special guest David Patterson of UC Berkeley and UPCRC. Aaron, Clay and David will be discussing the challenges developers face in Parallel Computing today. The radio version of this show has been broadcast since July 2008, with over 14,000 cumulative listeners. Parallel Programming Talk can be seen live every Tuesday at 8AM Pacific on Intel Software Network TV or via podcast .

Hosts Aaron Tersteeg and Dr. Clay Breshears

Special guest David Patterson of UC Berkeley

June 9, 10 AM Pacific: Teach Parallel, a new show for parallel programming in academia. Hosts Paul Steinberg and Professor Tom Murphy of Contra Costa College will tackle the challenges of teaching Parallel Programming in academia and computer science. Teach Parallel can be seen live on alternate Tuesdays at 10AM Pacific on Intel Software Network TV.


Professor Tom Murphy	Paul Steinberg

June 9, 12 PM Pacific: A special chat with guest and Intel Software Network blogging hero, Doug Holland.

June 9, 2:30 PM Pacific: Visualize This! Show host and Intel Software Network Game Development Community Manager Arti Gupta will talk to Visual Computing Community Manager, Steve Pitzel. Steve will introduce the new Artists/Animators community and showcase resources available. This show will focus on what is new and exciting in the world of graphics, animation, and game development. Visualize This! can be seen live on alternate Tuesdays at 2:30PM on Intel Software Network TV.


Steve Pitzel	Arti Gupta

June 9, 4:00 3:30 PM Pacific: A chat with special guest David Stewart on the recently released Moblin 2.0 beta, with hands on demos.

Links:

Intel Software Network TV: http://intel.com/software/TV

Short URL (for Twitter, etc.): http://bit.ly/isntv

Parallel Programming Talk show episodes: http://software.intel.com/en-us/blogs/author/aaron-tersteeg/

Teach Parallel show episodes: http://software.intel.com/en-us/blogs/author/paul-steinberg/

Visualize This show episodes: http://software.intel.com/en-us/blogs/author/arti-gupta/

Intel Software Network Parallel Programming and Multicore Community: http://www.intel.com/software/multicore

Intel Software Network Visual Computing Community: http://software.intel.com/en-us/visual-computing/

Intel Software Network Academic Community: http://software.intel.com/en-us/academic/

Intel Software Network Manageability Community: http://software.intel.com/en-us/manageability

Intel Software Network Mobile Community: http://software.intel.com/en-us/mobility

Intel Software Network Main Home Page: http://intel.com/software/

SUGGESTED TAGS: Intel, software, developer, code, community, live, video, tv, shows, ISNTV, parallel programming, multicore, visual computing, graphics, manageability, moblin, mobile, academic, podcast

Producer:

Josh Bancroft - joshua.bancroft@intel.com, @jabancroft on Twitter

Media Resources:

Intel Software Network TV RSS feed (subscribe to high quality downloads of show episodes) - http://feeds2.feedburner.com/ISNTV

Intel Software Network TV Twitter Account: http://twitter.com/isntv

Intel Software Network Bloggers:

Aaron Tersteeg - Multicore and Parallel Programming Community Manager, @tersteeg on Twitter

Clay Breshears -Content Concierge for the Intel Developer Network Organization

Arti Gupta - Community Manager, Game Development, @artigupta on Twitter

Steve Pitzel - Community Manager, Visual Computing Community

Paul Steinberg - Academic Community Manager @psteinb on Twitter

Amy Barton - New Media Communications, @amybarton on Twitter

Additional pre-recorded Intel Software Network Videos:

Take Five Videos: www.intel.com/software/videos

Take Five Video YouTube channel: http://www.youtube.com/user/intelswnetwork

Developing for Mobile Internet Devices, Part 2: Designing, Coding and Testing a Twitter* Location-Based Application

Tue, 05 May 2009 11:05:45 -0700

By Paul Ferrill

In part 1 of this series, I showed you what it takes to build applications for the Mobile Internet Device (MID) platform. I covered the basic issues of setting up a development workstation, choosing a programming language, and making good choices in terms of external libraries. I also discussed issues like device emulation, the importance of working through a prototype “hello world” application, and common problems to avoid.

This installment gets down to the business at hand and walks through the process of designing and coding a working application. I chose a Twitter* application that will report the user’s current location as a way to exercise as many of the MID features as possible. Although it’s a simple application in terms of what it does, it has many of the parts you’d need to build any general-purpose user application.

Design Choices

Many of the functional parts of this application are foundational to everyday applications, requiring features such as user authentication, configuration storage and retrieval, network communications, and user interaction. It’s important to modularize the design as much as possible to both break the overall project down into manageable pieces and to make it easier to reuse the code.

The application checks each time it runs to see whether any user credential information has been entered. If not, it presents a typical user name/password login dialog box and stores the information in an encrypted local configuration file. A preferences dialog box makes it possible to change the user name and password after initial setup along with other program options.

For the initial release of this program, I assume that there is an active network connection. This is a bit of a stretch for the Compal JAX10* MID I tested on: It did not have an active 3G radio, so there was no “always-on” Internet connection. I was able to simulate having a consistent connection by using Wi-Fi, instead. Later versions might check for connectivity and, if currently disconnected, queue up the message to send the next time a connection to the Internet is available.

Another design consideration for the mobile form factor is deciding what happens when a button is pressed. With this particular application, there is a consequence for choosing single-key action; every time the user presses one of the action buttons, a message is sent to Twitter. If you assume the user won’t inadvertently press a button or do something like put the device in a back pocket with the application running, it shouldn’t be a problem. Alternatives might include adding a confirmation dialog box to each action (“Really send message?”), adding a button or a timer to lock the screen, or exiting the program by default after the message is sent.

Building a UI for the Small Screen

One of nice things about Python* is the abundance of libraries to do just about anything you need to do. The Compal* MID used for this project has a number of useful libraries installed as a part of the base operating system, and I chose to take advantage of them. The GTK+* user interface (UI) library contains a wealth of resources for building everything from a simple dialog box to a complex data-entry form. PyGTK is a wrapper around the GTK+ library and provides access to virtually every routine through standard Python objects.
Building a login dialog using PyGTK consists of creating a simple window with individual text boxes for username and password. You can find a good example and explanation of these techniques on the PyGTK tutorial page. In the following code snippet the pass_input.set_visibility(False) line causes the password to be blanked by a dot symbol:

def login(self):
        dialog = gtk.Dialog('Login', 
                            self.window,
                            flags=gtk.DIALOG_MODAL | gtk.DIALOG_DESTROY_WITH_PARENT,
                            buttons=(gtk.STOCK_CANCEL, gtk.RESPONSE_REJECT,
                                     gtk.STOCK_OK, gtk.RESPONSE_ACCEPT))
        dialog.set_default_response(gtk.RESPONSE_ACCEPT)
        
        userbox = gtk.HBox(False)
        
        user_label = gtk.Label('Username:')
        userbox.pack_start(user_label)
        
        user_input = gtk.Entry()
        user_input.set_activates_default(True)
        userbox.pack_start(user_input)
        
        dialog.vbox.pack_start(userbox)
    
        passbox = gtk.HBox(False)
        
        pass_label = gtk.Label('Password:')
        passbox.pack_start(pass_label)

        pass_input = gtk.Entry()
        pass_input.set_activates_default(True)
        pass_input.set_visibility(False)
        passbox.pack_start(pass_input)
	  dialog.vbox.pack_start(passbox)

Another chore for the small screen is creating a finger-friendly interface. For this application, that means buttons appropriately sized and spaced so that an adult‘s finger can easily press the button of choice. It is possible to code the button sizes specifically for the Compal screen size and resolution, but a more general approach would be to use the available system information to calculate the appropriate dimensions.

A second option with GTK+ is to create a table that fills the screen with a matrix of buttons that essentially takes up all the screen real estate. Although doing so might not be as visually appealing, it does accomplish the task of building a finger-friendly interface in which you can easily “click” the right button. It also provides a few more options for adding descriptive text to the button for the Twitter application. In Python, the matrix would look something like this:

def create_table(self):
        self.table = gtk.Table(3,4,True) # Create a 3 row by 4 column table
        button1 = gtk.Button("Button 1") # Create a button named button1
        self.table.attach(button1,0,1,0,1) # put button 1 in location 0,1
        button2 = gtk.Button("Button 2")
        self.table.attach(button2,1,2,0,1)	
        button3 = gtk.Button("Button 3")
        self.table.attach(button3,1,2,0,1)
.
.
.	
        button12 = gtk.Button("Button 12")
        self.table.attach(button12,1,2,0,1)

The lines with a single period are meant to indicate that the sequence repeats down to the final definition of button12.

Coding Practices

Python is a language that allows you to write code by the brute-force method, as in the lines above, or in a more elegant way using concepts like iteration. If you were to define all 12 buttons in a linear fashion, you would need 26 lines of code. Using the Python for construct, you can accomplish the same task in a mere seven lines of code. That equates to less than one-third of the code for this simple example, but the difference would be substantial for a larger table. Here’s the code in a more “Pythonic” way:

    def create_table(self):
        self.table = gtk.Table(3,4,True)
        for row in range(3):
            for col in range(4):
            	name = 'Twitter %i' % (row*4 + col + 1)
            	button = gtk.Button(name)
            	self.table.attach(button, col, col+1, row, row+1)

Keeping your code manageable is important when scripts start to get large. Python functions are a good way to break down your code into small, manageable pieces. It’s also important to point out that everything in Python is an object. You can see this to some extent in the create_table function through the use of the self construct. The function create_table creates a gtk.Table and returns it as an object—hence, the use of self to refer to the object being created. There is an abundance of resources on the Web if you’re not familiar with object-oriented programming concepts.

Taking advantage of all the built-in language features and functions is another way to keep your source code manageable. Python has a module for reading and writing configuration files named ConfigParser. This module provides all the tools you need to save and read program configuration information. It supports different sections and creates a file of name–value pairs within each section. There are even individual methods to retrieve specific types, such as getboolean, getint, and getfloat.

If you can’t find what you need in the Python standard library, chances are that someone else has already written what you need. A quick Google* search typically returns multiple choices for a specific tool. Python-Twitter is a good example of a helper library to accomplish the heavy lifting of sending messages to the Twitter service. It’s hosted on Google Code* and even comes with several sample applications.

Testing and Debugging

You can test code on the Compal MID in several ways. File transfer over a USB port is drop-dead simple and works well. Optionally, you could attach a USB keyboard to the Compal MID and use the VI editor directly on the device for your editing and the Python interpreter for testing. This method works okay for small proof-of-concept efforts but gets out of control for anything but small, simple programs. Another, similar approach is to use Virtual Network Computing* (VNC) to remotely view the screen on the device through your workstation.

Another way is to use the emulator approach. The Moblin* project has a tool called the Moblin Image Creator* (MIC) for building platform-specific images. With MIC you can also use the Xephyr* emulator tool to launch an independent session for testing purposes. This method has the advantage of a rapid build / test cycle to help work the bugs out of your code in short order.

A final way might be to test the initial version of the software on your Linux* desktop. The advantage is that you don’t need MIC. The disadvantages are that you may need additional hardware for your desktop (GPS, for example) and that you can’t test MID specific functionality (such as screen characteristics).

Lessons Learned

Don’t get bogged down in the details too early in the process. It’s important to completely flesh out your requirements in the beginning, then make some design decisions based on a clear picture of what you’re trying to accomplish. Get comfortable with your development tools—especially the debugging portion—as you’ll probably use them more than you think.

The easier it is for you to test and debug your code, the quicker you’ll get it running.

Have a convenient way to transfer files to your device that doesn’t require a lot of motion. This could be as simple as keeping an easily accessible USB cable plugged into your workstation. When you get down to squashing bugs, it helps to make the process as smooth and painless as possible, especially if you’re editing all the code on a workstation and have to move it over to the device for testing.

Summary

Building a solid application for the MID platform requires the same set of disciplined steps you would use in any software project. Be sure you don’t skip steps like these:

Take your time on the design process, and consider alternatives.
Think through the UI design from a user’s perspective before you start coding.
Write your code with testing in mind.
Have a clear set of requirements that you can test.
Use tools such as source code control, and check in your code frequently.

About Author

Paul Ferrill has been writing in the computer trade press for more than 20 years. He got his start writing networking reviews for PC Magazine on products like LANtastic and early versions of Novell Netware. Paul holds both BSEE and MSEE degrees and has written software for more computer platforms and architectures than he can remember.

Link to Part 1 of this series

Tools, Choices, and Development Environment Configuration.

Developing for Mobile Internet Devices, Part 1: Tools, Choices, and Development Environment Configuration

Tue, 05 May 2009 10:45:26 -0700

By Paul Ferrill

Developing applications for Mobile Internet Devices (MIDs) requires a new mindset on the part of developers. While it is possible to take an existing application and port it to a MID, it probably will not work well without some tweaking. Building a new application from the ground up to take advantage of MID features opens a world of possibilities.

Targeting a specific MID might limit the usefulness of the application. It makes a lot more sense to build in platform awareness for things like display size, network connectivity, Global Positioning System (GPS) availability, and storage. This will take a little extra coding but should make for a much more robust application. It will also make the code work on more platforms.

Making the right choices when it comes to programming language, support libraries, and user interface (UI) will determine the overall success of the project. Most open source projects typically start out as a pet project written in someone's favorite language or as an exercise to learn something new. For this article series, I use the Python language and attempt to keep the supporting libraries to a minimum.

Hardware Possibilities

The current crop of MIDs, based on the Intel® Atom™ processor, provides a combination of CPU power, graphics performance, and memory not previously available in small devices. When you add in GPS, Wi-Fi, and 3G connectivity (on some models), you have the potential for a truly always-connected device capable of delivering precision location information. This combination of hardware functionality opens up a whole new world of possibilities for applications.

This series of articles uses the Compal* JAX10 MID as the target platform. It is based on an 800-MHz Intel® Atom™ processor with 512 MB of memory, 4 GB of solid-state disk configured as two 2-GB devices, two built-in cameras on the front and back for video conferencing and taking pictures or video, GPS, Bluetooth* technology, and 802.11b/g Wi-Fi. The model tested did not have 3G wireless installed.

Powering up the Compal* JAX10 MID reveals the Midinux* operating system from Red Flag Software. A version of Moblin* specifically for the JAX10 is available from Moblin.org. It requires a bit of tweaking to get the touch screen and wireless to work, but it is doable. One other option is Ubuntu* Mobile and Embedded (UME), although it is based on an older version of Ubuntu.

UI Constraints and Choices

One of the problems developers inevitably face with small form factor devices is in designing the right UI to be both visually appealing and finger functional. Crafting a small-screen UI is one of the most important things you have to take into consideration when developing for the MID form factor. The Compal JAX10 MID has a display size of 800 × 480, which can chop off the lower portion of some fixed-sized dialog boxes.

Choosing a flexible and easy-to-use UI foundation library helps keep your development struggles to a minimum. Which library you select depends a great deal on the type of application you're looking to build. The GTK+* framework comes as a standard part of both Midinux and Moblin, so you won't have to include or require any additional libraries should you choose to go that route. Moblin has also decided to standardize on Clutter* for graphics-intensive applications.

Development Environment

Although you could do the development work on either a Windows* or Linux*-based computer, it really makes the most sense to use a Linux system for a number of reasons. The build-test-build cycle goes more quickly when you run on the same operating system. The only exception might be when using a language like Python* that doesn't really require compilation. In addition, Linux target device emulation has the best support from the Linux operating system.

Choosing a stable, popular distribution like Ubuntu makes it easier to get the tools you need up and running quickly. It also increases your chances of finding help for problems you might run into, as more often than not, someone else has already found a solution. Ubuntu is also one of the distributions-along with Fedora* 9-directly supported by the Moblin project. We chose Ubuntu 8.10 to use on our development system for this project.

Consider using a fairly recent computer with hardware virtualization support as your primary machine. Some of the virtualization software packages require hardware virtualization support to work properly. Others will work without it but obviously run faster if the support is available. You should max out your memory, as well, although a 32-bit machine can't really use more than 3 GB.

Developer Tools

Most seasoned developers have a preferred set of tools they feel most comfortable using. For many in the open source world, this toolset equates to Eclipse* and some number of add-ins. Although Eclipse was built on Java* technology and counts Java developers as its largest user base, it does support other languages quite well. Nokia* uses Eclipse as the foundation of its developer tools to deliver a high-end experience complete with emulation and target device deployment for the Nokia* N810 family of devices.

Anjuta* is another integrated development environment (IDE) with a substantial following. Anjuta is written in the C language and uses C for its application programming interface (API) and plug-in architecture. It does provide decent support for both C++ and Python, as well. Support for other languages, including C#, is in the works. Of particular interest to UI designers is the integrated Glade* tool, with tight support for editing and creating Glade files.

Intel has a number of open source tools available to developers serious about squeezing the most out of their applications. New power-management profiling tools make it possible for developers to determine exactly how much power individual pieces of their code consume. The Application Energy Toolkit evaluates applications to determine how "power aware" they are. Versions for Windows, Linux, and Mac OS* X version 10.5 Leopard are available. Specifically for mobile developers, the Intel® Mobile Platform Software Development Kit (Intel® Mobile Platform SDK) offers a number of different tools to facilitate building "mobile aware" applications.

Emulation

One of the best ways to test your software without actually loading it onto the target device is through emulation. A number of emulation tools work only in the Linux environment. Red Flag* Software uses Xnest* in conjunction with chroot in its SDK for Midinux, which makes it possible to run in virtually the same environment you would be running on the target device. For our purposes, there's a how-to on the Red Flag site for configuring its SDK to work with Xnest.

The Moblin project uses a similar approach with its Moblin Image Creator* (MIC) tool. This graphical user interface (GUI) application helps you create a target Moblin image for a specific platform, then test it by using Kernel-based Virtual Machine* (KVM). MIC can also build VMware* VMDK* images for use with VMware's player application, which gives you the option of running completely inside a virtual environment without making any modifications to your host machine.

Getting Started

The best place to start with any project is the beginning. Developing a set of requirements that meet your goals helps determine the overall direction of the project. Even if the project is fairly simple, it always helps to write down what your application will do. For this effort, I focus on an application that will take advantage of a number of the MID features, including the GPS and Wi-Fi connectivity.

It's a good idea to go through the process of creating the typical "hello world" application after you have your development environment configured to your liking. This might seem like a trivial exercise, but it confirms your ability to build your code then deploy it to your target platform. It might also help you think through how best to automate the process to save time in the future.

Be sure to enable Secure Shell (SSH) on the target platform to make it possible to enter commands remotely. For the JAX10 notebook, you must type a command in a terminal window on the device to start the SSH daemon. Launching a terminal window requires you to press the Fn and P keys simultaneously (Function P), which brings up a prompt similar to this:

[root@CompalMID~]#

To start the SSH daemon you must type:

[root@CompalMID~]# /etc/init.d/sshd start

You should see:

Starting sshd:  								[OK]

When that's done, you'll be able to use an SSH client tool to connect remotely to the device. You need the IP address to connect: You can find that information with the IFCONFIG command.

Avoid Common Problems

Don't get bogged down in the details too early in the process. Trying to write code to accomplish a task you don't understand well is not a good idea. Reading the documentation and studying example source code for any library or packaged code you choose to use could actually save you time in the long run. Reading through forums or old IRC logs can help answer questions and provide some insight as to how others have approached similar problems in the past.

Don't be afraid to build small "proof of concept" applications to figure out how something works-say, how to connect to the GPS or how to properly size a button based on the display dimensions of the device. Look for other code that accomplishes the same thing. Don't be too proud to learn from someone else's work. The Python community has a large body of code to do just about anything you can think of. You can find a wealth of searchable code examples on the ActiveState Python Cookbook site.

Do use some type of source control system for tracking revisions and keeping your source code backed up. It's a good idea to either use a hosted service or run the main source code repository on separate machine from your development computer. Then, you'll always have a way to recover should something happen to that machine. Concurrent Versions System* (CVS) has been around forever, while Subversion* (SVN) and Git* are more recent possibilities.

Summary

Building software applications for the MID platform requires a new mindset and a good set of tools to do the job right. Keep these things in mind when starting out:

Choose a good IDE that you're comfortable with.
Use a popular Linux distribution like Ubuntu for the operating system of your development computer.
Don't skimp on your development hardware, and do get a machine with a recent processor and ample memory.
Use good software development practices, like gathering requirements and using a source code control tool.

About the Author

Paul Ferrill has been writing in the computer trade press for more than 20 years. He got his start writing networking reviews for PC Magazine on products like LANtastic and early versions of Novell Netware. Paul holds both BSEE and MSEE degrees and has written software for more computer platforms and architectures than he can remember.

Link to Part 2 of this series

Designing Code and Testing (coming soon).

An Edge By Design for MID Applications

Thu, 30 Apr 2009 17:16:02 -0700

Design research and design-driven best practices can help your application development get an edge.

By Knut Graf. Knut is a Principal Designer at frog design, a global innovation firm.

Abstract

The Mobile Internet Device (MID) platform has to establish a following of users and a set of high quality applications, which presents a kind of chicken and egg challenge. The lack of a track record to refer to, along with other factors that are common to emerging platforms, makes application development on MIDs challenging. Yet, high-quality applications are critical to the platform's success. Design, as expertise and as a set of practices, can address many of the risk factors that characterize this situation.

Design ensures that the product vision is relevant to the user by gathering knowledge about the user and the application's usage environment through informal discovery activities and through formal research. Based on the knowledge gained in this discovery phase, a crisp feature definition lays the groundwork for a great user experience, which is built out through a compelling look and feel. A prototype confirms the product vision amongst team members and guides implementation and testing, thereby reducing the need for lengthy and tedious traditional requirements documentation.

The guidance and streamlining that design brings to an application development process allows the core development team members to devote proper amounts of attention to technical challenges and quality, greatly improving the odds that the project will be completed and successful.

Introduction

The software industry has established a track record over the last few decades of slowly making its development practices more efficient and effective. Even so, software projects are still burdened with high failure risks. The quality of projects that make it to market is hard to predict. For example, in consumer-facing applications, for every well-rounded product, there is another one full of bugs and quirks. Properly introducing "design" into a software project is one way to increase its odds of success.

Many processes and best practices address risk and quality concerns in software projects. In practice however, such practices compete with established habits and the temptation to take shortcuts.

Design has a variety of effects. Approached naively, design can raise expectations and then confuse and complicate the actual process, inundating unprepared developers with distractions and implicit requirements. On the other hand, a proper approach to harnessing design for software development can ensure that the end product is both relevant and beautiful. Along the way, the collaborative aspects of design process can align stakeholder's expectations and even save development time by using prototypes to communicate project goals.

Design - whether it be "Interaction Design," "User Interface Design," or "Experience Design" - is not retrofitting a screen with pretty graphics. Applying design to an existing project provides limited value. Design in software development is much more valuable when applied as a way to discover, refine, and execute proper success criteria.

Addressing the MID Form Factor

The Mobile Internet Device, or MID, is a low-power mobile device with many of the capabilities of a full PC. It employs a small, high-resolution touch screen and a reduced keypad. The MID platform provides unique new usage opportunities and advantages that translate into an exciting new market opportunity. MIDs offers new capabilities in terms of computing power, display quality, touch-input quality, and connectivity, along with a high amount of energy invested in the software tools.

The way the platform's promise translates into value to the end user is through the software running on it. Software turns abstract capabilities into user-facing features. Software applications will decide the fate of the platform: Compelling usefulness will give mobile internet devices a place in our everyday lives, bringing success to the platform. Falling short, MIDs will join our Palm* Pilots in the gadgets drawer, awaiting their fate at the next garage sale.

The platform's promise does not guarantee success. MIDs faces some specific challenges in terms of application development - challenges that design can help address.

Thinking Small

With or without all the power delivered by a MID, the small device form factor limits the gamut of interactions that people will want to engage in. Comparing the same task on a small device and a large device, the small device requires more dexterity and concentration from the user. Simplifying tasks for small devices means challenging the user's habits and expectations.

Lean Teams

The limited out-of-the-gate user base constrains the economically sensible investment to be made. Development teams will be lean and schedules will be short, even as the application development community is still familiarizing itself with the MID development environment.

Porting

Many projects are ported from existing implementations on other platforms. Considerable updates to such projects are often required to allow them to take full advantage of the specific conditions offered by MIDs.

Device Definition

Smart phones, with ever-growing capabilities, and the booming netbook contest the space for the MID platform. Acceptance for MIDs depends on unique value which neither of these other device classes can offer.

Establishing a Target Design

In software application development, challenges are not unusual. Any software development project, regardless of the platform, comes with challenges. The way to mitigate the risk associated with these challenges is to decide upon a focused, valuable target, and to stay on this target.

At the heart of a software application is the basic idea, "does it do something useful?" For the application to be successful, the answer must be "yes." A software project starts with existing ideas for specific features, or with general goals. These existing goals are formalized, to arrive at an implementable specification. During this process of formalization, the goals are examined, refined and adjusted.

The first step towards the feature definition is learning who the end user is, what the end user likes, and what the end user does.

A certain amount of general knowledge about users can be derived from the MID platform goals as a whole, as well as from interpreting the usage opportunities offered by target devices appearing on the market. Beyond this common sense approach, design provides a set of tools to get a clear picture of the end user and of the opportunities for application usage afforded to the user.

User Personas

A user persona provides a description of an imaginary, but specific person who would use the application. A user persona is meant to be realistic and robust. A user persona describes the habits, preferences and environment of the target character, to provide a framework from which the character would make judgments and decisions. The user persona is a conceptual simulator for the practical value of new features.

Idealized Personas

The practical use of an application is not the only question to consider. An application can be an enabler to the user, providing functionality that is socially attractive and desirable, regardless of its usefulness in a traditional sense. Idealized personas provide a handle on defining this type of functionality. Idealized personas are traditionally used in the discipline of marketing, not in the more "down to earth" context of usability. Actual people aspire to the attributes the idealized persona embodies. The idealized persona is more sophisticated then a real person, bound by fewer constraints. Some stereotypes might be used to define this persona. The idealized persona provides a sounding board for empowering, uncommon feature possibilities.

Scenarios

A scenario describes a situation, and a sequence of events, in which the device and the software application running on it are used. The scenario is meant to be realistic, to provide a background to judge the value of the planned application and its features. The more detailed the scenario is, the more it can serve as a source and validation point for specific ideas.

Other, less standardized forms of documentation can be used as a basis for feature definition. The assumptions and conclusions in any feature documentation can be tested and strengthened by personas and scenarios as verification points.

Personas and scenarios are speculative in nature: they are based on assumptions. To add a grounding in realism to these assets, we recommend that design research activities be performed.

Mining Reality for Knowledge: Research

Design research mines real life for project-relevant information. Common methods include surveys, user interviews, and contextual inquiry, in which the researcher engages with a user one-on-one to observe activities. Ranging from simple to very involved, the value of the research results grows with the depth of user-engagement.

Design research requires preparation time and careful analysis of data. The schedule impact must be weighed against the benefits to the project. Consider that often the benefit is a drastic reduction of risk.

For applications that provide narrow specialized feature sets for vertical markets, the value of research is fairly obvious: it provides knowledge of the problem domain to the team. For common applications with mass-market, mainstream functionality, the value proposition is more subtle: while the team is familiar with the domain, the deeper examination can provide insights into key differentiators that escape the naked eye.

Generating the Design

Equipped with a picture of a target user, and solid knowledge of the real-world context, designers unearth feature opportunities for the application. Some opportunities will be obvious from looking at a scenario. Interpreting research data and applying abductive reasoning to the problem space knowledge uncovers further opportunities.

Designers define features by mapping the opportunities and constraints to an actual software structure. To arrive at valid results, design principles are applied to guide this exercise. In absence of specific native design principles for MID devices, proven design principles from other small platforms can be used.

The actual feature definition is expressed as a vision of the resulting program, and this is done in the form of diagrams, wireframes, and visual mock-ups. Abstract features are given a concrete expression. This documentation provides a moment of truth for project stakeholders. It serves as the first concrete shared picture of "the design" and a glance at the project outcome. As the project continues, collaborative discussions will adjust this picture.

The design addresses core features first, and then it takes on secondary features such as peripheral details. One after another, parts of the application get addressed, designed, documented, designed and adjusted.

Design Principles for Mobile Platforms

For relevance to the MID form factor, Table 1 lists a set of design principles that are relevant and apply to mobile platforms.

Mobile Platforms Design Principal	Description
Immediate Results	Small, mobile devices offer themselves to be used spontaneously, whenever opportunity beckons. Such an opportunity for using the device, especially when occurring in a mobile situation, may not last long, as other things compete for the user's attention. To ensure a successful user experience, the application accessed by the user must waste no time in providing results. The tasks offered by the application must be straightforward, leading to immediate results. Long sessions that require continuous user attention are better suited for a full-size PC. The home screen application of the HP* Mini 1000 MI (Mobile Internet) Edition netbook is an example for focus on immediate results. The HP MI Edition is the Linux* version of this product. Its home screen accumulates recent e-mail, web shortcuts and thumbnails for favorite music and photos. The traditional "launch and dig" sequence to get to content is eliminated. In contrast to this approach, most other netbooks just offer collections of program icons on their home screen.
Adequate Feature Density	Besides being short, the path to results must also be obvious. Few users will tolerate forced way-finding exercises. Given the constrained screen real-estate, this principle is applied by carefully designing decision trees to present clear decision points, and by limiting the amount of inputs asked of the user. Full-size PC applications have more leeway for less-clear structure. Feature density is an important consideration especially when porting existing full-size applications to a MID.
Adequate Information Density	While the small, high-resolution screen is a brilliant display, it is still, and foremost, simply small. The number of concurrently displayed content items should be more limited, to avoid intolerably microscopic text and graphics
Flow	Since not every interaction can be reduced to a few buttons on a few screens, the user will inevitably spend time completing non-trivial tasks. Those tasks may be necessary sequences, such as forms that must be filled, or voluntary sequences, such as meandering through a media library. In either case, the immersion that is achieved by presenting a steady stream of simple choices, creates a level of comfort. The immersion must not be interrupted trivially by modal alerts or dead-end flows. This is a general design principle, but on a small form factor platform, the temptation to present such interruptions is higher then on full-size PC applications, because fewer opportunities are available to communicate secondary information in more subtle ways.
Interruptability	It is a common full-size PC experience ritual to launch an application, and then to open a document, or to perform some other initiation procedure, before getting to the actual task at hand, and to save and quit the application when done. On a MID device, where application state management is not on the user's mind, and usage session durations are short, this ritual gets in the way. Dealing with any sort of sequential task becomes more feasible, even attractive, once it is possible to effortlessly "Pick up where you left off".
Progressive Disclosure	Progressive disclosure, the hiding of secondary information on secondary screens, is a well-known, valuable design principle. Applied to a MID, it can be read slightly differently: high density of information, as encountered in an existing PC application, can be preserved, behind lower-density summary screens, when the application is ported to a MID. Such summary screens, presented as the initial entry points of an application, provide the right small-device scale and satisfy many scenarios. More traditional, higher-density screens underneath, can provide unexpected horsepower for full-featured PC functionality. Handled with care, progressive disclosure is a valuable principle for porting existing applications to MIDs.

Table1: Design Principals for Mobile Platforms

Look and Feel

Expressing features as parts of a software application is not a mechanical procedure. It’s a subjective process, in which the designer makes personal decisions. As a result, the application gains a unique personality. This personality is expressed in the “look and feel,” which has a great impact on shaping the user experience. The user experience — literally the string of moments the user lives through while interacting with the product — determines the user's memory and judgment about the device.

Look and feel ensures usability through design patterns that string user-facing objects together in ways that make sense. These patterns are reused across the application, providing comfort and predictability.

Look and feel is concerned with the details of the experience: the central moments when the user pays detailed attention, and those less important moments that lie in between and help string the important ones together. All these moments benefit from the beauty of well-executed emphasis and guidance, through visual means like composition, contrasts and harmonies on a pixel level.

The user’s experience of an application is shaped over time, as the application changes state during use, bringing up one screen after another, or updating the content that is shown on the screen. This temporal aspect of the experience is part of look and feel too. It can be shaped to provide a good flow, actively help the user with tracking the application’s state, through meaningful transitions.

Iconic examples of strong, experience-shaping look and feel are the “Fluent” interface of Microsoft* Office 2007, or the category-defining appearance of the Adobe* Lightroom application. Such strong statements can be controversial at first, as they force users to jettison old habits. But they usually establish a following and invite imitations.

Implementation Complexity as a Concern

While working on the ‘look and feel’, the designer must be aware of the implementation platform, and its constraints and opportunities as they relate to the user interface. For MIDs, Hildon* is the primary choice platform, and it has some very specific characteristics. It cannot be emphasized enough that the design must be implementable on the given platform, by the developers tasked with the job, in the timeframe available.

To avoid surprises, it is essential that the actual development team members who are responsible for the UI execution provide their perspective to the designer during the look and feel work. A professional designer is prepared to listen.
With a design team on board, there usually is a temptation to go for a totally custom UI, to maximize usability, beauty, flow, and branding. These are noble intentions, but must be checked against the realities of schedule- and resource constraints. A simpler look and feel that is actually executable might be a better way to go. After all, the measure of success is the real product that makes it to market.

To ensure that the project is on track, the design must be truly understood by all stakeholders. A particular asset can communicate the design much better then any combination of diagrams, wireframes and specification documents: the prototype.

Expressing Living Features: A Prototype

As the regular implementation preparation proceeds, a design team can provide a valuable contribution typical project constituents can’t — a prototype. A developer, sometimes called a design technologist, puts the prototype together. This prototype shows core moments and aspects of the application. The ideas shown are those of the project team as a whole, as captured from the stakeholders. The design team shapes these ideas, infusing them with a user-facing structure that eventually evolves into a coherent look and feel. The main value of a prototype is its ability to play out concurrent changes from multiple separate angles of the project. Valuable time can be saved this way, and the project team can cover a lot of ground in the process.

The prototype is an antidote to analysis paralysis. Application structure, functionality, and look and feel come together as a unit and are refined together. The in-progress result is visible to the entire team, serving as a validation point. The aspect of validation can be taken further, by presenting the prototype to users, who provide both usability feedback and emotional responses, without the need for preparation of additional test assets.

The prototype neither has to be perfect nor complete, as long as it provides meaningful insights. Bugs and dead ends are allowed and expected, so the developer can focus on relevant details.

As the prototype is built out, it takes on the role of a living specification, replacing much of the traditional specification documentation that otherwise must be written and maintained. Traditional specifications still play a supporting role, filling in detail for areas that the prototype doesn’t cover. The application developers refer directly to the prototype as a reference for the implementation. The QA team can do the same, informing a traditional QA process by referencing the prototype, bringing efficiencies to the testing process.

To Do This, Do You Need a Designer?

The answer to the above question is, “it depends.” Do you have enough knowledge of your problem space to perform a well-grounded feature definition? Do you have the time to take care of the details for a good follow-through? Will your stakeholders take care of this for you?

Common Sense…

It is evident that not every good piece of software is produced with the involvement of a dedicated designer or design team. Much useful work, in terms of crisp feature definition and high execution quality, can be done by “simply” assuming a design perspective.

This reliance on common sense thrives when a self-motivated developer is driving the work and making her own decisions, within a manageable scope of work. But the efficiency of this approach does drop off, experience suggests, as the complexity of the challenge grows and more stakeholders come to the table. This is not at all a matter of malevolence by any stakeholder: all parties do want the best outcome. It is more a matter of entropy: as more perspectives and opinions come into play, more forces are at work. In such a situation, any perspective that is not formally represented will not be heard. Ask yourself: who is representing the end user?

…And Addressing Complexity

As project size increases, the complexity of the design-addressable challenges also grows, quickly reaching a point where common sense falls short. Here, the benefits of a professional perspective become obvious. Just as the development team should not be handling accounting on the side, it is not in a position to be handling design. The design team’s role is not meant to weaken other project contributors design ideas. On the contrary, the design team synthesizes everyone’s contributions, amplifying the good ones. This synthesis is essential when many different perspectives need to be heard. On large projects without formal design participation, design will go wrong.

Engaging a design team can bring otherwise unattainable results to a software project: a unique execution, with an outstanding look and feel. This can turn out to be the single, critical differentiator in the marketplace.

Change the Odds

Full-size desktops and laptops have long given up their position as the only form factors for personal computing. After small form factors had been pioneered by the PDA, the mobile phone matured to provide ad-hoc information access and media consumption. The laptop as sole choice for mobile content creation and productivity has made room for the netbook, its smaller, less powerful sibling. Each of these form factors thrives on useful, attractive software. That’s evident when you consider the variety of software being used on near-identical hardware.

The MID form factor is in a position to be the next step in this march of personal computing to ubiquity. New form factors start as an underdog. To fuel their possible success, great applications first have to be created, under developmental conditions that are more challenging than those on established platforms. As the software industry comes to terms with the platform, design can make a contribution to the quality of individual software experience offerings, which is what counts most at the current moment in the lifecycle of the platform.

About the Author

Knut Graf is a Principal Designer at frog design, a global innovation firm. Frog Design* works with the world’s leading companies, helping them create and bring to market meaningful products, services, and experiences. Knut joined frog in 1997 and has since served as Developer, as Content Architect and as Senior Design Analyst before assuming the role of Principal Designer. Knut has worked with clients such as SAP*, Microsoft*, and HP*. His recent work includes contributing to the well-received HP Mini 1000 MI edition user interface as a design lead on the project.

Knut's work focuses on software user interfaces, from idea development to implementation. He guides software designs through the time- and resource constraints that real-world software projects bring, ensuring that the user experience of the end product is of the highest quality possible.

In his work, Knut brings a programmer’s view of software development to a German design education background, to create innovative solutions that empower both the end user and the development team that has to meet shipping deadlines. In Knut’s opinion, design work must be judged by the quality of the end product. It is the actual result that matters, not the unrealized potential.

Obtaining Display Information on Mobile Internet Devices

Wed, 22 Apr 2009 16:34:23 -0700

Introduction

With the advent of Mobile Internet Devices (MIDs) based on Intel® Architecture, the porting of desktop and laptop applications to mobile hand-held devices has become significantly easier. However, one area of continued challenge is the adapting of screen layout and user-interface navigation to this small form factor. These devices have a screen size that ranges from 4.5" to 7" and a resolution of at least 800 x 480 pixels. Device characteristics of increased pixel density, combined with the ability to rotate between landscape and portrait orientations, and the strict display brightness constraints necessary to preserve battery power, make it essential for compelling software to be aware of the device's display attributes. Ideally an application will obtain this information at runtime in order to dynamically adapt.

Since MID devices run Moblin-based, Linux operating system, this paper will describe several mechanisms for obtaining display information in a Linux compliant manner. Unfortunately, all display information isn't available from one easily accessible source, so this document will cover the various sources of screen information. The X Window extension X Resize and Rotation (XRandR) is a good source for resolution and screen orientation. Physical screen dimensions are also available through the XRandR API but accuracy of this particular information is dependent upon screen drivers providing accurate EDID values. Another source of information is the Hardware Access Layer (HAL). This component exposes a wide range of system information; the properties of interest in this context are screen brightness and the levels of brightness. These pieces of information, as well as other platform and context information, can also be retrieved using the Platform Awareness Service, available from Intel® on Moblin based platforms.

Getting Display Information from XWindows

The X11 library is designed to provide a connection to the X Server. It allows access to size and rotation information about the root window of the screen and also provides the ability to set these values.

In order to get to the resolution information, several preliminary calls need to be made to connect to the X Server and get to the desired data structure. First, a call to XOpenDisplay() connects to the X Server and returns a Display pointer. The X11 architecture allows for multiple Windows, with the root window being the one that holds the information we want. A call to RootWindow() will return this window. Once the display is opened and the Root Window is obtained the third call can be made to XRRGetScreenInfo() which returns an XRRScreenConfiguration structure.

#include 
 
Display *dpy;
Window root;
XRRScreenConfiguration *sc;
 
dpy = XOpenDisplay (NULL); //open the current display
if (dpy) 
{
      root = RootWindow (dpy, 0);    
      sc = XRRGetScreenInfo (dpy, root);

After the XRRScreenConfiguration structure is obtained it can be used to make the call that actually returns the resolution information. X11 allows for the possibility of an array of sizes of which the first represents the current display. A call to XRRConfigSizes(), passing in the XRRScreenConfiguration, will return this array. Each element of the array contains a width and height value.

XRRScreenSize *sizes;
unsigned int nsize;
unsigned int xres, yres;
 
sizes = XRRConfigSizes (sc, &nsize);
 
if (0 >= nsize)
{
      xres = sizes[0].width;
      yres = sizes[0].height;
 
}

The physical dimension of the screen can be obtained directly from the XRRScreenConfiguration structure via the screen member. It should be noted however that the accuracy of this information is dependent on the screen driver providing correct values from the display device's Extended Display Identification Data (EDID) block[1]. At the time or this writing the display devices on a number of publicly available MIDs do not provide correct information.

// Physical dimensions
         
int mwidth, mheight;
 
mwidth = sc->screen->mwidth;
mheight = sc->screen->mheight;

The other interesting display attribute that can be obtained from X11 is the screen orientation. According X11 there are four settings of rotation; 0%, 90%, 180% and 270%. X will also tell you which of the rotations are supported on the current device. A call to XRRRotations(), passing in the previously obtained Display pointer will return this info as a bit array. The X11 header file defines values that can be used to mask out the supported rotations.

// Screen Rotation – What rotations are supported

Rotation rotations_supported, cur_rotation;
bool bRotate_0, bRotate_90, bRotate_180, bRotate_270;
 
rotations_supported = XRRRotations (dpy, 0, &cur_rotation);
 
if (1 >= rotations_supported) 
      return; // Screen rotation not supported
else 
{
      if ( 0 != ( rotations_supported & RR_Rotate_0))
            bRotate_0 = true;
      if ( 0 != (rotations & RR_Rotate_90))
            bRotate_90 = true;
      if ( 0 != (rotations & RR_Rotate_180))
            bRotate_180 = true;
      if ( 0 != (rotations & RR_Rotate_270))
            bRotate_270 = true;
}

The cur_rotation variable that was passed to XRRRotations() specifies the current rotation. Again the X11 header file defines values used to interpret the current rotation value.

switch (cur_rotation) 
{
      case RR_Rotate_0:
            ...
            break;
      case RR_Rotate_90:
            ...
            break;
      case RR_Rotate_180:
            ...
            break;
      case RR_Rotate_270:
            ...
            break;
      default:
            return false;
}

Finally, cleanup needs to be done to free the XRRScreenConfiguration struct and close the display.

XRRFreeScreenConfigInfo (sc);
XCloseDisplay(dpy);

Getting Screen Brightness information from the HAL

Screen brightness information is not inherently necessary for MID screen layout and navigation. However, since battery power savings is one of the most critical aspects of MID design, screen brightness management becomes an important factor of overall efficient power usage, and an application may wish to modify its behavior or appearance based on screen brightness settings.

The HAL is a software layer that provides access to various pieces of hardware on a system. Metadata is available describing the hardware, its state and notifications of change. A Device Object with accompanying properties is used to represent each piece of hardware. Namespaces are also defined to group the properties into logical categories. Finally, D-Bus Interfaces are defined as the access mechanism to the properties and notifications within a namespace. For background information on the D-BUS architecture and usage refer to these locations:

To make a D-BUS connection to the HAL, several steps are necessary. First, a pointer to the System Bus is obtained by calling dbus_g_bus_get()[2]. With the system bus pointer, an interface can be obtained to the HAL Manager by calling dbus_g_proxy_new_for_name(). This manager will allow a search for all objects on the system with the "laptop_panel" capability. The object that provides "laptop_panel" capability is where screen brightness information is found.

DBusGConnection *systemBus;
GError *error
DBusGProxy *managerProxy;
char **deviceList;
int len;
 
// Initialize the System DBus connection
systemBus = dbus_g_bus_get(DBUS_BUS_SYSTEM, error);
      
if (systemBus == NULL) 
      return FALSE;
 
managerProxy = dbus_g_proxy_new_for_name( systemBus,
                              "org.freedesktop.Hal",
                              "/org/freedesktop/Hal/Manager",
                              "org.freedesktop.Hal.Manager" );
 
dbus_g_proxy_call(managerProxy, "FindDeviceByCapability", &error, 
                              G_TYPE_STRING, "laptop_panel", G_TYPE_INVALID,
                              G_TYPE_STRV, &deviceList, G_TYPE_INVALID);      
len = g_strv_length(deviceList);
 
if (len = 0)
      return false;

Now that we have a pointer to the list of laptop_panel objects we can get the interface that directly provides the screen brightness properties (note the following code assumes there is only one screen attached to the system). This is done with the same call used to obtain the HAL Manager but specifies the Device.LaptopPanel interface as the fourth parameter.

char **devices_ptr;
DBusGProxy *deviceProxy;
 
devices_ptr = deviceList;
 
deviceProxy = dbus_g_proxy_new_for_name(  systemBus,
                              "org.freedesktop.Hal",
                              *devices_ptr,
                              "org.freedesktop.Hal.Device.LaptopPanel" );

To get the current brightness setting, we need to call a method of the LaptopPanel interface called GetBrightness. This is done again with dbus_g_proxy_call function but takes no parameters and returns the brightness as an integer.

uint brightness;

dbus_g_proxy_call(deviceProxy, "GetBrightness", &error,
                              G_TYPE_INVALID,
                              G_TYPE_UINT, &brightness, G_TYPE_INVALID);

Conclusion

By obtaining a few basic pieces of screen display information (resolution, orientation, physical dimensions and screen brightness) an application is poised to adapt efficiently and dynamically to the various MID form factors and their changing display characteristics. With this information in hand, the real work of creating MID optimized UI designs and navigation can begin!

References

XrandR Project Documentation - http://www.x.org/wiki/Projects/XRandR
HAL 0.5.10 Specification - http://people.freedesktop.org/~david/hal-spec/hal-spec.html

[1] For more information see http://www.vesa.org/Public/EEDIDguideV1.pdf or http://en.wikipedia.org/wiki/Extended_display_identification_data

[2] This is actually a glib wrapper to the D-Bus function that retrieves the bus. The glib wrapper is used in this discussion because it is less complex than using D-Bus directly.

Moblin Platform Awareness Service

Wed, 22 Apr 2009 16:18:42 -0700

Platform Awareness Service – An Introduction

The Intel® Mobile Internet Device (MID) platform provides a full internet experience in a pocket-sized form factor. Combining Moblin-based operating systems with the Intel® Atom™ processor, MIDs are able to run applications that have been built for the x86 architecture, reducing the cost of porting applications to this platform, while significantly expanding integration potential with existing infrastructures. While the features of the devices that are and will be on the market will vary widely, all MIDs have several features in common (some more obvious than others): a low-power Intel® Atom™ processor, a highly variable set of input mechanisms, a touch screen display, multiple radios and network connectivity options, limited battery and storage capacity, and in many cases an onboard GPS. These hardware devices have been exposed to software developers by way of the Platform Awareness Service, a lightweight, read-only, D-Bus initiated platform information provider. Since the final software stack for each device is determined mainly by Original Equipment Manufacturers (OEMs) and Service Providers (SPs), this service may not be pre-installed on Intel® MIDs. Therefore this series of whitepapers has been written in an effort to simplify access to this information on platforms that do not have this service installed.

Many of today’s traditional web applications are built with a client server architecture where all the processing is done on the server, and the client is only used to display static content. All interaction with the application must be sent as a request to the server, and then a response is formatted and sent back to the client where is it simply rendered in the browser window. In this interaction, the client is somewhat analogous to a terminal. Very little of its resources are being used to contribute to the experience the user is getting.

Rich Internet Applications (RIAs) represent the next evolution in the traditional web application model. RIAs employ the power of the client to augment the experience by utilizing the processing power that was previously mostly ignored. RIAs are web applications that have the many of the features of traditional desktop applications, as they introduce another layer of processing on the client that handle richer features such as rendering, state management, and storage.

The functionality of a RIA is only limited by the capabilities of the client. Instead of designing for the lowest common denominator, RIA’s have the opportunity to scale their features and interfaces to match what the client can handle. Awareness of the client’s capabilities therefore becomes critical when determining how to scale an application’s features, or how to present the user interface. The information exposed by the Platform Awareness Service can be used by RIA designers to effectively scale their applications to the next level.

Whitepapers have been authored introducing developers to each key area previously mentioned:

Utilizing Processor Performance in Rich Internet Applications discusses the exposure of processor capabilities to developers.
Determining Input Devices in Linux discusses input mechanisms.
Obtaining Display Information on Mobile Internet Devices covers device displays.
Detecting Network Connectivity Using D-Bus, network connectivity.
Developing Power Aware Applications Using D-Bus, enables application awareness of device power states.
How to Obtain Storage Information in Linux addresses storage capacity.
Last but not least, How to Obtain Location Information in Linux covers integration of location-based information into your applications utilizing the GPS.

A quick API reference is available in: Platform Awareness Service: D-Bus Interface Definition. Finally, the Platform Monitor sample application has been included in the package, clearly demonstrating syntax and usage of the Platform Awareness Service API. Full documentation for this tool is available in the: Platform Monitor User’s Guide.

As always, feedback is greatly appreciated and will aid development of upcoming releases. Feel free to submit a comment to the Intel® Software Network, or alternatively send an e-mail to either jeremy dot saldate at intel dot com or clayne dot robison at intel dot com. Happy coding!

Further Research

API Reference

Information about how to use the Platform Awareness Service DBus Interface.

Sample Applications

Source Code

Platform Awareness Service CVS Tree Snapshot (Inludes Platform Monitor) (4.5MB)
Platform Awareness Service Midinux Source RPM (1.4MB)
Platform Awareness Service Midinux Source RPM (Debug) (1.4MB)
Platform Awareness Service Midinux Source RPM (No GPS) (1.4MB)
Platform Monitor Source RPM (2MB)

Downloads

Community

Detecting Network Connectivity Using D-Bus

Wed, 22 Apr 2009 16:14:00 -0700

Preface

Introduction

With the advances of computer networking within the last decade, devices can be connected via a myriad of technologies and protocols, wired and wireless. This connectivity has become so prevalent that many applications can’t function without it. Some application functions take advantage of network communications such as email, network gaming, web browser, etc. Some real-time applications, especialy networking games, require a large bandwidth and high network reliability. These applications must be aware of the network connectivity. Mobile computing devices such as a laptop or Mobile Internet Device (MID), frequently use wireless technology and thus network awareness becomes even more important. Instead of letting each application write its own connectivity awareness code, we propose a uniform way to convey the connectivity information to applications. Laptop/MID applications can then refer to our system to get information on network connectivity and make proper decisions at run time.

As part of a whole project, MID Platform Awareness, this paper shows how we can call connectivity awareness methods and get event notifications.

The system was developed on Moblin[4], a Linux* platform, and uses D-Bus communication[1] to transport information to users [1]. Applications which want to get connectivity information need to use D-Bus as well. In the following sections, we briefly describe D-Bus and how we implement network connectivity awareness service using D-Bus. We show examples of how an application can retrieve the network connectivity information; (1)whether or not the device is connecting to a network, (2)whether or not the device can reach a given website, (3)the latency of the network when the device does connect, (4)the data rate involved when the device reaches a website, (5)the media type of the current network, and (6)the link speed of the network.

Background on D-Bus

D-Bus is a fast, lightweight message system which allows applications to communicate one on one or to broadcast messages to subscribers, (inter-process communication). [2]. D-Bus can be used as low-level API or via a higher level binding, such as Qt, Python*, Java*, C#, or Perl. This paper shows an application written in C using Glib bindings. Glib is the base library of GNOME and provides an object-based, event-driven environment.

Two buses are defined in D-Bus: the system bus and the session bus. The system bus allows communication between an application and the operating system while the session bus is designed to allow communication between two applications.

In order to use D-Bus, we need to understand a few basics. First, an object is an endpoint on the bus that is created by an application in the context of that application’s connection to the bus. Objects have names, and these names are called object paths. We can find an object via its path. A proxy allows clients to reference objects on the bus. Once we find an object, we usually keep a proxy to that object so we can subsequently refer to that object without searching again.

An object can perform specific operations, referred to as methods. Thus, a client can send a request to an object and ask the object to invoke a method. The object then executes the method (if the method exists) and the result is sent back to the client. If a method requires input parameters, these parameters are passed with the request. The result can be one or more output parameters, which are sent back to the client in the reply message. At the D-Bus layer, this method invocation/message passing sequence occurs asynchronously; the glib wrapper for the D-Bus object proxy allows the methods to be called either synchronously or asynchronously.

An object can also emit an event, or signal. When a signal is generated by an object, it is broadcasted to any interested observers. Signals can also carry parameters. Methods and Signals are embedded members of an object that can be grouped into an interface. An object can declare one or many interfaces.

In order to generate dbus-glib binding code, we use a tool called dbus-binding-tool. We first create an XML file, referred to as an Introspection XML file, in which we describe the methods and signals. Defining the interface this way ensures that clients can discover and introspect our D-Bus service. An example of the introspection XML is shown below:

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE node PUBLIC 
"-//freedesktop//DTD D-Bus Object Introspection 1.0//EN"
"http://standards.freedesktop.org/dbus/1.0/introspect.dtd">
<node name="/org/moblin/Platform">
  <interface name="org.moblin.Platform.Connection">
       <annotation name="org.freedesktop.DBus.GLib.CSymbol" value="org_moblin_platform_connection"/>
       <method name="IsConnected">
              <annotation name="org.freedesktop.DBus.GLib.CSymbol" value="isConnected"/>
              <arg type="b" name="isConnected" direction="out" />
       </method>
       <method name="IsReachable">
              <annotation name="org.freedesktop.DBus.GLib.CSymbol" value="isReachable"/>
              <arg type="s" name="URI" direction="in" />
              <arg type="b" name="isReachable" direction="out" />
       </method>
       <method name="GetLatency">
              <annotation name="org.freedesktop.DBus.GLib.CSymbol" value="getLatency"/>
              <arg type="s" name="URI" direction="in" />
              <arg type="d" name="seconds" direction="out" />
       </method>
       <method name="GetDataRate">
              <annotation name="org.freedesktop.DBus.GLib.CSymbol" value="getDataRate"/>
              <arg type="s" name="URI" direction="in" />
              <arg type="d" name="KiloBytesPerSecond" direction="out" />
       </method>
       <method name="GetMediaType">
              <annotation name="org.freedesktop.DBus.GLib.CSymbol" value="getMediaType"/>
              <arg type="s" name="mediaType" direction="out" />
       </method>
       <method name="GetLinkSpeed">
              <annotation name="org.freedesktop.DBus.GLib.CSymbol" value="getLinkSpeed"/>
              <arg type="d" name="kpbs" direction="out" />
       </method>
              
       <signal name="Connected" />
       <signal name="Disconnected" />           
   </interface>
</node>

In this introspection XML file, an interface called org.moblin.Platform.Connection defines six methods:
IsConnected, IsReachable, GetLatency, GetDatRate, GetMediaType and GetLinkSpeed. The annotation XML tags tell dbus-binding-tool what the name of the implementing C function should be. For example, IsConnected is the name of the method that will be visible to users over D-Bus. Internally, we need to implement a C function called isConnected. Method parameters and return values are both specified using the arg XML tag. The direction attribute for a parameter is "in"; for return values, the direction attribute is "out". Note that parameters and return values both have name attributes.

The type attribute of the arg XML tag indicates the data type of the parameter or return value. For example, the value "b" in the IsConnected method return value indicates that the method returns a Boolean. The second method, IsReachable, takes a string parameter representing the target URI (Uniform Resource Identifier) and returns a Boolean value. The next two methods, GetLatency and GetDataRate, also take a string parameter representing the URI and return a double representing seconds and kilobytes per second, respectively. The output of GetMediaType is a string. Finally, the output of the last method, GetLinkSpeed, is a Double data type, representing the number of kilobits per second.

Two signals are defined in the introspection XML file. The signal "Connected" is generated when the system changes state from having no connection to having at least one connection. The "Disconnected" signal is generated when the when the system changes state from having at least one connection to having no connections.

Below are primary steps to implement a D-Bus service. For more details, look here.

Run dbus-binding-tool for an introspection XML file to generate dbus-glib binding code
Acquire the D-Bus GObject wrapper
Implement the instance initialization
Implement the methods
Register the object on the D-Bus

To call the methods implemented on a remote object, a client needs to follow the following steps:

Connect to the bus
Create a proxy object
Invoke the methods on the proxy object.

The connectivity awareness service below uses D-Bus as a communication channel to send information to clients regarding network connectivity. Clients can thus use D-Bus to get connectivity information by querying the methods provided by the connectivity service. Client applications can also listen for the signals that the connectivity awareness service generates. The methods and events mentioned in the introspection file are implemented by the connectivity awareness service.

Getting Network Connectivity Information

The connectivity awareness service provides the means to query the following connectivity information on the computer where the service is installed.

Detecting the network connection

A networked application obviously requires an established network connection. Before allocating resources for a network transaction, it is useful to know whether or not the system has an established network connection. Therefore, the network connectivity service provides a method called IsConnected, which returns a Boolean value confirming the status of the network. The network connectivity service checks the status of all network devices on the computer. If at least one network device has an established connection, the Boolean value TRUE is returned. If all network devices on the computer are not running, the Boolean value FALSE is returned. To query the connectivity, the application first must bind to D-Bus service as shown in the following example

#include <dbus/dbus.h>
#include <stdbool.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <dbus/dbus-glib-bindings.h> 
 
#define PLATFORM_SERVICE          "org.moblin.Platform"
#define PLATFORM_PATH                    "/org/moblin/Platform"
#define PLATFORM_CONNECTION_IF    "org.moblin.Platform.Connection"
 
int main(int argc, char** argv)
{
       DBusGConnection* conn;
       GError *error;
       DBusGProxy *platformProxy;
 
       g_type_init();
       error = NULL;
       conn = dbus_g_bus_get(DBUS_BUS_SESSION, &error);
 
       // Create the proxy Platform
       platformProxy = dbus_g_proxy_new_for_name(conn,
              PLATFORM_SERVICE,          // target for the method call
               PLATFORM_PATH,                   // object to call on
               PLATFORM_CONNECTION_IF);  // interface to call on
 
      gboolean result;
 
      if (!dbus_g_proxy_call(platformProxy, "IsConnected", &error, 
                            G_TYPE_INVALID,
                            G_TYPE_BOOLEAN, &result,
                            G_TYPE_INVALID))
      {
              g_printerr("Failed to call remotely: %s\n",
                                error->message);
              g_error_free(error);
      }
      else
              printf ("Remote call successes with returned value: %s\n", result? "TRUE" : "FALSE");
 
       . . . . . . . . . . . . . . . . . . . . . .
       . . . . . . . . . . . . . . . . . . . . . .
       . . . . . . . . . . . . . . . . . . . . . .
 
       return 0;
}

Note that the application invokes the method IsConnected implemented in the connectivity awareness service: no input is required, and the method returns TRUE if the computer is connected to a network.

The back-end implementation of this method basically computes the list of network adapters available, and confirms the connection status if there is at least one network adapter running. The function detecting whether or not a network adapter is running, is shown below

netdev_ret netdev_get_running(netdev_dev *dev, // in 
                     netdev_running *running)     // out
{
       struct ifreq ifr;
       if(_get_ifreq(dev->ifname, SIOCGIFFLAGS, &ifr) != NETDEV_SUCCESS)
       {
              running = RUNNING_UNKNOWN;
              return NETDEV_ERROR;
       }
 
       short flags = ifr.ifr_flags;
       if(flags & IFF_RUNNING)
       {
              *running = RUNNING_RUN;
       }
       else
       {
              *running = RUNNING_STOP;
       }
 
       return NETDEV_SUCCESS;
}

Detecting HTTP reachability

The second method queries the reachability of a specified website. When getting this request, the connectivity service forms a HTTP GET message[5] and sends it to the specified address (web address) at port 80 (the typical port for HTTP protocol). The socket timeout is set to 3 seconds in this implementation: the service will wait for a HTTP response with status 200[5] before disconnecting the socket. This method, IsReachable, requires a string parameter as the target address (web address) and returns a Boolean value confirming whether or not the web address can be reachable within the socket timeout. The format of the valid entry takes the protocol (http in this case) follows it with the URI. Examples of valid inputs are shown below

"http://www.intel.com/", "http://www.google.com/", "http://www.yahoo.com/", etc ...

The third method, GetLatency, computes the time delay between sending a HTTP GET message and receiving the reply. This method takes an input parameter which is the URI of the website and returns a value of type double, representing the time in seconds. If the socket timeout expires, this method returns a null value.

The fourth method, GetDataRate, calculates the data rate when sending a HTTP GET message and receiving the reply. This method takes an input parameter which is the URI of the website and returns a value of type double representing kilobyte per second (kBps). If the socket timeout expires, this method returns a null value. Data rate is computed using the following formula:

(length of HTTP GET sent + length of HTTP reply) / latency

Code referring to these D-Bus methods is shown below.

              int result1;
 
      if (!dbus_g_proxy_call(platformProxy, "IsReachable", &error,
                            G_TYPE_STRING, "http://www.intel.com/",
                            G_TYPE_INVALID,
                            G_TYPE_BOOLEAN, &result1,
                            G_TYPE_INVALID))
      {
              g_printerr("Failed to call remotely: %s\n",
                     error->message);
              g_error_free(error);
      }
       else
                printf ("Remote call successes with returned value: %s\n", result1? "TRUE" : "FALSE");
 
      gdouble result2;
 
      if (!dbus_g_proxy_call(platformProxy, "GetLatency", &error,
                            G_TYPE_STRING, "http://www.intel.com/",
                            G_TYPE_INVALID,
                            G_TYPE_DOUBLE, &result2,
                            G_TYPE_INVALID))
      {
              g_printerr("Failed to call remotely: %s\n",
                     error->message);
              g_error_free(error);
      }
      else
              printf ("Remote call successes with returned value: %6.3f seconds\n", result2);
 
 
      if (!dbus_g_proxy_call(platformProxy, "GetDataRate", &error,
                            G_TYPE_STRING, "http://www.intel.com/",
                            G_TYPE_INVALID,
                            G_TYPE_DOUBLE, &result2,
                            G_TYPE_INVALID))
      {
              g_printerr("Failed to call remotely: %s\n",
                     error->message);
              g_error_free(error);
      }
              else
                     printf ("Remote call successes with returned value: %8.2f KB/sec\n", result2);

The back-end implementation of the above three methods shares a common function: this function parses the input URI and then searches for the URI reachability using HTTP protocol. The parsing function validates the URI and retrieves the target IP address. The reachability function forms a HTTP GET message and sends to the target IP address at port 80. The reachability is confirmed if a HTTP reply message is received within a timeout limit. Readers are encouraged to refer to the source code of the MID Platform Awareness project for the implementation. For illustration, only the reachability function is shown below

bool HTTPIsReachable(
              unsigned int *pTime,       // in msec
              double *pRate,             // in KB/sec
              PURI_INFO pUri)
{
              bool bRet = false;
              unsigned long StartTime, StopTime;
              int dwStatusCode;
              int conn;
              int Len = 0;
       
              if (pTime)
                     *pTime = 0;
 
              if ( pUri->Port == 0 )
                     pUri->Port = HTTPPORT;
 
              StartTime = getTime();
              if (pUri->DestPath)
                        conn = (int)socketClient( pUri->pHostIP, pUri->Port, 0);
 
                if (conn < 0)
              {
                     printf("conn<0\n");
                       goto GracefulExit;
              }
 
              char req[1024];
              sprintf( req, "GET /%s HTTP/1.0\r\nHost: %s\r\n", pUri->FileName, pUri->DestPath);
               strcat( req, "User-Agent: hget/"  LIBHTTP_VERSION "\r\n");
                     strcat( req, "Pragma: no-cache\r\n" );
              strcat( req, "Accept: */*\r\n\r\n" );
              dwStatusCode = HttpRequest(conn, &Len, req);    // in Bytes
              close(conn);
 
              StopTime = getTime();
 
              printf("return code %d\n", dwStatusCode);
              if ( dwStatusCode == 200 || pUri->FileName == 0 )
              {
                     bRet = true;
                     if (pTime)
                     {
                           unsigned int st;
                           st = StopTime - StartTime;                // in msec
                           *pTime = st;
                           *pRate = (double)Len / (double)st;              // in KB/sec
                     }
              }
 
       GracefulExit:
              return bRet;
}

Detecting the media and speed of the network connection

The last two methods, GetMediaType and GetLinkSpeed, return the network media type and the link speed of the network. In the current implementation, only Ethernet and WiFi are supported. The output of GetMediaType is a string (i.e., "802.03", "802.11g"… etc) and the output of GetLinkSpeed is a value of type double, representing the number of kbps (kilobits per second).

      char *result3;
 
      if (!dbus_g_proxy_call(platformProxy, "GetMediaType", &error,
                            G_TYPE_INVALID,
                            G_TYPE_STRING, &result3,
                            G_TYPE_INVALID))
      {
              g_printerr("Failed to call remotely: %s\n",
                     error->message);
              g_error_free(error);
      }
      else
              printf ("Remote call successes with returned value: %s\n", result3);
 
      double result4;
 
      if (!dbus_g_proxy_call(platformProxy, "GetLinkSpeed", &error,
                             G_TYPE_INVALID,
                             G_TYPE_DOUBLE, &result4,
                             G_TYPE_INVALID))
      {
              g_printerr("Failed to call remotely: %s\n",
                     error->message);
              g_error_free(error);
      }
      else
              printf ("Remote call successes with returned value: %10.1f Kbps (kbit per sec)\n", result4);

The back-end implementation of the method GetMediaType is shown below.

char* RetrieveMediaType(void)
{
   netdev_dev netdev_list[MAX_DEVICE];
   int numInterface = 0;
 
   if(netdev_get_devices(netdev_list, &numInterface) == NETDEV_SUCCESS)
   {
       int i;
       netdev_dev *net_devPtr = netdev_list;
 
       for (i=0; i= Frequency802_11a1) && 
                                      (freq <= Frequency802_11a2) && 
                                      (rate <= MaxRate802_11a))
                                         return ("802.11a");
 
                                  if ((freq >= Frequency802_11b1) && 
                                       (freq <= Frequency802_11b2) && 
                                      (rate <= MaxRate802_11b))
                                         return ("802.11b");
                                                       
                                  if ((freq >= Frequency802_11g1) && 
                                      (freq <= Frequency802_11g2) && 
                                      (rate <= MaxRate802_11g))
                                         return ("802.11g");

                                  return ("Unknown");
                                  break;
                           }
                                                       
                           default:
                                  return ("Unknown");
                                  break;
                        }
 
                     }

                     else
                        return ("Unknown");
 
              }
          }
          net_devPtr++;
       }
 
   }
 
   return ("Unknown");
}

The back-end implementation of the method GetLinkSpeed is shown below.

 double RetrieveLinkSpeed(void)   // in bps
{
   netdev_dev netdev_list[MAX_DEVICE];
   int numInterface = 0;
 
   if(netdev_get_devices(netdev_list, &numInterface) == NETDEV_SUCCESS)
   {
       int i;
       netdev_dev *net_devPtr = netdev_list;
 
       for (i=0; i

Readers are encouraged to refer to the source code of the MID Platform Awareness project for more details.

Monitoring Network Connectivity Change

An application can query the network connectivity information by invoking the methods above. However, instead of constantly invoking the method to query the network connectivity status, sometimes it is more practical that an application just subscribe to network events, or signals. The application will be notified whenever the network connectivity changes status. Two network events are defined: Connected and Disconnected. The Connected event is emitted by the network connectivity service when the network suddenly becomes available. Similarly, the Disconnected event is emitted by the network connectivity service when the network suddenly becomes unavailable. The following code shows how to use D-Bus signals for monitoring network connectivity.

       DBusMessage* msg;
       DBusConnection* conn;
       DBusError err;
 
       printf("Listening for signals\n");
 
       // initialise the errors
       dbus_error_init(&err);
   
       // connect to the bus and check for errors
       conn = dbus_bus_get(DBUS_BUS_SESSION, &err);
       if (dbus_error_is_set(&err)) 
       { 
              fprintf(stderr, "Connection Error (%s)\n", err.message);
             dbus_error_free(&err); 
       }
 
       if (NULL == conn) 
              exit(1);
 
       dbus_bus_add_match(conn, "type='signal',interface='org.moblin.Platform.Connection'", &err);
       dbus_connection_flush(conn);
       
       if (dbus_error_is_set(&err)) 
       { 
              fprintf(stderr, "Match Error (%s)\n", err.message);
              exit(1); 
       }
 
       printf("Match rule sent\n");
 
       // loop listening for signals being emmitted
       while (true) 
       {
              // non blocking read of the next available message
             dbus_connection_read_write(conn, 0);
              msg = dbus_connection_pop_message(conn);
 
             // loop again if we haven't read a message
              if (NULL == msg) 
              { 
                     sleep(1);
                     continue;
              }
 
              if (dbus_message_is_signal(msg, PLATFORM_CONNECTION_IF, CONN_CONNECTED_SIGNAL)) 
                     printf("Received signal %s\n", CONN_CONNECTED_SIGNAL);
 
              if (dbus_message_is_signal(msg, PLATFORM_CONNECTION_IF, CONN_DISCONNECTED_SIGNAL)) 
                     printf("Received signal %s\n", CONN_DISCONNECTED_SIGNAL);
 
              // free the message
              dbus_message_unref(msg);
       }

Conclusion

D-Bus is a lightweight Remote Procedure Call (RPC) which is suitable for many applications running on a desktop. Because D-Bus is simple and relative small, yet powerful, we can adapt this technology for Mobile Internet Devices (MID). In this paper, we introduced a platform service for MID using D-Bus technology. We briefly described the six connectivity-related methods and two signals provided by the MIDPlatformSvc.

Although this implementation has been tested on the Moblin stack, this technology should also work on a Windows platform as well: therefore, with minimum change, this application should work on other form factors like UMPC, which run Windows* instead.

References

[1] D-Bus, http://www.freedesktop.org/wiki/Software/dbus
[2] D-Bus Tutorial, http://dbus.freedesktop.org/doc/dbus-tutorial.html
[3] http://www.moblin.org/toolkits/basicDevGuides/mobLinux/toolkits_DevGds_mobLinux_createDBUS.php
[4] Mobile and Internet Linux Project, http://moblin.org/
[5] RFC 1945 "Hypertext Transfer Protocol – HTTP/1.0"

Determining Input Devices in Linux*

Wed, 22 Apr 2009 16:13:14 -0700

Preface

The Intel Mobile Internet Device (MID) platform provides a full internet experience in a pocket-sized form factor. Combining Moblin-based operating systems with the Intel® Atom™ processor, MIDs are able to run any application that has been built for the x86 architecture, including Adobe* Flash 10 and Adobe* AIR 1.5. While the features of the devices that are and will be on the market vary depending on OEM and target market, there are several features that the devices share in common: small form factor, emphasis on internet connectivity rather than extensive storage, and alternate input methods.

Although there are ultra-mobile computing devices in the market that run Microsoft Windows* XP or Windows Vista and that are built on the same hardware platform as those running a Moblin-based operating systems such as Midinux* or Ubuntu* Mobile Edition, this series of whitepapers focuses entirely on the Moblin-based MIDs. For information on how to retrieve this information from Windows operating systems, please consult that platform’s documentation, or see the Intel Mobile Platform SDK.

The functionality described in this paper is also provided via the Platform Awareness Service, a light-weight, D-Bus initiated platform information provider. However, because the final software stack for each Moblin device is influenced heavily by the OEM and Service Providers, this service may not be pre-installed on some Moblin-based devices. We have therefore written these whitepapers in order to simplify access to this information on platforms that do not have this service installed.

For further information on how to use D-Bus to retrieve information from the Platform Awareness Service, please refer to the Platform Awareness Service documentation.

Introduction

One of the more distinguishing differences between a desktop machine and a mobile device is the way in which data can be input. Most desktop machines are equipped with a keyboard, a mouse, and perhaps other input devices. For a mobile device the choices are not always as obvious, and at times are not even available. The user of these machines, however, expects to be able to input information into the machine, and the software used must be aware of the options for input that are available on the system.

The purpose of this paper is to demonstrate one way of retrieving input device information from Moblin-based Linux platforms.

How to get Input Device Information in Linux

While there is a fair amount of information available, we focus on three main pieces of information in order to keep things small and simple:

The existence of a physical keyboard
The existence of a physical pointing device
Whether the existence of either device changes

Using HAL

The Linux Hardware Abstraction Layer (HAL>) can retrieve information about the hardware that makes up a computer system. HAL can be queried through the command line using commands like hal-device, hal-find-by-property, hal-find-by-capability, and hal-get-property . One can get the same information inside of an application by using D-BUS. The HAL 0.5.10 Specification lists information that is available through HAL. Therefore, for our purposes here, we will illustrate the use of the D-BUS interface to query the HAL and locate the available input devices, and once located determine which input device is relevant to a particular query. This is done by means of the FindDeviceByCapability directive to return a list of devices that have various input capabilities, namely keyboard and mouse. We will also illustrate a method for detecting when input devices are added or removed.

Creating the List of Input Devices

In order to obtain a list of input devices, two functions are used to query the HAL for available devices. isPhysicalKeyboardPresent() collects information about the keyboards that are connected to the system. isPhysicalPointerPresent() collects information about the mouse devices that are connected to the system. Each function has the same parameters:

MIDPlatformSvc *obj – Contains a pointer to the system bus through which the HAL is queried
gboolean *Present – Returns TRUE if the device is present, FALSE if no device is present
GError **error – Used to report the absence of the device being queried

Each function performs basically the same algorithm: connect to the HAL and request a list of devices using the FindDeviceByCapability directive to look for input.keyboard and input.mouse capability, and then, if appropriate, add the device to the collection of available input devices. The list returned by this query to the HAL is a collection of User Interface Devices (UDI) that each have the capability requested. Each UDI in this list is then examined to ensure that only the appropriate set of capabilities is present in the device, meaning that keyboards do not also have mouse capability, and that mouse devices do not also have keyboard or keys capability. This is done by again calling the HAL to determine if the opposite capability is also present in the UDI. When it is determined that only the desired capability is present in the UDI, a call to adjustinputdevicenames() is then made to track the particular UDI along with its discovered capability. Details of this function are located below. Once the device list has been created, it is used to track devices as they are connected or disconnected from the system.

A listing of isPhysicalKeyboardPresent() is now presented:

gboolean isPhysicalKeyboardPresent(MIDPlatformSvc *obj, gboolean *keyboardPresent, GError **error)
{
       DBusGConnection *sysBus;
       DBusGProxy *proxy;
       char **kbdList = NULL,**mouseList = NULL;
       char **kbd_ptr,**mouse_ptr,**mousename;
       int i = 0,len = 0;
       
       // Initialize the System DBus connection
       sysBus = obj->systemBus;
 
       // Connect a proxy to the Hal Manager interface 
       proxy = dbus_g_proxy_new_for_name(sysBus,"org.freedesktop.Hal",
                           "/org/freedesktop/Hal/Manager","org.freedesktop.Hal.Manager" );
 
       dbus_g_proxy_call(proxy, "FindDeviceByCapability", error,     //Find Keyboard via HAL
                     G_TYPE_STRING, "input.keyboard", G_TYPE_INVALID,              // param #1
                     G_TYPE_STRV, &kbdList, G_TYPE_INVALID);                // ret val
       
       if (kbdList)
              len = g_strv_length(kbdList);
       if (len == 0) {                   // no keyboard found
              *keyboardPresent = FALSE;         // Function Fail
              g_set_error (error,                             // set an error
                          INPUT_DEVICE_NP,                           // error domain
                          1,                                  // error code
                          "No Keyboard devices were found.\n");      // error message
              return TRUE;
       }
       gboolean haskbd = FALSE,hasmouse;
       for (kbd_ptr = kbdList; *kbd_ptr; kbd_ptr++,i++)       // iterate through the list of
       {                    // keyboard devices, checking each udi to for mouse capability
              hasmouse = FALSE;
              DBusGProxy *kbdProxy = dbus_g_proxy_new_for_name(sysBus,      //Open proxy for
              "org.freedesktop.Hal",*kbd_ptr,"org.freedesktop.Hal.Device" );//Keyboard UDI
              dbus_g_proxy_call(kbdProxy, "GetPropertyStringList", error,   // Checking caps                                
			  G_TYPE_STRING, "info.capabilities", G_TYPE_INVALID,
                                  G_TYPE_STRV, &mouseList, G_TYPE_INVALID);
              len = g_strv_length(mouseList);
              for (mouse_ptr = mouseList;*mouse_ptr && !hasmouse;mouse_ptr++)
              {
                     if (!strcmp(*mouse_ptr,"input.mouse"))
                           hasmouse = TRUE;
              }
              if (!hasmouse)
              {
                     haskbd = TRUE;
                     adjustinputdevicenames(obj,*kbd_ptr,ADDIT,KEYBOARD);
              }
              if (len)
                     g_strfreev(mouseList);
              g_object_unref (kbdProxy);
      }
       g_strfreev(kbdList);
       g_object_unref (proxy);
       
       *keyboardPresent = haskbd;
       return TRUE;
}

An additional check is made when working with mouse devices. It has been determined that a mouse emulation UDI is sent by DBUS when a keyboard is connected to or disconnected from the system. It does have input.mouse capabilities only, but, as an emulation, is not connected to a physical device. Thus, when searching mouse devices for keys or keyboard capabilities, an additional call to the HAL is made using the GetPropertyString directive to discover the info.product elements of the UDI. If the property name is not “Macintosh mouse button emulation”, then we proceed with checking to see if keys or keyboard capabilities are also present in the UDI. A listing of isPhysicalPointerPresent() is now presented:

gboolean isPhysicalPointerPresent(MIDPlatformSvc *obj, gboolean *pointerPresent, GError **error)
{
       DBusGConnection *sysBus;
       DBusGProxy *proxy;
       char **kbdList = NULL,**mouseList = NULL;
       char **mouse_ptr,**kbd_ptr,*mouseproduct;
       int i = 0,len = 0;
       
       // Initialize the System DBus connection
       sysBus = obj->systemBus;
 
       // Connect a proxy to the Hal Manager interface 
       proxy = dbus_g_proxy_new_for_name(sysBus,"org.freedesktop.Hal",
                     "/org/freedesktop/Hal/Manager","org.freedesktop.Hal.Manager" );
 
       dbus_g_proxy_call(proxy, "FindDeviceByCapability", error,            //Find Mouse via HAL
                     G_TYPE_STRING, "input.mouse", G_TYPE_INVALID,          // param #1
                     G_TYPE_STRV, &mouseList, G_TYPE_INVALID);                     // ret val
 
       if (mouseList)
              len = g_strv_length(mouseList);
       if (len == 0) {                   // no keyboard found
              *pointerPresent = FALSE;          // Function fails
              g_set_error (error,                             // set an error
                          INPUT_DEVICE_NP,                           // error domain
                          1,                                  // error code
                          "No Mouse devices were found.\n");  // error message
              return TRUE;
       }
       gboolean hasmouse = FALSE,haskeyboard;   // No solely mouse capability is assumed
 
       for (i=0,mouse_ptr = mouseList; *mouse_ptr && !hasmouse; mouse_ptr++,i++)
       // iterate through the list of mouse devices, checking each udi for keyboard capability
       {
              haskeyboard = FALSE;
              DBusGProxy *mouseProxy = dbus_g_proxy_new_for_name(sysBus,"org.freedesktop.Hal",
                     *mouse_ptr,"org.freedesktop.Hal.Device" );      //Open Proxy for Mouse UDI
              dbus_g_proxy_call(mouseProxy, "GetPropertyString", error,     // Checking caps. 
                                  G_TYPE_STRING, "info.product", G_TYPE_INVALID,                                            
								  G_TYPE_STRING, &mouseproduct, G_TYPE_INVALID);
              if (strcmp(mouseproduct,"Macintosh mouse button emulation"))  // if mouse
              {      // device is not Macintosh mouse button emulation continue
                     dbus_g_proxy_call(mouseProxy, "GetPropertyStringList", error,                                                
					 G_TYPE_STRING, "info.capabilities", G_TYPE_INVALID,                                      
					 G_TYPE_STRV, &kbdList, G_TYPE_INVALID);
                     len = g_strv_length(kbdList);
                     for (kbd_ptr = kbdList; *kbd_ptr && !haskeyboard; kbd_ptr++) //check to
                     {      // see if device has any "Keyboard" capability as well; if so,
                           // device is not solely a mouse device
                           if (!strncmp(*kbd_ptr,"input.key",9))      //check for input.key*, 
                                  // if any exist we have keyboard capability, not just mouse
                                  haskeyboard = TRUE;
                     }
                     if (!haskeyboard)    //set mouse capability with respect to keyboard:
                                         // if no keyboard we have mouse; if keyboard we 
                     {                    // don't have mouse only
                           hasmouse = TRUE;
                           adjustinputdevicenames(obj,*mouse_ptr,ADDIT,MOUSE);
                     }
                     if (len)
                           g_strfreev(kbdList);       //free elements as appropriate
              }
              free(mouseproduct);
              g_object_unref (mouseProxy);                                  //free proxy
       }
       g_strfreev (mouseList);
       g_object_unref (proxy);
       *pointerPresent = hasmouse;
       return TRUE;
}

Collecting the Available Input Devices

As information regarding the input devices is discovered, and as it can change any time a device is connected to or disconnected from the system, a method for tracking available devices becomes necessary. Each UDI has a unique name and is generally connected to a unique function, in our case either for mouse support or keyboard support. The function adjustinputdevicesnames() was written to track these changes as they occur. The parameters are as follows:

MIDPlatformSvc *obj – Contains a pointer to the system bus used when advising users of changes in the availability of devices
char *name – Contains the name of the UDI being tracked
int action – Indicates to the function the operation to perform. Options here are ADDIT, REMOVEIT, CLEANUP, INITIALIZE, NOACTION
int role – Indicates the role of this particular UDI. Options here are KEYBOARD or MOUSE.

The purpose of this function is to collect and track the information regarding the various UDI’s that are discovered by the system, and to track when changes dictate that an advisory should be sent to interested parties regarding the state of input devices on the system. In tracking the UDI’s, once they are entered in the list of devices, the name remains in the list. This is because each device is assigned the same name, and when disconnected or connected will be the same as the previous use. A listing of adjustinputdevicename() and associated data is now presented:

#define ADDIT              1
#define REMOVEIT           2
#define CLEANUP            3
#define KEYBOARD           4
#define MOUSE              5
#define NOACTION           6
#define INITIALIZE         7
 
#define TBLSIZE            20
 
typedef struct 
{      char *name;
       int active;
       int role;
} DEVICE_INFO;
 
static void adjustinputdevicenames(MIDPlatformSvc *obj,char *name,int action,int role)
{
       static DEVICE_INFO inpdevs[TBLSIZE];     // static variables will keep state
       int i;
       static int devcount = 0,mousecount = 0, keyboardcount = 0;
       static gboolean firstpass = TRUE;
       gboolean present = FALSE;
 
       if (action == ADDIT) // operation is to add UDI to tracking mechanism
       {
              gboolean adjcount = FALSE;

             for (i = 0; i < devcount && !present; i++)
                    if (!strcmp(name,inpdevs[i].name) && inpdevs[i].role == role)
                     {  // check to see if UDI name and role already exist and is yes
                           adjcount = !inpdevs[i].active; // determine previous state
                           inpdevs[i].active = TRUE;  // set as active
                           present = TRUE;            // set as present
                     }
              if (!present)        // UDI is not present so it is added
              {
                     inpdevs[devcount].name = strdup(name);   // keep UDI name
                     inpdevs[devcount].active = TRUE;         // set as active
                     inpdevs[devcount].role = role;           // store its role
                     devcount++;                       // increase device count
                     adjcount = TRUE;                  // indicate adjustment necessary
              }
              if (adjcount)
              {      //if adjustments are necessary, make them based on role of UDI
                     if (role == KEYBOARD)
                     {      // if keyboard has not been present and now is then
                           if (!firstpass && !keyboardcount) // alert users of change
                                  keyboardPresentChanged(obj,TRUE,NULL);
                           keyboardcount++;     // adjust keyboard count
                     }
                     else if (role == MOUSE)
                     {      // if mouse has not been present and now is then
                           if (!firstpass && !mousecount)    // alert users of change
                                  pointerPresentChanged(obj,TRUE,NULL);
                           mousecount++;        // adjust mouse count
                     }
                     firstpass = FALSE;   // set controlling variable to FALSE
              }
       }
       else if (action == REMOVEIT)      // operation is to remove UDI as active
       {
              for (i = 0; i < devcount; i++)    // for each UDI that is tracked
              {      // if UDI is being queried and is active
                     if (!strcmp(name,inpdevs[i].name) && inpdevs[i].active)
                     {      
                           inpdevs[i].active = FALSE; // set as inactive
                           if (inpdevs[i].role == KEYBOARD)
                           {      // if role is keyboard decrement refence count
                                  keyboardcount--;     // and if now no keyboards are
                                  if (!firstpass && keyboardcount < 1) // present
                                         keyboardPresentChanged(obj,FALSE,NULL);
                           }             // alert users of change
                           else if (inpdevs[i].role == MOUSE)
                           {      // if role is mouse, decrement reference count
                                  mousecount--;        // and is now no mouse is present
                                  if (!firstpass && mousecount < 1) // alert users
                                         pointerPresentChanged(obj,FALSE,NULL);
                           }             //of change
                     }
              }
              firstpass = FALSE;
       }
       else if (action == CLEANUP) // operation is to cleanup information
       {
              for (i = 0; i < devcount; i++)
              {
                     free(inpdevs[i].name);     // release memory allocated for name
                     inpdevs[i].name = NULL;
                     inpdevs[i].active = FALSE; // set active and role to zero state
                     inpdevs[i].role = 0;
              }
              devcount = 0;        // set counters all to zero
              keyboardcount = 0;
              mousecount = 0;

             firstpass = TRUE;    // set to initial state
       }
       else if (action == INITIALIZE && firstpass)     // operation is to initialize
       {
              for (i = 0; i < TBLSIZE; i++)
              {
                     inpdevs[i].name = NULL;           // set a known state for all
                     inpdevs[i].active = FALSE;        // elements
                     inpdevs[i].role = 0;
              }
       }
}

Tracking Changes in Available Input Devices

Input devices can change at almost any time. The DBUS provides signaling capabilities are sent when a connection or disconnection of a device occurs on the system. We have taken advantage of this capability to monitor the changes to input devices by subscribing to the DeviceAdded and DeviceRemoved signals. This method provides a mechanism whereby a callback function can be specified to handle these two signals. The function beginInputEventThread(), which is invoked by the Mobile Internet Device platform architecture to initialize the input events, is the function in which we provide hooks into the signaling system to be able to monitor changes to input events. Its parameter is a MIDPlatformSvc object containing system bus information used throughout the input device module. A listing of this function is now presented:

void beginInputEventThread(MIDPlatformSvc *obj)
{
       DBusGConnection *sysBus = obj->systemBus;       // Initialize the System DBus connection
       DBusGProxy *proxy;
       gboolean kpresent,mpresent;
       GError *error = NULL;
 
       adjustinputdevicenames(obj,NULL,INITIALIZE,NOACTION);  //initialize keyboard/mouse data
       isPhysicalPointerPresent(obj,&mpresent,&error); //Make first check of mouse
       isPhysicalKeyboardPresent(obj,&kpresent,&error);       //Make first check of keyboards
       // Connect a proxy to the Hal Manager interface 
       proxy =  dbus_g_proxy_new_for_name(sysBus,             // Retrieve proxy to HAL manager
              "org.freedesktop.Hal",
              "/org/freedesktop/Hal/Manager",
              "org.freedesktop.Hal.Manager" );
       dbus_g_proxy_add_signal(proxy,"DeviceAdded",G_TYPE_STRING,G_TYPE_INVALID);
       dbus_g_proxy_connect_signal(proxy,"DeviceAdded",G_CALLBACK(checkAddedDevice),
(void *)obj,NULL);   // add and connect to DeviceAdded signal 
                                                // with callbackfunction checkAddedDevice()
       dbus_g_proxy_add_signal(proxy,"DeviceRemoved",G_TYPE_STRING,G_TYPE_INVALID);
       dbus_g_proxy_connect_signal(proxy,"DeviceRemoved",G_CALLBACK(checkRemovedDevice),
                           (void *)obj,NULL);   // add and connect to DeviceRemoved signal      
						   return;	 // with callback function checkRemovedDevice
}

As noted in the function above, two functions, checkAddedDevice() and checkRemoveDevice() are denoted as the callback functions that are called when the aforementioned signals are sent. They will make calls to appropriate functions that will monitor and track the changes to devices as they occur. The callback checkRemovedDevice() function makes use of adjustinputdevicenames() that we have already discussed. Its parameters are:

DBusGProxy *proxy – a DBus proxy pointer stored when the callback function was declared and registered with the connect signal call
gchar* device_udi – the name of the UDI which has been removed
gpointer userData – a pointer to user defined data associated with the connect signal call

A listing of this function is now presented:

void checkRemovedDevice(DBusGProxy *proxy, gchar *device_udi, gpointer userData)
{
       adjustinputdevicenames((MIDPlatformSvc *)userData,device_udi,REMOVEIT,NOACTION);
       return;
}

It should be noted that the call to adjustinputdevicenames() in this function denotes that we are removing a device from active service in our data elements.

The callback checkAddedDevice() function makes use of the function examineUDI(), which is discussed below. Its parameters are:

DBusGProxy *proxy – a DBus proxy pointer stored when the callback function was declared and registered with the connect signal call
gchar* device_udi – the name of the UDI which has been removed
gpointer userData – a pointer to user defined data associated with the connect signal call

A listing of this function is now presented:

void checkAddedDevice(DBusGProxy *proxy, gchar *device_udi, gpointer userData)
{
       examineUDI(proxy,device_udi,(MIDPlatformSvc *)userData);
       return;
}

Identifying an added input device requires a slightly different approach than removing an input device. Since a device added to the system could belong to a variety of functionality, a means to determine if the device added is an input device had to be created. As we are only interested in input devices, the function examineUDI() is used to make this determination. This function uses the HAL to determine the capability of the device being examined, and only adds a device if it has keyboard or mouse capability. The parameters are:

DBusGProxy *proxy – a DBus proxy pointer stored when the callback function was declared and registered with the connect signal call
gchar* device_udi – the name of the UDI which has been removed
MIDPlatformSvc *obj – a pointer to user defined data associated with the connect signal call

This function, after determining that the added device is an input device, makes use of adjustinputdevicenames() to track the new device. A listing of this function is now presented:

static void examineUDI (DBusGProxy *proxy, gchar *device_udi,MIDPlatformSvc *obj)
{
       char **devicecaps = NULL,**list1 = NULL,**list2 = NULL;
       GError **error = NULL;
       int len = -1;
 
       DBusGProxy *capProxy = dbus_g_proxy_new_for_name(obj->systemBus,
                           "org.freedesktop.Hal",device_udi,
                           "org.freedesktop.Hal.Device");    //Open Proxy for supplied UDI
       dbus_g_proxy_call(capProxy,"GetPropertyStringList",    // Checking for device capability
                           error,G_TYPE_STRING, "info.capabilities", G_TYPE_INVALID,
                           G_TYPE_STRV, &devicecaps, G_TYPE_INVALID);
       if (devicecaps)
       {
              len = g_strv_length(devicecaps);
              for (list1 = devicecaps;*list1;list1++)  
              {
                     if (!strncmp(*list1,"input.key",9))      // Is any key type capability present
                     {
                           gboolean haskbd = FALSE;
                           list2 = list1;       // check remaining through second pointer
                           for (;*list2 && !haskbd;list2++)  // check for keyboard
                                  if (!strcmp(*list2,"input.keyboard"))
                                         haskbd = TRUE;
                           if (haskbd)   // if there is a keyboard make sure mouse is missing
                           {
                                  gboolean hasmouse = FALSE; 
                                  list1++;//begin mouse search one beyond where key was found
                                  if (list1)
                                         for (;*list1 && !hasmouse;list1++)
                                                if (!strcmp(*list1,"input.mouse"))
                                                       hasmouse = TRUE;
                                  if (!hasmouse)       // if no mouse present add UDI to kbd list
                                         adjustinputdevicenames(obj,device_udi,ADDIT,
                                                               KEYBOARD);
                           }
                           break; //end for loop search
                     }
                     else if (!strcmp(*list1,"input.mouse")) // is mouse the capability
                     {
                           gboolean haskey = FALSE;
                           list1++;
                           if (list1)    // make sure not “key” capability is present
                                  for (;*list1 && !haskey;list1++)
                                         if (!strncmp(*list1,"input.key",9))
                                                haskey = TRUE;
                           if (!haskey)  // if no key, then add UDI to mouse list
                                  adjustinputdevicenames(obj,device_udi,ADDIT,MOUSE);
                           break;        //end 'for' loop search
                     }
              }
       }
       g_object_unref (capProxy);
}

Notification of Changes in Available Input Devices

As mentioned above, when changes in input devices occurs the user is notified of these changes through an alert through the DBUS signaling service. These alerts are made via the functions keyboardPresentChanged() and pointerPresentChanged. Both functions have identical parameters:

MIDPlatformSvc *obj – Contains a pointer to the system bus to which the alert is issued
Gboolean isPresent – indicates the current data of the devices
GError *error = an error reporting element

Both functions operate the same way by calling g_signal_emit() to pass the specific alert defined for each function. The listing of both functions is now presented:

gboolean keyboardPresentChanged(MIDPlatformSvc*obj, gboolean isPresent, GError *error)
{
       if (error == NULL) //GQuark stuff #define SIG_PHYSICAL_KEYBOARD_PRESENT_ID
       {      //"physical_keyboard_present_changed": whether the physical keyboard is present
              g_signal_emit(obj,g_inputSignals[SIG_PHYSICAL_KEYBOARD_PRESENT_ID].signalId,
                           0,isPresent); 
       }
       return TRUE;
}

gboolean pointerPresentChanged(MIDPlatformSvc*obj, gboolean isPresent, GError *error)
{
       if (error == NULL)          //GQuark stuff #define SIG_PHYSICAL_POINTER_PRESENT_ID
       {      //"physical_mouse_present_changed": whether the physical mouse is present
              g_signal_emit(obj,g_inputSignals[SIG_PHYSICAL_POINTER_PRESENT_ID].signalId,
                           0,isPresent);
       }
       return TRUE;
}

Cleaning Up Information Regarding Available Input Devices

As must always occur, we must be careful to cleanup the memory and other resources we have used during the process of tracking input devices. The Intel® Mobile Internet Device platform provides a mechanism for all components to release all resources used during the process of managing the device. For input devices, this is done through a call tofinalizeInputObject(). Its one parameter, MIDPlatformSvc *obj, contains the system bus information we have used through out. A list of the function is now presented:

void finalizeInputObject(MIDPlatformSvc *obj)
{
       DBusGConnection *sysBus = obj->systemBus;       // Initialize the System DBus connection
       DBusGProxy *proxy;
       gboolean present;
       GError *error = NULL;
       
       adjustinputdevicenames(obj,NULL,CLEANUP,NOACTION);     //cleanup the tracking table
       // Connect a proxy to the Hal Manager interface 
       proxy = dbus_g_proxy_new_for_name(sysBus,"org.freedesktop.Hal",
                           "/org/freedesktop/Hal/Manager","org.freedesktop.Hal.Manager" );
       dbus_g_proxy_disconnect_signal(proxy,"DeviceAdded",G_CALLBACK(checkAddedDevice),
                                  (void *)obj); // disconnect from DeviceAdded signal
       dbus_g_proxy_disconnect_signal(proxy,"DeviceRemoved",G_CALLBACK(checkRemovedDevice),
                                  (void *)obj); // disconnect from DeviceRemoved signal
       return;
}

Unsupported Input Devices

There are two input devices that are current not supported to the extent of keyboards and the mouse. They are the TouchScreen and the On-Screen keyboard. There are hooks in the input code that returns a fixed state for these devices, but any changes to them is not reported at this time. Future revisions will surely have support for these devices if support in the OS can be found. A listing of the three functions that returned a fixed state is now presented:

gboolean isTouchScreen(MIDPlatformSvc *obj, gboolean *isTouchScreen, GError **error)
{
       *isTouchScreen = TRUE;
       return TRUE;
}
 
gboolean isOnScreenKeyboardVisible(MIDPlatformSvc *obj, gboolean *visible, GError **error)
{
       *visible = FALSE;
       return TRUE;
}
 
gboolean onScreenKeyboardChanged(MIDPlatformSvc* obj)
{
       gboolean visible;
       GError* error = NULL;
       dbg("Simulating a OnScreenKeyboardChanged Event.");
       isOnScreenKeyboardVisible(obj, &visible, &error);
       if (error == NULL)
       {
              g_signal_emit (      obj, 
                                         g_inputSignals[SIG_ON_SCREEN_KEYBOARD_CHANGED_ID].signalId , 
                           0, //GQuark stuff
                                  //the parameters; in this case, whether or not the
                                  //keyboard is visible
                                         );
       }//GQuark stuff #define SIG_PHYSICAL_KEYBOARD_PRESENT_ID      "on_screen_keyboard_changed"
       return TRUE;
}

Writing Input Device Aware Applications

The ability to determine input devices is very important to an application. When events occur that change that ability, it is important that the application is aware of these changes. Hopefully this paper covered enough detail to get you started on writing your own input device aware applications for Linux.

How to Obtain Location Information in Linux

Wed, 22 Apr 2009 16:12:12 -0700

Preface

Introduction

One of the features of the Intel® MID platform is its support for GPS-based location awareness. While an OEM of Service Provider makes the decision about whether to include a GPS device in their MID, the ability to provide location-based services (LBS)—including context specific advertising and Point of Interaction sales—is compelling.

In addition to GPS data, there are several other ways to compute the location of a device, including IP address provider mapping, cell tower triangulation, Wifi access point proximity, etc. This paper focuses exclusively on retrieving data from the GPS device.

How to get Location Information in Linux

GPS information is not easily accessible in Linux, but it is available. Some GPS devices can connect via Bluetooth, but most will be connected via a USB or serial port. Finding out which port the device is mapped to can be rather difficult. For help on setting up a Bluetooth device, try http://gpsd.berlios.de/bt.html. Linux’s HAL (Hardware Abstraction Layer) might be useful for finding a device connected by USB or serial. You can use HAL to find out which serial devices the system recognizes, and where to access them:

hal-find-by-capability --capability serial

HAL will return a device name for each serial device that if finds (for example: /org/freedesktop/Hal/devices/usb_device_1546_1a4_noserial1_if0_serial_unknown_0). From here you can find the path to access the device:

hal-get-property 
--udi /org/freedesktop/Hal/devices/usb_device_1546_1a4_noserial_if0_serial_unknown_0 
--key serial.device

This will generally map to a /dev/tty* location. You can listen to the serial device directly. For example, a GPS device connected to /dev/ttyACM0 can be seen by doing the following:

cat /dev/ttyACM0

In most cases, you’ll see rather cryptic NMEA 0183 sentences that are hard to understand. See example NMEA sentances below:

$GPTPV,2005-02-11T04:40:51.231Z,?,4916.45N,123.12W,2.3,70.1,52.0,01.0,02.1,23.1,0.6,,,8,A
$GPSVU,2005-02-11T04:40:51.231Z,11,03,03,111,00,04,15,270,00,06,01,010,00,13,06,292,00,14,25,170,00,16,57,208,39!,18,67,296,40!,19,40,246,00,22,42,067,42,24,14,311,43!,27,05,244,00

This data can be parsed and translated into geographic data.

Using gpsd

gpsd is a service daemon that can listen to a USB, serial, or Bluetooth GPS device and provide the user with meaningful location information. For more detailed information, visit http://gpsd.berlios.de/.

gpsd will connect to the GPS device and parse the device’s data into location coordinates, so you don’t have to do it manually. This takes away all of the hassle of having to translate the NMEA 0183 sentences that were shown above. gpsd also allows multiple GPS clients to have access to the GPS data at the same time. If you design your application to grab the data directly from the serial port, other applications will not be able to access the GPS data.

For these reasons, the Platform Awareness Service has been implemented to use gpsd for its location-based information.

Install and Launch gpsd

You can download gpsd for Linux directly from the website listed above or install it directly from your favorite package manager repository.

Once gpsd is installed, it must be run with a parameter indicating the location of the GPS device. In this case the path was /dev/ttyUSB0. For debugging purposes, it may be good to initially include the following optional flags:

gpsd -n -N -D 2 /dev/ttyUSB0

-n: begin polling the GPS device immediately; otherwise it will wait for a client to connect before it polls the GPS
-N: don’t daemonize; run in foreground; good for debugging
-D 2: set the debug level of information

Note: gpsd can be set to run as a daemon and can also be configured to launch upon startup of the device.

Getting Location data from gpsd

There are a couple of ways to get location data from gpsd.

1. Libgps

Libgps is an interface library (in C) that manages communication with the daemon. There’s also libgpsmm, a C++ wrappper for libgps. The libgps documentation is available at http://gpsd.berlios.de/libgps.html.

Libgps gives you the freedom to poll gpsd as often or as infrequent as you’d like. You can also create a callback method that is called anytime the GPS information is updated (like a signal).

2. D-Bus

Listening for a D-Bus signal coming from gpsd can get you this same information. In version 2.37 of gpsd, there are only two implemented D-Bus calls that an application can use. You can call initialize_dbus_connection(), then you can listen for a send_dbus_fix() signal, which includes all of the GPS’s data in a giant struct.

Using Libgps

A client application may choose to listen for D-Bus messages that come from gpsd, or it may use the libgps interface library to communicate with gpsd. The Platform Awareness Service uses libgps’s polling method to get location information. This allows clients to determine how often they want location updates.

To connect to gpsd, you must use the gps_open() function to connect to port 2947 of the host computer. Then the gps_set_raw_hook() method allows you to define a function to be executed each time a gps_query / gps_poll command is run.

#include 
 
gboolean isConn2GPSD = FALSE;
struct gps_data_t *gpsdata = 0;
 
void connectToGPSD() {
    if (gpsdata == NULL) {
    // ran for first time: initialization
        char* server = "localhost";
        char* port = "2947";     // default port
 
        gpsdata = gps_open(server, port);
 
        if (gpsdata != NULL) {
            isConn2GPSD = TRUE;
            gps_set_raw_hook(gpsdata, (void *)updateGPSdata_cb);
    }
}

updateGPSdata_cb is the function that is executed anytime I poll gpsd. myGPSdata stores the location data that I’m interested in.

struct GPSdata {
    double latitude;
    double longitude;
    double altitude;
} myGPSdata;
 
void *updateGPSdata_cb() {
    if (gpsdata->fix.mode > 1) {
        // if there's a fix
        myGPSdata.latitude = gpsdata->fix.latitude;
        myGPSdata.longitude = gpsdata->fix.longitude;
        myGPSdata.altitude = gpsdata->fix.altitude;
    }
}

The gpsdata struct that is populated by gpsd carries more than just latitude, longitude, and altitude information. The only place I could find a description of this struct was inside the source code of gpsd.

With this code in place, an application is free to poll gpsd for location information at its own leisure. It only needs to call the gps_query / gps_poll methods that are available from libgps.

Writing Location-Aware Applications

In a world where more and more computational power is going into handheld devices, location-based software is being developed at a rapid rate. Hopefully this paper covered enough detail to get you started on writing your own location-aware applications for Linux.

Developing Power Aware Applications Using D-Bus

Wed, 22 Apr 2009 16:11:33 -0700

Introduction

Computer power consumption has become a passionate subject; hardware engineers trying to minimize the power consumed by devices, and software engineers trying to optimize their code to reduce the power consumed by their applications. Power is an even more important issue with Mobile Internet Devices (MIDs) since the small form factor limits the size of the battery. Applications running on MID's must therefore be very sensitive to power, and use power information to make smart decisions. For example, before beginning a lengthy transaction (such as downloading a video, or running an update), an application should check to see if the device is running on external power, and if not, determine whether or not there is sufficient power remaining to complete the transaction.

Background on D-Bus

D-Bus is a fast, lightweight message bus system which allows applications to communicate each other (Inter-process communication) [2]. It has a so-called D-Bus message bus (dbus deamon) which can accept messages from multiples applications and forward messages to them. D-Bus can be used as low-level API or higher level binding, such as Qt, Python*, Java*, C#, or Perl. This paper shows an application written in C using Glib bindings. Glib is the base library of GNOME, it provides an object system, object-based and event-driven programming.

Two buses are defined in D-Bus: system bus and session bus. The system bus allows communication between an application and the operating system while the session bus is designed to serve the communication between two applications.

In order to use D-Bus, we need to explore some concepts about D-Bus. First, an object is an endpoint on the bus, an object is created by an application in the context that the application's connection to the bus (either system bus or session bus). Objects have names, and these names are called object paths. A proxy is an object on the bus that can be accessed through references. We can find an object by searching the bus name and the object living in that bus connection. Once we find it, we usually keep a proxy to that object so we can refer to that object again without searching again.

An object can perform some specific operations. Each operation is referred as method. Thus, a client can send a request to an object and ask the object to invoke a method. The object then executes the method (if the method exists) and the result is sent back to the client. If a method requires input parameters, these parameters have to be passed with the request. The result can be one or more output parameters, these parameters are sent back to the client in the reply message.

An object can also emit an event, or signal. When a signal is generated by an object, it will be broadcasted to any observers who are interested in that particular signal. Signals can carry parameters too. Methods and Signals are embedded members of an object. They can be grouped. An Interface of an object is just a group of its members. An object can declare one or many interfaces - its members are then classified in these interfaces.

Instead of forming a D-Bus method call message and sending to the remote object using Glib bindings, one can instantiate a proxy object representing the remote object and then just invoke the methods of that object.

In order to generate dbus-glib binding code, we can use a tool called dbus-binding-tool. We first create an XML file, referred as Introspection XML file, in which we describe the methods and signals. An example of the introspection XML is shown below:

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE node PUBLIC 
"-//freedesktop//DTD D-Bus Object Introspection 1.0//EN"
"http://standards.freedesktop.org/dbus/1.0/introspect.dtd">
<node name="/org/moblin/Platform">
  <interface name="org.moblin.Platform.Power">
       <annotation name="org.freedesktop.DBus.GLib.CSymbol" value="org_moblin_platform_power"/>
    <method name="IsUsingExternalPowerSource">
       <annotation name="org.freedesktop.DBus.GLib.CSymbol" value="isUsingExternalPowerSource" />
       <arg type="b" name="usingExternalPowerSource" direction="out" />
    </method>
    <method name="GetTimeRemaining">
       <annotation name="org.freedesktop.DBus.GLib.CSymbol" value="getTimeRemaining"/>
       <arg type="i" name="minutesRemaining" direction="out" />
    </method>
    <method name="GetPercentRemaining">
       <annotation name="org.freedesktop.DBus.GLib.CSymbol" value="getPercentRemaining"/>
       <arg type="u" name="percentRemaining" direction="out" />
    </method>
  </interface>
</node>

In this introspection XML file (named MIDPlatformSvcInterfaceDefinition.xml), an interface called org.moblin.Platform.Power defines three methods: IsUsingExternalPowerSource, GetTimeRemaining and GetPerCentRemaining. The output of the first method is a Boolean value. The output of the second method is an integer value representing the value in minutes, while the output of the third method is an unsigned integer value representing the percentage.

Below are primary steps to implement a service with methods to be exposed. More details are explained in [3].

Run dbus-binding-tool for an introspection XML file to generate dbus-glib binding code
Create a simple GObject for D-Bus
Implement the instance initialization
Implement the methods
Register the object to the D-Bus

To call the methods implemented on a remote object, a client needs to follow the following steps:

Connect to the bus
Create a proxy object
Invoke the methods on the proxy object

Using D-Bus as a Communication Channel

We designed the power service application which uses D-Bus as a communication channel to send information on battery. Other applications which are interested in power awareness can use D-Bus to get power information by querying the methods that the power service provided. These applications can also listen for the events that the power service generated. Figure 1 illustrates the usage model:

Figure 1. Usage Model: A Client Registers to D-Bus to Get the Information Provided by the MISPlatformSvc

Gathering Battery Information

We will present the implementation of three methods that are part of a simple library that provides battery information. The first method queries the percent of battery power remaining (getPercentRemaining). This method returns the percent of power currently available in the battery.

The second method queries the time remaining until the MID runs out of battery power (getTimeRemaining). This method returns the remaining time in minutes.

The third method queries whether or not the MID is using an external power source (IsUsingExternalPowerSource). This method returns a Boolean: TRUE means the MID is currently using an external power source (e.g., AC), FALSE means that the MID is using its battery (DC).

The first method calculates the percent of battery power remaining in a MID. In Linux, the file /proc/acpi/ contains power-related information. In particular, the file /proc/acpi/battery/BAT1/state contains the current remaining capacity in the field "remaining capacity". The file /proc/acpi/battery/BAT1/info contains the maximum capacity information in the "last full capacity" field. From these entries, we can deduce the percent of power remaining as shown below:

gboolean computePercentPowerRemaining(guint *result)
{
       DIR *d;
       struct dirent *de;
       char *acpi_path  = "/proc/acpi";
       char *device_type  = "battery";
       char *stateFile = "state";
       char *infoFile = "info";
       FILE *file;
       char filename[PATH_LENGTH];
       char line[LINE_LENGTH];
       *result = 0;
       double power_left = 0.0;
       double power_full = 0.0;
       gboolean rc = FALSE;
 
       // First, check if the ACPI path exists
       if (chdir(acpi_path) < 0) 
       {
              dbg("ACPI is not supported (\"%s\").\n", acpi_path);
              return rc;
       }
       else
              dbg("Path %s is found \n", acpi_path);
 
       // Check if battery directory exists
       if (chdir(device_type) < 0) 
       {
              dbg("No support for device type: %s\n", device_type);
              return rc;
       }
       else
              dbg("Device %s is supported \n", device_type);
       
       // /proc/acpi/battery is found. Now search for available batteries
       d = opendir(".");
       if (!d) {
              dbg("Cannot open directory!\n");
              return rc;
       }
 
       while ((de = readdir(d))) {
              // Search for real directory ("BAT0", ...), not ".", ".."
              if (!strcmp(de->d_name, "."))
                     continue;
 
              if (!strcmp(de->d_name, ".."))
                     continue;
 
              dbg("device found: %s\n", de->d_name);
 
              // Open file "state".
              sprintf(filename, "%s/%s/%s/%s", acpi_path, device_type, de->d_name, stateFile);
              file = fopen(filename, "r");
              if (!file)
              {
                     closedir(d);
                     return rc;
              }
 
              memset(line, 0, LINE_LENGTH);
              while (fgets(line, LINE_LENGTH, file) != NULL) {
                     if (strstr(line, "remaining capacity:") && 
                           (strstr(line, "mWh") || strstr(line, "mAh")))
                     {
                           // Search the value
                           char *c;
 
                           c = strchr(line, ':');
                           c++;
 
                           power_left = strtoull(c, NULL, 10);      // in mWh or mAh
 
                           // Cannot perform conversion
                           if ((0 == power_left) && (EINVAL == errno))
                           {
                                  closedir(d);
                                  return rc;                 
                           }
                           break;
                     }
              }
 
              fclose(file);
 
              // Open file "info".
              sprintf(filename, "%s/%s/%s/%s", acpi_path, device_type, de->d_name, infoFile);
              file = fopen(filename, "r");
              if (!file)
              {
                     closedir(d);
                     return rc;
              }
 
              memset(line, 0, LINE_LENGTH);
              while (fgets(line, LINE_LENGTH, file) != NULL) {
                     if (strstr(line, "last full capacity:") && 
                            (strstr(line, "mWh") || strstr(line, "mAh")))
                     {
                           // Search the value
                           char *c;
 
                           c = strchr(line, ':');
                           c++;
 
                           power_full = strtoull(c, NULL, 10);      // in mWh or mAh
 
                           // Cannot perform conversion
                           if (0 == power_full)
                           {
                                  closedir(d);
                                  return rc;                 
                           }
 
                           *result = (power_left/power_full)*100;  // in %
                           break;
                     }
              }
 
              rc = TRUE;
              fclose(file);
 
              // Exit while loop
              break;
       }
       closedir(d);
 
       return rc;
}

The second method queries the time remaining until the MID is out battery power (getTimeRemaining). This method returns the remaining time in minutes. As mentioned above, the file /proc/acpi/battery/BAT1/state contains the current remaining capacity in the "remaining capacity" field. The "present rate" field in the same file contains the rate at which the battery capacity is changing. This field is significant only if the battery is discharging. From this information, we can deduce the remaining time in minutes as shown below:

int computeTimeRemaining(void)
{
       DIR *d;
       struct dirent *de;
 
       char *acpi_path  = "/proc/acpi";
       char *device_type  = "battery";
       char *stateFile = "state";
 
       FILE *file;
       char filename[PATH_LENGTH];
       char line[LINE_LENGTH];
       int result = -1;
       double power_left = 0.0;
       double power_full = 0.0;
       double dischargeRate = 0.0;
       int find = 0;
 
       // First, check if the ACPI path exists
       if (chdir(acpi_path) < 0) 
       {
              dbg("ACPI is not supported (\"%s\").\n", acpi_path);
              return result;
       }
       else
              dbg("Path %s is found \n", acpi_path);
 
       // Check if battery directory exists
       if (chdir(device_type) < 0) 
       {
              dbg("No support for device type: %s\n", device_type);
              return result;
       }
       else
              dbg("Device %s is supported \n", device_type);
       
       // /proc/acpi/battery is found. Now search for available batteries
       d = opendir(".");
       if (!d) {
              dbg("Cannot open directory!\n");
              return result;
       }
 
       while ((de = readdir(d))) {
              // Search for real directory ("BAT0", ...), not ".", ".."
              if (!strcmp(de->d_name, "."))
                     continue;
 
              if (!strcmp(de->d_name, ".."))
                     continue;
 
              dbg("device found: %s\n", de->d_name);
 
              // Open file "state".
              sprintf(filename, "%s/%s/%s/%s", acpi_path, device_type, de->d_name, stateFile);
              file = fopen(filename, "r");
              if (!file)
              {
                     closedir(d);
                     return result;
              }
 
              memset(line, 0, LINE_LENGTH);
 
              while (fgets(line, LINE_LENGTH, file) != NULL) {
                     if (strstr(line, "charging state:") &&
                           strstr(line, "discharging"))
                     {
                           find++;
                     }
 
                     if (strstr(line, "present rate:") &&
                           (strstr(line, "mW") || strstr(line, "mA")))
                     {
                           // Search the value
                           char *c;
 
                           c = strchr(line, ':');
                           c++;
 
                           dischargeRate = strtoull(c, NULL, 10);   // in mW or mA
 
                           // Cannot perform conversion
                           if ((0 == dischargeRate) && (EINVAL == errno))
                           {
                                  closedir(d);
                                  return result;                    
                           }
 
                           find++;
                     }
 
                     if (strstr(line, "remaining capacity:") && 
                           (strstr(line, "mWh") || strstr(line, "mAh")))
                     {
                           // Search the value
                           char *c;
 
                           c = strchr(line, ':');
                           c++;
 
                           power_left = strtoull(c, NULL, 10);      // in mWh or mAh
 
                           // Cannot perform conversion
                           if ((0 == power_left) && (EINVAL == errno))
                           {
                                  closedir(d);
                                  return result;                    
                           }
 
                           find++;
                     }
 
 
              }
 
              fclose(file);
 
              // Exit while loop
              break;
       }
       closedir(d);
 
       if (find == 3)
       {
              result = 0;
 
              if (dischargeRate > 0)
                     result = (power_left/dischargeRate)*60;  // convert to minutes
       }
 
       return result;
}

The third method queries whether or not the MID is using an external power source. The information in the file /proc/acpi/ac_adaptor/ACAD/state shows the status of the battery. Below shows the implementation.

int computePowerSource()
{
       DIR *d;
       struct dirent *de;
       char *acadaptor_path  = "/proc/acpi/ac_adapter";
       char *stateFile = "state";
       FILE *file;
       int result = -1;
       char filename[PATH_LENGTH];
 
       // First, check if the ac_adaptor path exists
       if (chdir(acadaptor_path) < 0) 
       {
              return result;
       }
 
       // /proc/acpi/ac_adaptor is found. Now search for available entry
       d = opendir(".");
       if (!d) {
              return result;
       }
 
       while ((de = readdir(d))) {
              char line[LINE_LENGTH];
              // Search for real directory (not ".", ".."
              if (!strcmp(de->d_name, "."))
                     continue;
 
              if (!strcmp(de->d_name, ".."))
                     continue;
 
              sprintf(filename, "%s/%s/%s", acadaptor_path, de->d_name, stateFile);
              file = fopen(filename, "r");
              if (!file)
              {
                     closedir(d);
                     return result;
              }
 
              memset(line, 0, LINE_LENGTH);
              while (fgets(line, LINE_LENGTH, file) != NULL) {
                     if (strstr(line, "state:") && strstr(line, "off-line"))
                           result = 0;   // AC (battery)
                     else if (strstr(line, "state:") && strstr(line, "on-line"))
                           result = 1;   // DC
              }
 
              fclose(file);
       }
 
       closedir(d);
 
       return result;
}

Putting Things Together

First, the introspection XML in previous section clearly defined the three methods for battery. We can now generate a D-Bus binding header file using the D-Bus binding tool.

% dbus-binding-tool --mode=glib-server -–prefix=MIDPlatformSvc --output=MIDPlatformSvc-dbus-glue.h MIDPlatformSvcInterfaceDefinition.xml

Then, we create a platform service object by following standard steps in [3]. We don't show it here since it is straightforward. In the final step, we just glue the three methods above to the implementation.

Each interface method has three parameters: the called object, the return value, and the error. Inside the interface method we glue the return value to its implementation.

gboolean getPercentRemaining(MIDPlatformSvc *obj, guint *percentRemaining, GError **error)
{
       gboolean rc = FALSE;
 
       rc = computePercentPowerRemaining(percentRemaining);
 
       if (rc) 
              return TRUE;
       else
       {
              g_set_error(error, 
                         G_FILE_ERROR,
                         G_FILE_ERROR_NOENT,
                         "Failed to open file /proc/acpi/battery");
              return FALSE;
       }
}
 
gboolean getTimeRemaining(MIDPlatformSvc *obj, gint *timeRemaining, GError **error)
{      
       *timeRemaining = computeTimeRemaining();
 
       if (*timeRemaining > 0)
       {
              return TRUE;
       }
       else if (*timeRemaining == 0)
       {
              g_set_error(error, 
                         G_FILE_ERROR,
                         G_FILE_ERROR_NOENT,
                         "Cannot determine since information is missing!");
              return FALSE;        
       }
       else
       {
              g_set_error(error, 
                         G_FILE_ERROR,
                         G_FILE_ERROR_NOENT,
                         "Failed to open file or directory");
              return FALSE;
       }
}
 
gboolean isUsingExternalPowerSource(MIDPlatformSvc *obj, gboolean *onExternalSource, GError **error)
{
       int t = computePowerSource();
 
       if (t == 0)
       {
              *onExternalSource = FALSE;
              return TRUE;
       }
       else if (t == 1)
       {
              *onExternalSource = TRUE;
              return TRUE;
       }
       else
       {
              g_set_error(error, 
                         G_FILE_ERROR,
                         G_FILE_ERROR_NOENT,
                         "Failed to open file or directory");

              return FALSE;
       }
}

A Test Client

To test the interface power, we write a simple test client using D-Bus as well. The test client invokes the remote methods of object MIDPlatformSvc in order to retrieve battery information on the MID.

#define PLATFORM_SERVICE          "org.moblin.Platform"
#define PLATFORM_PATH                    "/org/moblin/Platform"
#define PLATFORM_POWER_IF         "org.moblin.Platform.Power"
#define POWER_SRC_CHANGED_SIGNAL  "PowerSourceChanged"
 
void queryMethod(char* param) 
{
       DBusGConnection* conn;
       GError *error;
       DBusGProxy *platformProxy;
       DBusError err;
 
       printf("Calling remote method: %s\n", param);
 
       g_type_init();
       error = NULL;
       conn = dbus_g_bus_get(DBUS_BUS_SESSION, &error);
 
       // Create the proxy Platform
       platformProxy = dbus_g_proxy_new_for_name(conn,
             PLATFORM_SERVICE,    // target for the method call
                PLATFORM_PATH,    // object to call on
                PLATFORM_POWER_IF);      // interface to call on
 
       // Now call the metjod "IsUsingExternalPowerSource"
       if (param == "GetPercentRemaining")
       {
              uint result;
 
              if (!dbus_g_proxy_call(platformProxy, param, &error, 
                                   G_TYPE_INVALID,
                                   G_TYPE_UINT, &result,
                                   G_TYPE_INVALID))
              {
                     g_printerr("Failed to call remotely: %s\n",
                                error->message);
                     g_error_free(error);
              }
              else
                     printf ("Remote call successes with returned value: %d%\n", result);
       }
       else if (param == "GetTimeRemaining")
       {
              int result;
 
              if (!dbus_g_proxy_call(platformProxy, param, &error, 
                                  G_TYPE_INVALID,
                                 G_TYPE_INT, &result,
                                 G_TYPE_INVALID))
              {
                     g_printerr("Failed to call remotely: %s\n",
                            error->message);
                     g_error_free(error);
              }
              else
              {
                     printf ("Remote call successes with returned value: %d minutes\n",result);
              }
       }
       else if (param == "IsUsingExternalPowerSource")
       {
              gboolean result;
 
              if (!dbus_g_proxy_call(platformProxy, param, &error, 
                                  G_TYPE_INVALID,
                                 G_TYPE_BOOLEAN, &result,
                                 G_TYPE_INVALID))
              {
                     g_printerr("Failed to call remotely: %s\n",
                            error->message);
                     g_error_free(error);
              }
              else
                     printf ("Remote call successes with returned value: %s\n", result? "TRUE" : "FALSE");
       }
 
}
 
int main(int argc, char** argv)
{
       char* methodName[3] = {"GetPercentRemaining",
                           "GetTimeRemaining",
                            "IsUsingExternalPowerSource"};
 
       int i;
       
       for (i = 0; i <= 2; i++)
              queryMethod(methodName[i]);
 
       return 0;
}

Below is the result when running the test client.

Calling remote method: IsUsingExternalPowerSource
% ./clientTester
Calling remote method: GetPercentRemaining
Remote call successes with returned value: 96%
Calling remote method: GetTimeRemaining
Remote call successes with returned value: 235 minutes
Calling remote method: IsUsingExternalPowerSource
Remote call successes with returned value: FALSE

Conclusion

Because the MID form factor limits the size of the battery, applications that run on the platform must be aware of power state information in order to make smart decisions. Knowing how much power is remaining, how much time is remaining, and whether or not the system is running on external power can help software make wise use of the MID's resources. D-Bus is a lightweight Remote Procedure Call (RPC) which is suitable for many applications running on desktop. Because D-Bus is simple and relative small, yet powerful, we can adapt this technology for Mobile Internet Device (MID). In this paper, we introduced a platform service for MID using D-Bus technology. We showed how to implement three power-related methods provided by the MIDPlatformSvc. A sample test client is also shown to illustrate how we can use D-Bus to invoke these methods. As D-Bus not only supports methods, it can also support signals; we can also extend this application to include signals. In the feature, this platform service can be extended to include other interfaces such as network, location, CPU utilization...