gsoc

Google Summer of Code project: Sub-pixel anti-aliasing

Blog post by Andrej Spielmann on Wed, 2008-05-14 23:22

Hello Everybody!

My name is Andrej Spielmann and I am the GSoC student who will be implementing anti-aliasing based on LCD sub-pixels to Haiku’s graphics engine (App server, Painter, etc.).
Stephan Assmus is going to be my mentor on this project and Oliver Ruiz Dorantes seems to be my backup mentor and an eager investigator to the Slovak language and cuisine :-)

A short introduction of myself: I was born in Slovakia (Bratislava) and I still live there during vacations. During high school I have spent two years in Germany so I can speak German quite fine (Normally I would say very good but there are many Germans around :-). Now I’m studying at the University of Oxford (UK) at a 4-year undergraduate course in Mathematics & Computer Science. After I finish, I would like to go for a PhD somewhere else in Europe (Norway, Switzerland??) or in the USA. I very much like traveling, tourism, hiking and cooking. I’m most probably going to use a part of the GSoC money for a long trip around Russia including a part of the Trans-Siberian Railway.

I have no prior experience with coding for Haiku but I admire it a lot and will be very pleased to get involved with the community. Right now, I’m a little busy preparing for my exams, which take place between 2nd and 19th of June (but quite sparsely distributed, so there should be time for GSoC).
I am planning to start working on my project by the end of the next week, hopefully a couple of days before the official starting date to compensate for the time during exams when I won’t be able to fully concentrate on GSoC.

I will be coding on a Mac. I have set up all the compilation tools natively and now I’m able to build a hard disk image that runs in Parallels Desktop. If this turns out to be too slow or obstructing I will be considering other alternatives.
Right now the first big challenge for me will be to understand and get familiar with the existing Haiku code that I will be modifying. I will keep you updated on how it is going.

Bye,
Andrej

Contact:
ICQ: 161748133
Skype: andrejspielmann
e-mail: andrej.spielmann@seh.ox.ac.uk

Google Summer of Code Project: Alternate System Timers

Blog post by Dustin Howett on Sun, 2008-05-11 00:45

Hello, Everybody!
I'm Dustin, the student in the 2008 Summer of Code who is going to implement support for system timers other than the TSC in Haiku.

I've been actively tracking (and trying to involve myself in) Haiku's development for a few months now, but have been passively watching it since Be, Inc. went under and OpenBeOS sprang to life. In that time, I've gained a basic understanding of the Be/Haiku API, and of limited parts of the Haiku kernel.

Couple growing kernel knowledge with studying standards documents such as that for the HPET, and I believe I can finish this, or get a very appreciable start on it, over the summer, and plan to stick around long afterwards.

I can be found in #haiku on Freenode, my nickname is DHowett.

Thanks very much,
Dustin Howett

GSoc Swap File Project

Blog post by upczhsh on Thu, 2008-05-01 05:41

Hi everyone!
I am the GSoc student to implement the swap file support.

Haven't been here for a long time since I spent a week prepareing for the school's exam. The annoying exam ended yesterday, and now I have time to make some preparations for this summer.

I have got a basic unstanding of the Haiku vm system during the application period. In the next few days, I will investigate how paging is implemented in Linux and FreeBSD (I've stated doing that but was interrupted by the exam)and continue to work on my haiku vm tutorial. :-)

Bye,
Zhao Shuai

Impression about my GSoC with HAIKU and USB isochronous support status

Blog post by emitrax on Wed, 2007-09-05 13:32

During this summer I had the chance to improve myself, and work on the USB isochronous support of HAIKU. I wrote some code for every layer of the HAIKU USB stack: USBKit library, usb_raw driver, usb bus manager and most of all the uhci driver. I also spent/waisted some weeks with the usb_webcam media addon, but sadly with not success. Anyway here is what I did.

UHCI driver: Basically I added all the necessary code to handle isochronous transfer in both direction (in and out).

USB stack manager: As above, I added the necessary code to handle isochronous request plus a feature that was missing in the stack and I needed in order to use my webcam. Basically the possibility to choose a different alternate settings for an interface was missing. The code that implements this feature, along with some more code, is still hanging in my computer as it has not been reviewed yet. Not worries though, it will soon be included in the main tree.

USBKit library: Same here. I've added the code to submit isochronous request from user space and to set a different alternate settings. I also modified Francois utility (usb_dev_info) to display all the info about different alternate settings. This code is also still in my computer, but as I said, don't worry ;)

usb_raw driver: like you can imagine, I've added the necessary ioctl commands to handle both isochronous request, and alternate settings feature.

The main reason why some code is still not included in the main tree, it's because it breaks binary compatibility with the USBKit, as I added some more needed command to handle the alternate settings feature.

The most difficult part of my work was the testing as there was not working driver that uses isochronous transfers. I first tried with adding the support for my webcam to the usb_webcam media addon, but it turns out to be more difficult than I thought, because it wasn't very easy to debug for me. So after waisting some more days trying to compile a messy kernel driver provided by my mentor :-) , I finally come up with the idea of implementing the driver for my webcam as user space utility by using the USBKit and so bypassing the media server. This time it was very easy to debug. I managed to get some data but I didn't write the part the actually parsed the data and decoded the frame, as I ran out of time. I though compared the data I was getting with the one sniffed with usbsnoop on linux while running XP on vmplayer and some long hex patterns matched, which are supposed to be some sort of sync pattern. Beside, when putting the camera under my white lamp I was getting 0xff data, which looked very clear to me.

Anyway, I must say that I'm not very happy about the testing, I hoped I could do more but as I said, I waisted some weeks trying with the wrong method to test my code. Sorry guys.

Anyway, I'll be off for some weeks now, as I have my last exams and then I'll probably move to Pisa (any BeOS/HAIKU user over there?). Then I should finally managed to finish reading the OHCI spec I printed out month ago, and I promised I would work on.

Salvo

My feelings about GSOC and Firewire status

Blog post by absabs on Fri, 2007-08-31 02:36

During this summer I was working under my mentor Jerome Duval's guidance. This is the first time I tried to be part of the GSOC program.

All is well

Blog post by Sil2100 on Thu, 2007-07-19 12:15

Even though I had some private issues this week, all is going well with the PackageInstall. In its current form it is able to properly install all 3 test BeOS packages I tried on it, creating files and directories along with their data and attributes without flaw. So, what's left to do right now?

And those decisions lead us to...

(Or: knitting a delicate fabric, part II: sewing it all together)
(Or: Right, Joker, the underwear might be on the outside, but I get to drive the Batmobile!)
(Or: I just had to say something about Batman and the Batmobile. Couldn't help it.)

Cool, now we have a space- and time-efficient data structure (which is nothing more than a nice structure to handle non-overlapping numeric ranges) we can use to implement the simplified stride scheduling thing I've been discussing ou the previous posts, which will remain small most of the time, and won't change its shape like mad, so it's also very gentle on the CPU cache. Not only that, but the same effects hold for any trees, shall we decide that red-black trees aren't adequate and set ourselves to use splay trees, AA trees, AVL trees, Huffman trees, unbalanced binary trees (please: no.), whatever. So far we took care of the (not any more) skewed proportions due to randomness (by using strides), the mapping of "tickets" to tasks (by using trees to store the queues, "indexes" as the tickets, offsets to simulate "special" tickets, and lazy evaluation to efficiently implement offset propagation to upper queues), and the order of complexity (by using the queues as the node elements of the tree, where the key is base priority times number of threads in that queue).

Syndicate content