UVC Driver -- GSoC Quarter-term Report

Blog post by gabriel.hartmann on Mon, 2011-06-13 20:45

On June 7, I turned in my dissertation and my semester ended. On June 10, I had my first final exam. Now it's time to produce a progress report for Haiku. Almost miraculously, I've actually managed to squeeze some Haiku development time in and am making progress of a kind.

The most tangible progress is mostly in the form of debug messages and crashes into Kernel debug land, but I consider anything that I do which has a measurable effect to be progress. So far all my efforts are aimed at trying to understand how all the different pieces of a userland driver component come together. I've had a lot of help with this from my mentors and from people in IRC and on the haiku-development mailing list. Michael Lotz and Anevilyak (IRC nick, I don't know a real name) were particularly helpful.

My current understanding of the task is this:
1. I should detect the connection of a camera.
2. I should detect its capabilities.
3. I should expose those capabilities in a MediaNode.

In reality two and a half out of three of these have already been done for me. The USBKit is successfully detecting my camera. Furthermore listusb lists all the relevant interfaces, configurations, and endpoints the camera provides (there are many). In a similar way, a first draft of the UVCCamera driver (written by Jerome Duval) is also parsing this information and placing it in appropriate data structures. These data structures even make their way to encapsulation in a MediaNode which is visible to the Media server...sometimes. No capabilities are presented to the media server and CodyCam still claims that no video device is available, but I have seen something named "USB USB[sic] Video Device" in the Media preferences menu. However the behaviour of the node is a little strange. It's appearance is not stable at all. It tends to appear on an initial media server restart, then never appear again. This isn't always the case, so it's not exactly a reproducable bug which is irritating. Also attempting to test code by plugging and unplugging my camera or even a flash drive is a bad idea as it leads to Kernel panics and trips to a frozen Kernel debug land.

I do not yet understand the precise journey information takes from its extraction in the current UVC driver back to a Video Provider MediaNode. I know that a VideoProvider constructor takes a CamDevice. I know that a UVCCamDevice extends CamDevice. So presumably passing a UVCCamDevice to the VideoProvider constructor is how a MediaNode is created. I even see code which could do this in the USB webcam add-on directory, but I'm a little fuzzy on the exact set of operations which lead from the current UVCCamdevice code back to MediaNode creation. I'd like to understand exactly how that works.

Now that I've got a clearer if still hazy view of what's going on and what's needed I have some short term goals. First of all I'd like to understand exactly what a VideoProvider node needs in order to expose capabilities to interested applications. So far all my reading of code and documentation has focused on USB, but I really need to understand what the ultimate goal is before extracting data from the camera. Second (or perhaps in a shared first position), I'd like to not only detect camera capabilities but actually invoke a command which returns some data. I understand that Jerome Duval has done this recently and I'd like to either reproduce what he has done or extract some new kind of data. Third I'd like to actually expose whatever capability I am able to extract to the media server. My thinking is that if I can expose a single feature from end-to-end then the repitition of this task for more features should be fairly straightforward.

I'll be spending all day today working on the first two goals. Tomorrow I have to study for an exam as it takes place on the day after tomorrow. Then I've got a long break before my last exam in which to focus on the UVC driver. I feel like I am starting to get a handle on the structure of the problem and am able to poke and prod the current code to learn new things. That makes the problem solvable. I suppose my biggest medium-term worry is how to deal with compressed video streams. I don't know what decompression facilities are available or if they're applicable to this situation, but that's a problem for later.

ZFS Port: Community Bonding Report

Blog post by GeneralMaximus on Mon, 2011-05-30 19:39

I was busy with finals throughout the Community Bonding period, which left me with little time to work on GSoC-related tasks. I still have 3 exams left with the last one being on June 7. That's when the fun starts. For now I'm merely playing with ZFS on FreeBSD on a virtual machine. I still need to make my way through at least the ZFS On-Disk Specification. Even though the information contained in this document is not strictly required for porting ZFS to Haiku, it's a useful read nonetheless. It also makes me look like a rockstar when I open it in coffee shops.

According to my proposal, this is what comes next:

  • Finish porting dependencies (libavl, libnvpair, libuutil, libumem).
  • Begin writing an OpenSolaris compatibility layer. This involves studying how threads, mutexes, condition variables etc. work on Solaris and then writing wrappers that behave in a similar manner around the Haiku API.

This means approximately one week spent on porting and testing dependencies and a fair bit of time spent on learning about low-level Solaris interfaces. One week is an optimistic estimation for a port of any kind, but some of the dependencies are merely libraries that implement useful data structures. This means they might build on Haiku without major changes. I can't say anything further unless I've taken a better look at them myself. The end result of the quarter term should be an OptionalPackage that contains all the external ZFS dependencies.

June 7 is not far :)

Contacts Kit, Community Bonding Period

Blog post by Barrett on Mon, 2011-05-30 11:17

During the community bonding period, i have researched around the project to prepare my work for the coding days that will follow.
I also promised to talk with the other devs in the ml, it was not necessary in these days...i'm working with the help of Alex to a document describing the entire API in order to discuss it in the ml.

The first problem was to choose a Default Media Format for contact translators, my choice has been addressed to a flattened BMessage. BMessage will be used internally by BContact to represent the contact fields and the state of the object. BContact will be also a BArchivable object.

All that could look strange for a naive, but there are some aspects that should not be underestimated :

  1. Easily sendable through applications and network (useful in future when sync support will come)
  2. Make simple to save the state of an object on a disk and then restore it at the next boot

So one of the most important aspects of BMessage is their flexibility in storing informations. The contact kit will define a set of fields used to represent a generic contact in memory, but it's too restrictive! Apps and addons should be able to define custom types of fields since the API cannot in any case define a set of fields generic enough to support every existent and future API. This is already an obscure side for me and i need some hours to make clarity and choose the best solution.

Portable Contacts

Portable Contacts is REST API using OAuth with the aim to provide a generic access to contacts from different services, at the moment it support many services like the OpenSocial platform. Who has read my proposal probably remember something about a "Google Contacts Services Add-On". I have decided to switch it into a "Portable Contacts Addon". For more informations :

Goals For the first quarter

  • A little patch for the translation kit to support the Contacts translators
  • Basic BContact Implementation
  • vCard and People translators

A USB Video Driver for High-end Webcams (GSoC Proposal)

Blog post by gabriel.hartmann on Mon, 2011-05-02 03:04

As part of the Google Summer of Code I'll be working on developing a driver for Haiku that allows for the use of high-end webcams. By high-end webcams I mean in this case those which adhere to the USB video device class (UVC) specification. Preliminary work will involve bringing Haiku's support for the Enhanced Host Controller Interface (EHCI) to a point where UVC driver development proper can begin. Understanding the state of EHCI support and what work needs to be done in order to begin UVC development is my major goal for the community bonding period.

UVC development will entail the detection and exposure of camera features via Haiku's media kit. This will require (if I understand correctly) the production of a node with an attendant ParameterWeb which will hold the actual feature definitions. Then ideally any interested application will be able to issue commands to a UVC compliant camera and receive back appropriate responses in the form of image frames or video streams in various formats and resolutions, or status reports depending on the camera. The primary test camera will be a Logitech Quickcam Pro 9000 which supports a fairly wide range of resolutions, contains a microphone, and has a hardware button (presumably for taking still photographs). I have also noticed during the course of some computer vision research with the camera that it has what appears to be a hardware driven exposure compensation feature. There is also a similar feature exposed through the Windows Logitech driver software, but when this is turned off some exposure compensation still occurs. It will be intersting to see whether this feature is genuinely rooted in the hardware or is a result of hidden propietary Logitech software.

GSoC Introduction: ZFS Port

Blog post by GeneralMaximus on Sat, 2011-04-30 18:08

I'm Ankur Sethi, a 20 year old hacker from New Delhi, India. I mostly program in Python and Objective-C (on Mac OS X/iOS). This summer, I will work on porting ZFS to Haiku as part of Google Summer of Code 2011. My proposal lives here.

ZFS is a combined file system and logical volume manager built by Sun Microsystems (now Oracle) for OpenSolaris. Besides having a 'Z' in the name -- which automatically grants it +100 awesome points -- ZFS sports a feature set that will enable developers to build some incredibly neat applications on top of Haiku. For example, ZFS supports files and volumes up to 16 exabytes in size. It is designed from the ground up with a focus on protecting data from silent corruption (bit rot, cosmic radiation, etc.) Thanks to its copy-on-write nature, creating snapshots on ZFS is quick, easy and cheap, which takes the pain out of creating backups. This Wikipedia article does a better job than I ever could of describing why ZFS is, as Oracle's marketing department will be happy to let you know, the last word in filesystems.

I will be spending the Community Bonding period studying how the FreeBSD port of ZFS and zfs-fuse work. I will also be reading some of the available literature on ZFS. Once the coding period starts, I will use this blog to keep everyone updated on what I'm doing.

Looking forward to a great summer :)

GSOC Introduction: Jrabbit, Batisseur and you

Blog post by jrabbit on Thu, 2011-04-28 23:45

I'm Jack (Jrabbit). I am a python hacker.

Bâtisseur is a broad system for making Haiku package development simple and quick. It will borrow concepts from OpenSuse Build and Canonical's Launchpad [Specifically Soyuz]. Some documents pertaining to it can be found in this repo. The end goal will be a modern build system for packages that can scale up or down and a system of achievements for participating in it.

Whats happening now

During the community bonding period I will be working with the new hpkg_builder tool to make sure it's ready for hackage. I will be working with the core team to look at buildbot deployment and such. Also I will be trying to get some of my web tools I wrote for haiku put up on haiku-files.

2010 Google Summer of Code Mentor Summit

Blog post by scottmc on Tue, 2010-11-02 18:14

This year's Google Summer of Code Mentor Summit again fell on the same weekend as BeGeistert. This year Niels was able to make the trip. Niels and I attended the summit representing Haiku. We attended some of the same sessions but split up for others. As was the case last year we met a lot of developers from the other orgs, some I had met either at last years summit or other open source events. I talked with the VLC, FFMpeg and BeagleBoard guys on Friday night. One (or more) of the guys works for TI in Community Development, and was exited to hear that Haiku was working on an Arm port and suggested he may be able to hook us up with Free Hardware. We may just have to cover the taxes to get such hardware to a developer in Europe is all. I have contacted him and will post an update on this when we get a response.

Here's the group picture. click to see larger view

Syndicate content