2011 Google Summer of Code Mentor Summit

Blog post by scottmc on Wed, 2011-11-02 03:12

The GSoC Mentor Summit this year happened to be the weekend before BeGeistert, which allowed Matt Madia to make it to both events. This time Haiku had four mentors make the trip. Jérôme Deval flew in from Paris, Philippe Saint-Pierre traveled in from Quebec, Matt joined us from New Jersey, and I drove down from just north of the Golden Gate Bridge. Google allows two mentors per org, plus a third if the org participated in Google Code-In last year. Mentors who live nearby are allowed to sign up on a waiting list and if there's enough room Google allows them to come as well, so that's how we ended up with 4 this year. Matt and I stayed at the Domain hotel, while Jérôme and Philippe stayed at the Wild Palms. Google has a Friday night dinner at the Wild Palms so Matt and I walked over to meet up with Philippe and Jérôme, except that no one knew what Jérôme looked like. We were there for a few hours but didn't manage to find him on Friday night. On Saturday morning we hopped on the Google buses and headed over to the Googleplex. We finally met up with Jérôme at breakfast. After breakfast we headed over to building 43 for the start of the unconference. There were several interesting sessions posted, including one hosted by Philippe on software patents. Over the two days we sometimes went to sessions together and other times split up. While looking for one to attend for the last session on Saturday we didn't find one that sounded interesting so we posted Haiku on one of the empty slots for a room that could hold 8 people. The four of us headed over and so we could talk about Haiku. We were joined by a couple others who were interested in hearing about what was new with Haiku, so we talked and answered their questions and showed off a few things.

Saturday night Urias joined in, having driven 3+ hours to meet up with us. On Sunday after breakfast we ventured over to the android statues for some pictures.

We later attended what has now become a yearly mentor summit tradition, the Open Source Operating System Session. This year's session featured about 25 mentors from at least 9 different OSes. We went around the room discussing what's new with each one in the last year or so and ways that we could help each other. There was at least one new comer, IluminOS which I think is where Open Solaris migrated to. Philippe's session on software patents was at the same time as the OS Summit, the notes from that session and most of the other sessions are posted on the mentor summit wiki:
GSoC Mentor Summit 2011 Session Notes
It was a fun weekend and was great to meet up with each other. Google was, as always a great host and we thank them for GSoC and the mentor summit.

UVC Driver: Final Report GSoC 2011

Blog post by gabriel.hartmann on Wed, 2011-08-24 21:53

The Google Summer of Code for 2011 is over now for me. The final state of the UVC driver project while very far from perfect is at least at a point where incremental improvement can be made. Literally the day (maybe 2 days, depending which timezone you're in) before the "firm pencils down" date I finally managed to get data all the way from the camera to the screen. The decoding of that information is totally wrong at this point, but coloured pixels show up on the screen and they appear to react when things move in front of the camera. Success?!

Beyond the relatively simple task of writing a colour decoder that actually matches the format of the data being provided by the camera, there remains a whole lot of work to be done. The work comes in three major categories: the application layer, the driver layer, and the USB layer.

By the application layer, I mean the interface between the driver and applications. The two major webcam applications for Haiku Cortex and Codycam both primarily request and accept frames at 320x240 resolution. Allowances have been made in the driver for this behaviour. The current code should allow other resolution requests to be negotiated successfully, but without application testing, it's likely that resolution negotiation will have some bugs. Also this tendency on the part of applications ignores camera preferences for default resolutions.

At the driver layer the UVC driver does not even attempt to support all the features of the specification yet. In particular no attempt has even been made to deal with compressed video frames. The MJPEG frames that uvc cameras normally provide haven't yet been touched. The specification also allows for other proprietary formats. Again this is unexplored. Finally, the driver to camera resolution negotiation is not particularly robust and assumes to some degree that applications are going to request reasonable resolutions (from the camera's perpsective). This portion needs to be looked at again. This will be a time consuming process because camera stalls in negotiation lead to unrecoverable crashing of the media_addon_server. A camera stall occurs on the slightest provocation. Learn to love rebooting.

At the USB layer, ehci isochronous transfers tend to crash Haiku into KDL. There are probably a series of reasons for this, but at least one known issue is that ehci doesn't deal well with a large number of queued transfer requests. For this reason, there is currently artificial waiting time ( snooze(for a for a little while) ) in the generic CamDevice so that the queue doesn't get to backed up. Of course this makes a decent frame rate impossible. At least the more or less random pixels now displayed don't appear to have a very quick frame rate. Even with the artificial delay you only have about 20 seconds of video frames (if you're lucky) before crashing into KDL. Again, learn to love rebooting. There is a newer version of ehci available which deals with this issue, but I couldn't get it to play nice with my system.

In short, to use a transportation metaphor, a trail through the jungle has been beaten from camera to display. Technically one can get from point A to point B. However if you want to do this easily, quickly, and reliably you're going to need a super-highway. Expansion and improvement of the route is needed at all levels.

I had a great time with this, my first GSoC and learned a lot about USB which was something I didn't really know a lot about before. I'd like to thank my mentors Jerome and Philippe for their time and patience.

UVC Driver -- GSoC Three-quarter-term Report

Blog post by gabriel.hartmann on Mon, 2011-08-01 20:25

Not so long ago, at the half way mark of the GSoc, I was optimistic that I was near to actually interpretting data from the camera in such a way as to produce images on screen. I was successfully grabbing payload data from the camera, the camera's in-use light was on, things were looking good. Since that point, progress has been repeatedly stalled by strange and difficult to debug behaviour.

The first problem which I encountered was that the vast majority of the data received from the camera consisted only of headers with very little actual image data ever attached. In a few seconds of contact with the camera as an example, only 6 out of 7714 packets (0.000778%) contained content. That was worrying. Furthermore the bit indicating an error was often set in the headers, although not perpetually. Investigation of that problem has revealed one of two possible scenarios.

1) Protected content -- This situation occurs if the data source device detects that the video or still-image data is protected and cannot be transmitted. In this case, empty packets containing only headers will be sent for the duration of the protected content.

2) Input buffer underrun -- If the data source device is not able to supply data at the requested rate, it will transmit empty packets containing only headers for the duration of the buffer underrun.

There are other possible error modes, but these are the only two described in the specification which indicate the empty packets with only headers behaviour. Both I and my mentors believe that the second scenario is most likely. However we do not know for certain, which leads to another problem.

Requesting information about what error mode exactly is being encountered of the camera, should be very nearly in exactly the same format as the probe / commit routine which directly precedes the initiation of data transfer. However, whenever the camera is asked for further information about the error mode it is indicating, both the media_addon_server and the camera lock up. Now, it is far from abnormal for the media_addon_server to lock. This has happened countless times during development. But the camera has never locked up befor. Even after a restart, the camera remains locked. A full power cycle is required to bring things back to relative normal. So that's one major intractable issue at the moment, but it is not the only one.

Another major issue was an essentially infinite loop in the VideoProducer's Datapump thread. A division by zero was causing a very large negative number to be included in a sum. The result of this sum was supposed to be a time in the future for which a semaphore grabbing loop should wait. However since the time was hugely negative, at no point could a constantly positive and climbing system time reach this "future" date. Investigations into this issue were going on at the same time as I was investigating the empty packets error. Because my camera was locking up, I had been unplugging and replugging my camera repeatedly. In order to make this easier I had started using the usb plug on the front of my machine. This movement has, I believe, solved the division by zero problem. I haven't done rigorous testing yet, but it was a consistent problem before, and now that I've switched usb plugs, it has gone away. Do you see what I mean about strange and difficult to debug behaviour?

Finally, in an effort to see if the empty packets problem was confined to the beginning of data transfer, and perhaps worked itself out later, I began watching printouts of actually full packets being received. After about 20 seconds of this, Haiku reliably crashes into Kernel Debug Land (KDL). I'm now looking into kernel debugging advice my mentors have given me. Just judging by the kernel debug messages, it looks like an inappropriate NULL pointer problem in the ehci isochronous transfer code.

So, while it would be nice to be writing a deframer or some code for negotiating resolution between the user applications and the driver, with a view towards getting images on the screen at user requested qualities, I think it's probably more important to get the back end working properly. There are only about 3 weeks until the firm pencils down date and I haven't entirely given up hope of one day seeing images, but at the very least I'll hope to have made thorough informative investigations into a series of problematic behaviours that would certainly not be acceptable for end-users to encounter.

Contacts Kit, Mid-term

Blog post by Barrett on Tue, 2011-07-19 17:16

From my latest post, i had to do more work on the base classes, i realized that my implementation of BContactField was too inflexible for the use so my progresses were not fast as i hoped.
The main problem was to provide something that can fit the simplicity of the Person format (people files) and the complexity of VCard. The result was BContactField. Starting from a number of fields (defined in ContactDefs.h) the class provide some methods to access the field-type of a particular fields and give an interface able to manage properties and parameters as well. At the bottom there are some classes that implements BContactField, they will be used directly by the user, let me give some examples :

This merge every fields that does not have any other object or special functionalities like B_CONTACT_NAME or B_CONTACT_EMAIL.

This is the first example of a field that will incorporate an object from the Haiku's API, in this case it's simple but will be helpful when the BAddressContactField will be added.

How the API help to distinguish between the type of the fields?

You can use the method BContactField::FieldType() but there's a more simple solution, using the visitor pattern i have created a BContactFieldVisitor class, it is nothing more than an interface that specify one Visit() method for every BContactField child class. Implementing a your own class, when you receive a BContactField you can pass your visitor into the BContactField::Accept() method without having any troubles converting the base class to the derived class. One pratical use is for example the EqualityVisitor that allow to implement the method BContactField::IsEqual() in a nice manner. Also the VCardTranslator use a private visitor as a class that convert every field into a VCard string.

While i should commit some changes for BContactField, BContact and BRawContact are basically complete and usable and seems working as well.


The state of translators is summarily good, at the moment VCard can read and write some basic properties, People is in full development state. The main problem with it was a intrinsic limitation of the translation kit, basically you have to pass a BPositionIO (BFile, BMemoryIO..) to a translator but people files are recorded as attributes. You cannot edit an attribute using a BPositionIO since they are data written outside the file, so at the moment the translator will check if the input/output (as the case) is a BFile and if not it will fail.

At this point i will not make forecasts, i'm working on a plan for the services kit and the addon API in order to begin discuss it with my mentor(s), the first part of the project seems close to be complete so i'll update you with a blog post in the next days.

ZFS Port: Midterm Report

Blog post by GeneralMaximus on Tue, 2011-07-19 09:44

My midterm goal was porting libzpool -- which contains most of the ZFS code -- to Haiku. Another midterm goal was to get ztest -- the ZFS testing tool --- to run on Haiku. Being able to run ztest in a loop for an entire day means that about 80% of the ported code is working fine (though the remaining 20% is the most difficult part of the entire porting process). ztest is a userland test, so actual file system modules or disks are not involved in the testing procedure -- ztest creates block files in a temporary directory and treats them as disks.

It took me days of fighting with the linker and the compiler, but I'm happy to report that both ztest and libzpool build on Haiku without errors! Does that mean I can run ztest for a day without problems? Sadly, that is not the case. ztest is unable to create ZFS storage pools and fails within a second of starting up. I am currently trying to investigate and fix this crash. Fixing this one crash will reveal more crashes, and running ztest with several threads will reveal subtle threading issues. This means I have my work cut out for me ;)

Meanwhile, I have also started porting libzfs, which is the library used by the zfs and zpool administration tools to communicate with ZFS code in the kernel. This communication occurs as ioctl() calls on /dev/zfs. My goals for the quarter term are getting libzfs, along with zpool and zfs, to build on Haiku. Of course, an additional goal is to get ztest to run without crashing.

You can follow the project at Building ztest is as easy as cloning the repository, changing into the zfs-haiku directory, and typing "jam ztest". The ztest executable is generated in the debug.X86 directory.

UVC Driver -- GSoC Midterm Report

Blog post by gabriel.hartmann on Sun, 2011-07-10 23:31

Since my last blog entry a lot of progress has been made. Currently I'm right on the cusp of actually producing images on the screen that have been captured by my camera. Successful communication is occurring between the driver and the camera in at least two different forms.

The first form of communication to be successfully implemented involves the setting of values within the camera which affect image capture. These are the familiar brightness, contrast, sharpness etc. settings which most cameras support. Nearly all of the options available to my camera are now presented for manipulation by end-users and successfully communicated to the camera. These values are maintained within the camera between power cycles and this fact is successfully communicated to the user via the available controls. The controls can be viewed and modified in the media preferences application or the cortex demo application. ParameterWeb control documentation indicates a range of different style controls within the continuous or discrete parameter varieties. However it appears to me that the only discrete value input method currently supported with an appropriate gui interface is the binary on/off option. This is suitable for features like the auto value for white balance which can only be either on or off. However the powerline frequency setting which has three possible values was unable to be represented with the appropriate discrete control of the B_RECSTATE type which has three possible states. To simulate this capability a continuous control was modified to only allow three values which are indicated by placing the sliding control within a +/-10 range of the desired value. The slider snaps to the available values to indicate this behaviour. One future feature which would perhaps be desirable is controls with auto settings which indicate in real time by their movement what values the camera is using in its auto mode. Right now sliders are simply frozen in their last position when the auto mode is in effect. I had some brief discussion with my mentors about this feature, but it was deemed to be unnecessary at this stage as a lot of work is left to be done in actual image capture.

ZFS Port: Quarter Term Report

Blog post by GeneralMaximus on Fri, 2011-06-17 03:32

My quarter term goals for the ZFS port included porting all the libzpool dependencies to Haiku. Out of four major dependencies -- libavl, libnvpair, libuutil and libumem -- I already have two -- libavl and libnvpair -- building on Haiku. libumem and libuutil will take another few days, which puts me at least a week behind my original schedule.

I'm currently working on porting libuutil, which is presenting a few roadblocks but nothing that can't be fixed in one day's work.

When I have some free time, I want to take a break from working on the port and do some cleanup. So far I've indiscriminately copied all the Solaris headers I need into my own repository. This is bad. I eventually want to use as many Haiku headers as possible, only importing those definitions from Solaris that are missing from the Haiku headers.

After all the libraries are working, the next step is porting libzpool itself.

My source repository is located at