Appendix C: References

Appendix C - References

• Asiliant Technologies: register specs for Chips and Technologies chipsets for laptops: https://en.wikipedia.org/wiki/Chips_and_Technologies.
• Be Incorporated http://www.beincorporated.com.
• BeOS API documentation: The Be Book https://www.haiku-os.org/legacy-docs/bebook
• BeOS R4 Graphics Driver Kit, alpha release 2, 1999-03-30, most likely written by Trey Boudreau.
• BeOS R5 Personal Edition, updates, and developer tools, free for non-commercial use.
• BeTVOut: TVout for nVidia cards under BeOS., Rudolf Cornelissen: http://betvout.sourceforge.net.
• FreeBSD http://www.freebsd.org.
• Haiku (OpenBeOS): http://www.haiku-os.org.
• Haiku (OpenBeOS) Matrox driver, Rudolf Cornelissen: http://rudolfs-place.nl/BeOS/MGAdriver.
• Haiku (OpenBeOS) NeoMagic driver, Rudolf Cornelissen: http://rudolfs-place.nl/BeOS/NMdriver.
• Haiku (OpenBeOS) NVIDIA driver, Rudolf Cornelissen: http://rudolfs-place.nl/BeOS/NVdriver.
• Industry standard .four character code. colorspaces: http://www.fourcc.org.
• Linux kernel sources: http://www.kernel.org.
• Linux Xfree86 project sources: http://www.xfree.org.
• Linux X.Org foundation sources: http://x.org.
• Matrox Developer Relations: register specs for diverse MGA cards: http://developer.matrox.com.
• MediaPlayer and streaming video solutions. VideoLan: http://www.videolan.org.
• Programmer's Guide to the EGA and VGA Cards, Richard F. Ferraro (Addison-Wesley), ISBN 0-201-12692-3.
• The indispensable PC Hardware book, Hans-Peter Messmer (Addison-Wesley), 4th edition, ISBN 0-201-59616-4.
• United States Code from the U.S. house of Representatives: http://www4.law.cornell.edu/uscode/17/1201.html.
• VESA organisation's VBE3 open standard: VESA Bios Extensions version 3: http://www.vesa.org/vbe3.pdf
• YellowTab: http://www.yellowtab.com.

Accelerant

4. Accelerant

As opposed to the kernel driver, the accelerant runs in user space. The accelerant provides functions that are needed to control a graphics card. These functions are used by the app_server and/or applications directly. There are a number of reasons for the graphicsdriver being divided into a kernel- and userspace part:

• Speed: When controlling the graphics card configuration (so programming the ‘registers’) is done using memory mapped I/O this can be done using pointers. This works much faster than doing a single I/O in kernelspace per register access. The context switch which has to be made then (twice per single I/O!) costs a lot of time. Especially when tens to hundreds of accesses need to be done this will slow things down considerably. (In theory the speed can be increased by sending lists of registers to the kerneldriver at once as this will minimize the number of context swiches, but this adds complexity considerably also.)

  Read More

Flags

5 - Flags

<td width="40%" valign="top">
  <b>Chart Legend</b>
  <ul>
    <li><b>Name</b> - The name as defined in the BeOS header files.</li>
    <li><b>API Construct</b> - The construct used in classes and functions.</li>
    <li><b>C</b> - The command, from API of appserver or accelerant.</li>
    <li><b>S</b> - Status, from accelerant to API.</li>
    <li><b>P</b> - The app_server is target.</li>
    <li><b>A</b> - The accelerant is source or target.</li>
  </ul>
</td>

A flag is basically a single tray. This tray has two states: TRUE or false. Flags can be given a command, or a status is indicated. The flags in BeOS are passed through 32bits words so that 32 flags can be passed.

There are several types of flags for video drivers. They have all in common that they are useful for applications from within the API. A subdivision of the types of flags can be created: -There are flags that are passed on to the accelerant; -There are also flags that are not passed on to the accelerant. These are flags that tell the App_server how to deal with the accelerant.

Conclusion

7 - Conclusion

Writing video drivers is nice to do a while. It is very instructive and (yet) good to do when the whole structure is addressed. Sometimes writing video drivers requires the necessary imagination from the programmer, because it is difficult to test some (combinations) of things or make them testable.

Also, the retrieval and understanding of the specifications is sometimes a challenge. Even if there is some documentation from a chip or card manufacturer, you still need to be puzzled regularly. Probably because of the big pressure from the manufacturers to be first with a new card on the market, you can see that the documentation is often bad or incomplete.

Writing The Driver

6 - Writing The Video Driver

When writing a video driver, a number of issues are important: -A plan is required to indicate the order in which the components can be constructed; -There must be possibilities for testing the driver; And -The driver must be constructed in such a way that its stability is ensured as well as possible.

This chapter will deal with these issues. The information given here is an important tool in actually building a video driver.

Students

This year, 2 of our 3 interns in GSoC and Outreachy completed their projects

• Rajagopalan Gandhagaran - Webkit2 port
• Preetpal Kaur (Outreachy) - Input preferences
• Bharati Ramana Joshi - Btrfs write support (repeated communication issues preventing the project from moving onwards)

Students

This year, all 4 of our GSoC students completed their projects!

• Cruxbox - XFS filesystem support
• Preetpal Kaur - Input preferences
• Leorize - Services kit rewrite
• Suhel Mehta - UFS2 filesystem support

Ideas

For information about Haiku's participation in GSoC this year, please see this page.

Qualifying students can apply for a Haiku project (see the list of suggested projects below). For details about how to apply, please check out Students: How to Apply for a Haiku Idea.

• ««
• «
• 2
• 3
• 4
• 5
• 6
• »
• »»