This article contains outdated information, please read with caution.
Mainly in the second half of the last year the Haiku USB stack has matured a great deal. Not only has it stabilized a bit, it has also seen the addition of an EHCI driver to support USB 2.0 devices. A rewritten UHCI driver and a new implementation of the USBKit library are other steps to a complete stack.
The reason to write about that is the following: An increasing number of people apparently get interested in the progress of Haiku USB and they start to ask questions about the completeness and usability of the stack. Also whether and how to use the Haiku USB stack under R5 is an interesting question. Instead of telling the story individually it probably makes more sense to sum everything up in a post for everyone to read. I'll try to show what is currently implemented and working and where missing parts or possible problems could arise.
I’ve been reading some more code and I’m getting more confident with it.
Basically data transfer is done with memcpy.
In the ehci controller, registers are mapped every time a controller is found. This is done in the controller constructor.
As the ehci specs says:
Register Space. Implementation-specific parameters and capabilities, plus operational control and
status registers. This space, normally referred to as I/O space, must be implemented as memory-mapped
I/O space.
I said it already, but I’m going to say it a million of times, I’ve never EVER would expected to work on such a project for the Google Summer of Code, I actually didn’t even think I would get in the soc. But anyway, here I am… so let’s begin!
Last night after I got bored reading the Kernel Kit section of the Be Book (it was about threads and related functions), I opened my shell and I dived right into the USB stack code.
Quick Updates
r20100-r20200- Updates to Mesa 6.5.2 and binutils 2.17
- Consoled debugging of app server, input server and the registrar
- CPU initialisation fixes
- Introduction of the UserlandFS
Quick Updates
20000-20100- Addition of class screensavers
- Customisable CFLAGS
- Useful URI to application redirects
- Syscall benchmarks and results
Quick Updates
19900-20000- Introduction of USBKit reimplementation
- Interesting local message passing optimisations
- VMWare vmdk tools
- vmdk image generator
- vmdk jam target: haiku-vmware-image
Quick Updates
r19800-r19900- Beginnings of AHCI support
- Hardware cache flush for SCSI
- Stability fixes for the USB stack
- Port of the following filesystems
Quick Updates
r19700-r19800- Addition of fortunes, including Haiku specific texts.
- Tweaked thread scheduler.
- Many VM enhancements and fixes
- Addition of resource editing tool, resedit.
- Addition of VMware graphics driver.
This morning we were discussing by email with Waldemar what could be causing some DB errors from the photo gallery and a general slowness of the website. Waldemar contacted our service provider, and their response was “your site has suddenly become too popular” (something that effect). Well, no wonder: I just noticed that we were Slashdotted (Haiku Tech Talk at Google a Success). I checked the logs, and it looks like the site received about 10,000 hits from /. in less than 12 hours!
For quite some time now, I have been looking for a good-looking and license-compatible Japanese font set that could be included in Haiku R1. Haiku does have a Japanese font called Konatsu, and while it does work, it is not very well suited as a general font for the overal UI. I think I have found something that is worth taking a close look: the VLGothic font set.
2ch+ running in Haiku using VLGothic font setVLGothic combines the latin characters from the M+ Fonts Project (these are VERY good looking fonts!) with the Sazanami Gothic Japanese font by the Electronic Font Open Laboratory. The result is a very good looking and well balanced TrueType font set with support for Japanese characters.
