Blogs

Batisseur project update: Summary of work done and crystal ball into the future.

Blog post by jrabbit on Sun, 2011-05-29 14:41

Some of the clearly amazing things that got done during the community bonding period were:

I also discovered that Buildbot (Mostly its dependency: Twisted) don’t play nice on FreeBSD, the platform which currently builds Haiku nightlies on Matt Madia’s server. It’s not a huge priority to me at this point but it appears a bug still exists and will have to be filed (on my list).

On my list for the first quarter is finishing Command Not Found, and beginning work on the git tools and web services for package developers.[My actual project.] These tools can be developed while the package-fs work is in limbo or hpkgs mature. Command Not Found is a little script (if the install has python) or message that hooks into Bash’s command not found system and informs the user of ways to get this software. (i.e. you type in ruby but haven’t installed it or know that we have installoptionalpackage ruby, it will kindly tell you we have it.) Ubuntu has this feature in recent releases, and has an optional feature that may be interesting to use, spelling correction. It will be optional.

Command not found will be a way for users to be educated about Haiku even if they dive straight into the Terminal like a Unix user without reading any documentation (Like me!).

VBox guest additions: end of bonding period; first quarter goals

Blog post by scgtrp on Wed, 2011-05-25 10:25

During the community bonding period I played around with the existing guest additions patch, getting it to build and switching my repository over to git to preserve my sanity. I've learned a lot about the way Haiku drivers and modules work, especially in the last few days, and it seems that a few things are simpler than I originally thought they'd be and some things are more difficult.

As an example of the latter, it turns out that drivers can't provide APIs to other drivers; only modules can do this. This posed a problem for the shared folders module, which needs to either be in a separate module or contain extreme hackiness. As a driver, the original vboxguest couldn't allow vboxsf to use its API. To solve this, mmu_man and I decided that the best first task would be to break up the existing vboxguest driver into a module (vboxguest) containing the guest additions and a driver (vboxdev) which exposes the library to userspace as /dev/misc/vboxguest. This is now finished.

It turns out guest properties and clipboard sharing are already working, and mouse pointer integration is at least partially implemented, though I've not managed to get it to work yet. This should free up a bit of time for some of the other things.

As my first major subproject, I'm planning to implement a shared folders filesystem module - as I (and possibly a couple of other students?) are coding exclusively in VirtualBox, it makes sense to focus on the things that make development easier first, and being able to share files with the host is certainly useful at times.

Language Bindings for the C++ API: First Quarter Goals

Blog post by jalopeura on Wed, 2011-05-25 09:03

During the bonding period I looked into Python's extension tools; they seem to be straightforward and at first glance look relatively easy, so Python is definitely an option. I asked on the mailing list what other languages people were using on Haiku, and Neil kindly made a poll based on the results. Depending on the popularity of the language (based on the poll results) and the ease of writing extensions, I will make a final decision on which langauges to target during GSoC.

I also looked into various ways of defining the extensions. I have decided to use an interface definition and generate bindings from that. I looked at pidgen's IDL, but it didn't have all the necessary information. I also considered parsing the header files directly, but that would also lack some necessary information. I am currently working on defining an SGML-esque interface language. Using an SGML-like language means that if a new target needs information not currently contained in the interface definition, this information can be added without disrupting the parsers for existing targets. SGML also compresses nicely. I am, however, still open to suggestions for other solutions, since I haven't (yet) put enough time into this one to be irreversibly committed to it.

My goal for the first week is to get minimal functionality; I have selected Perl as the target for this portion because I already know how to write extensions for Perl. I am implementing enough of the Application, Message, Window, and Button objects to write a small test program. This should let me work out any issues with the interface language.

Once this test program is working, it should also allow me to test for thread issues. While I could deliberately write a program that blocked, what I'm looking for is situations where C++ would not block with equivalent code. As soon as the test program is working, I'm going to look at changing some data via the from the target language (running in an interpreter in the main thread) when called from Window::MessageReceived (running in the window's thread). If anyone has any other suggestions for creating blocking situations, let me know.

After I have made the final selection on target languages and determined the best way to avoid thread issues, I will continue by expanding the interface definitions used for the test program and creating new interface definitions for additional classes. I will also need to document the interface definition language and each of the classes. Class documentation, at least initially, will consist of the differences between the C++ interface described in the Be/Haiku Book and the interface for the target language in question, along with a link to the relevant page in the Be/Haiku Book.

Unfortunately, I haven't been able to stay online much so far. We have company visiting us, and they're staying in the room with the wireless router/modem. Since Haiku can't do encrypted wireless, and I can't use the only space physically close enough to the router to use an ethernet cable, I have to leave Haiku and boot into Windows whenever I want to use the internet. I tried running Haiku from the physical drive with VMware in Windows, but it's too slow. Does anyone know whether VirtualBox can use the physical drive, and if so, is it faster than VMware?

In summary, my goals for the first quarter are:
- Define an interface definition language
- Define preliminary bindings for a minimal test program
- Write a preliminary generator to create the bindings
- Write the minimal test program
- Test threading issues
- Make a final choice on target languages
- Expand preliminary bindings and add new bindings
- Write test programs for the bindings
- Write documentation for the bindings

GSoC 2011: May 23 (end of community bonding period) Milestone Report

Blog post by antifinidictor on Mon, 2011-05-23 08:11

During Community Bonding period, I began the process of setting up my Haiku working environment. Initially I attempted to install Haiku on my machine using VirtualBox; while this ran successfully, I could not access the internet or USB devices from my virtual machine (and hence could load the SDL libraries into Haiku). I have since created a Haiku-USB drive which also loads, although my graphics hardware breaks down if I do not run Haiku in safe mode, and Haiku still does not recognize my ethernet connection. I have also tried connecting via Wifi, with similar results.

I have briefly discussed the issues with my mentor, and will inform him and the Haiku community of my computer's hardware in a few days. For now all I can say is that it is a Sony VAIO (laptop), and I have had compatibility issues before with certain types of software and drivers. I will have access to another machine with different hardware after June 10, if necessary.

I hope to have a working Haiku installation on my machine, and possibly have downloaded and compiled SDL 1.2 by the quarter term.

===Edit 5/29/2011===
Thanks to my mentor and those who commented below, I was able to get internet on the VirtualBox working using the IntelPro 1000 chipset. This is slow, but it should be good enough for me to get started. Of course, since finals is the week after next, I will be doing almost no work during until June 10; but I will download SDL 1.2 onto the virtual machine and see if I can get it to compile.

Lesson 20: Drag and Drop

Blog post by darkwyrm on Tue, 2011-05-17 11:38

In this lesson we seek to understand the part of the Interface Kit which lets us move things around in Tracker using the mouse. We will examine both ways of transferring information from one program to another, both the simple way and the more flexible (and complicated) method.

Programming with Haiku, Lesson 20

Driver status update : Radeon HD

Blog post by kallisti5 on Fri, 2011-05-13 15:35

EDIT: 05/28/2011: Add card functionality as of r41792

I have recently been working on the radeon_hd graphics driver and accelerant to get extended mode setting complete for the Radeon r600-r800 chipsets (Roughly Radeon HD 31xx - Radeon HD 59xx)

We still have a *very* long way to go, however the following is now working in the driver:

  • Identifying a pretty large range of Radeon HD cards based on PCIID
  • Reading card information such as Memory and recording it
  • Reading the active monitor EDID
  • Creating mode lines from the EDID information above and adding them to the available mode lines
  • Passing the active monitor EDID to the screen preflet for monitor vendor/model/serial identification

Here are the short-term todo items (with focus on getting extended mode setting working):

  • Set non-vesa (extended) mode lines by toggling the vendor-specific Radeon registers
  • Implement PLL controls
  • Add a few card-specific screen preflet options

Here are the long-term todo items:

  • Finish AtomBIOS support to support advanced card functionality
  • Multi-monitor support

I am looking forward to (hopefully!) getting base functionality to the ATI Radeon HD cards. If you have and comments / PCI ID numbers / etc feel free to contact me and let me know.

Here are the current card test results as of 5/28/2011 r41792

Radeon HD 3450 r620  -- kallisti5
   Primary monitor works at native resolution of
   1440x900 but image offset and cut off.

Radeon XT 2600 r630 -- Benjamin Angerer 
  Primary monitor works perfectly. Plugging secondary
  monitor causes major issues as we are using EDID VESA
  results. (we try to use the VESA primary monitor modelines
  on the secondary monitor)

Radeon HD 4350 r710 -- kallisti5
  White screen of doom, incorrect screen mode change.

Radeon HD 5830 r800 -- kallisti5
  White screen of doom, incorrect screen mode change.

GSoC: Haiku 2011- SDL Revamp

Blog post by antifinidictor on Mon, 2011-05-02 06:11

This summer, I will be delving into the Haiku implementation of SDL 1.2 and updating it to support SDL 1.3. Since the SDL 1.2 implementation had a number of bugs associated with it, it may be necessary to completely rewrite the implementation.

I currently hold an internship that ends with Spring Quarter in early June. My time up until June 10 will therefore be extremely limited, but I will do my best to make time to work on Haiku. I hope to spend the community bonding period getting to know the Haiku community and discussing the project with my mentor. I also hope to meet or talk with other GSoC developers, particularly the other seven people working on Haiku. Discussing the project with my mentor will help me develop the best strategy and perform initial setup. Meeting and talking with other developers will help me understand the operations of Haiku and how my project fits within the overall Haiku project.

I hope to make progress on setting up my Haiku development environment during the community bonding period as well.

Syndicate content