Rudolf Cornelissen Interview.

For the last couple of months, we here at TBJ have asked our readers to post questions they would like Rudolf Cornelissen (of the OpenBeOS Matrox driver) and Thomas Kurschel (of the Radeon driver) to answer. Finally, we bring you the resulting interviews. I must say, they both provided exceptional answers, both in length and content, so due to that fact, i'll post them separately. Rudolf today and Thomas tomorrow. Note: This interview was conducted by e-mail.

TBJ: Welcome to TBJ and thank you for allowing us to have this interview, and for our users to ask their own questions. Why don't you tell us a bit about yourself?

Rudolf: Hi, and thanks for inviting me.

My name is Rudolf Cornelissen. I live in the Netherlands. I am 36 years old, and I am an electronics design engineer. I design, build, test and service electronics for a living. I also write firmware for the microcontrollers I use in these designs. The electronics I currently design are mostly used for digital and analog I/O inside industrial measuring machines our (small) company builds. These machines contain industrial singleboard PC's which interface to my electronics via serial ports.

Because I personally have a growing interest in writing (lowlevel) PC software, I recently went back to school in the evening hours to increase my knowledge in this area. If I complete this study, I will also have a degree in software engineering. If not, I will have learned a lot at least. And that was the reason I went back to school.

The lowlevel thing is only natural for me, because I am used to be working in hardware, and with microcontrollers that control this hardware. Doing such things on PC's (writing drivers for instance) is only the next logical step 'up'. And to be honest: it gives me a 'kick' to get things working.

One final note: I am a perfectionist more or less. I try to build robust devices and software. In order to be able to do this, I always try to keep things simple and straightforward. I must admit I take pride in the fact that the electronics I design for instance are known to rarely fail.

TBJ: And what is your BeOS background? When and where did you first heard of it and later started using it?

Rudolf: I first heard of BeOS when R4 was released. I read about it in an article in the (very good, precise and in-depth) German computer magazine C'T. Because back then I already had enough Windows experience to know I wanted to loose it, I was very interested.

So I purchased my own copy, installed it, and I was hooked immediately. I saw an OS that had the same principles I work with. It was simple, straightforward and rarely caused trouble.

For instance the fact that you could simply install BeOS on a harddisk inside some machine, remove the disk, and re-install it inside a completely different machine and just boot up BeOS without any trouble or delay at all, was a real relief for me.

I read the line in the readme file that came up after starting BeOS that said that some people wanted to work for Be after just seeing the OS, and I could really understand that.

Well, it goes without saying that I never left the OS since. I even think I will loose my personal interest for PC's all together if BeOS were not to survive. Unless another likewise OS would come up of course...
(Linux is much to complicated for my taste. It's also too geek-like I think. I do think it is very important though!)

TBJ: What motivated you to write your driver? Unsupported hardware, or just a project you thought would be useful to the community?

Rudolf: Three things. One is I'll do everything I can to support BeOS in order for it to survive. The second thing is I wanted to learn how to program on a modern PC OS. The third reason is indeed unsupported hardware:

I bought a PC DVD player some years ago. Because Windows did all but please me with the results I got, I decided I wanted to watch my DVDs on TV via BeOS instead. Of course, BeOS had no TVout support. It did have a DVD player though: the VideoLan Client (VLC).

So I started coding with Nvidia cards and I started tweaking in VLC to get TVout for DVD in the optimal output quality possible. And it succeeded. I have a friend who is very critical when it comes to watching DVD's quality-wise, and he told me at one point that he was impressed with the output quality compared to stand-alone DVD players. My output was _almost_ as sharp as the stand-alone players we tested.

Of course we used stand-alone players with short RGB leads while my TVout tests were done with a Y/C cable that was 10 meters in length. Y/C cables give less quality than RGB cables because of their design of course...

TBJ: Have you thought about working on 3D in the future? Especially knowing Zeta will have Hardware Support.

Rudolf: I have thought about it a bit. I have no 3D experience whatsoever though. Thomas does have that however. So if he will lay the foundations and create the first driver, I might be able to 'copy' his work for the Matrox driver... I must confess I find it quite a challenge to try to get _that_ working!

TBJ: And while on the subject, what are your thoughts on Zeta and were you contacted by them, related to your work?

Rudolf: I for one was never contacted by Zeta as far as I am aware. I don't even know if they are using (or will use) this Matrox driver on it for example... (Doesn't look that way if you check the hardware compatibility list.)

Because I am a 'down to earth' kind of guy I'll just wait and see what Zeta will really Be before I'll say or think anything about it. I do hope it will turn out to be a positive development at least! (can't miss, no?)

TBJ: Regarding 2D acceleration support, i can see that Rudolph implemented the ScreenToScreenTransparentBlit function in his driver, while Thomas skipped it. I also think that they both didnt implement the ScreenToScreenScaledFilteredBlit.

These functions (especially the TransparentBlit) are critical for many 2D operations, and having them accelerated can increase the performance of many operations (be that in games, graphics apps, or even the app_server itself) sadly they are not (even if implemented) available in a clean form to the programmer as they are not defined as hook functions for the BWindowScreen API, and you need to do some voodoo to get them to work (check YNOP's code in the app_server prototypes).

I think we need to find a solution to these problems and try to see what is missing from the Be 2D Acceleration API and if it can be easily implemented on current hardware, theb add the appropriate hooks to the current BeOS API. The only hardware requirement is that all driver writers must confirm to the new hook indexes.

Do you think it can be done? Have you talked to Darkwyrn concerning the OpenBeOS app_server?

Rudolf: I first have to set something straight I think. I never implemented any 2D function at all: Mark Watson did all of this work. The (open)BeOS Matrox driver is based on his work, while it's being expanded a lot. I did remove some tiny bugs from it for some cards though.

I agree that the driver/accelerant API needs to be expanded. Apart from possible missing 2D hooks, we also need real support for multiple heads, TVout and 3D. Also I would like to see multiple Graphics card support added somehow. The Matrox driver already supports that. As far as I know there are no other drivers that support that currently though.

About ScreenToScreenScaledFilteredBlit: I think Mark Watson searched for this function in the Matrox card docs, and he concluded that the cards do not support that feature. This is why it's not implemented in the Matrox driver.

This function would also be nice to have maybe to setup some 'fake' hardware overlay on older cards like the Mystique, Millenium and G100 cards. Windows for instance supports 'overlay' on these cards with such a 2D or 3D engine 'trick'.

Extending the the driverhooks will be no problem at all as long as everyone uses the same indexes. Indeed some new and/or modified classes or so should be implemented in BeOS to take advantage of new functions is a clean way.

They could be used without those classes indeed, but you need that voodoo you are talking about. You can accomplish that by using BWindowScreen to get to the hooks, or by 'privately' loading (a clone of) the driver.

Loading a clone of the driver is what's done as far as I know for instance for a video consumer node to set modes and such on the driver, while also the app_server is using the driver.

Extending the number of hooks is something Be themselves did also. The current accelerants support for instance these never used functions for overlay use:

uint32 OVERLAY_COUNT(const display_mode *dm) // This method is never used AFAIK though it *is* exported on R5.0.3 and DANO. // Does someone know howto invoke it?

const uint32 *OVERLAY_SUPPORTED_SPACES(const display_mode *dm) // This method is never used AFAIK though it *is* exported on R5.0.3 and DANO. // Does someone know howto invoke it?

uint32 OVERLAY_SUPPORTED_FEATURES(uint32 a_color_space) // This method is never used AFAIK. On R5.0.3 and DANO it is not even exported!

Noone seems to know how you should invoke these hooks with a class.
OVERLAY_SUPPORTED_SPACES for instance is very important: currently every video app outthere just tries some colorspaces to see if they work. Instead they should ask the driver which spaces it supports, and then select one.

Because no class/function exists to call these hooks, they are never used.
One final remark about overlay: Be defines some colorspaces in a headerfile. These spaces are 16 bit constants. They are defined howeverin a 32 bit array. This means that we could simply extend the list of colorspaces BeOS supports by adding the FourCC industry standard space definitions.

Most cards support overlay colorspaces that are not defined in the GrahpicsDefs.h file. They could be used by VLC for instance if we would add the fourcc definitions. VLC internally works with these FourCC spaces, and translates them specially to BeOS spaces for BeOS currently...

I have contacted DarkWyrm a few times to send him the latest Matrox driver version, as he owns a Matrox card. From the few interesting 'talks' we had, it looks like we are still operating on entirely different 'planes'. For now I expect this is a good thing seeing where development of the app_server currently is (as far as I know), but one day we need to be able to 'interface' to each other indeed.

I expect that this (if needed) will be only for mutual understanding of the current driver hook API so we can ensure that openBeOS is indeed compatible to R5, not for modifying or extending this API. At least not for R1...

TBJ: Is there any way the two of you (ed: Thomas will also answer this questions)could write an article for graphics driver development geared towards people with a background in application programming but little to no kernel experience? Like a tutorial.

Rudolf: I think that would be possible to some extent. The driver is located in kernel space by the way: the accelerant sits in userspace. Writing a videodriver means that you will spend 95% plus of your time on the accelerant: that's where the real work is done.

One 'feature' a driver writer really does need I think though: Because you will be programming hardware directly, you need to have a feeling of what you are actually doing. Otherwise you just might end up destroying your hardware, or at least fail in creating a useable driver.

Part of this 'feeling' can be but into a document you can read, but not everything. You'll see that every manufacturor outthere has it's own 'personal' way of implementing things in hardware. This can mean you need a very different approach to get something done from driver to driver.

If you want an example of different approaches, compare the ATI way over selecting overlay colorspaces with the Matrox one for example. Also have a look at how overlay is actually implemented in both drivers in:

status_t CONFIGURE_OVERLAY
(overlay_token ot, const overlay_buffer *ob, const overlay_window *ow, const overlay_view *ov)

TBJ: Where did you get all the info/specs to write the Matrox driver? Is everything freely available or do you have a special contact to the Matrox guys?

Rudolf: I registered as Hobbiest/Student developer at Matrox. They were generous enough to grant me access to some basic (but incomplete) register-level info for most older cards.

For instance, Mystique upto and including G400 register-level specs are available to me via Matrox, G450, G550 and Parhelia specs are not.
Also hardware MPEG codec and TVout specifications are not available to me, as is the case with VGA BIOS related info.

I can imagine by the way why the people at Matrox (and other manufacturors) are carefull with giving out video-related information. It will have to do mainly with the movie industry and content copyright issues I expect.

I have no special contact at Matrox, just unsupported access to the above mentioned specs. Luckily, there are more people that write videodrivers in the Linux community. I regularly have a brief look at some Linux kernel or XFree code that already supports more stuff.

I use that information to extract the specs for the missing parts as far as it's possible, and after that I write my own code as much as possible. So I do no literal porting.

TBJ: What about coding drivers for future models, assuming you'd be provided with a card and the info for those are also available? Is Parhelia support planned?

Rudolf: I do check the Matrox developer site regularly for Parhelia register-level specifications, but it looks like (for now) this will not be available to me. If these specs were available, and I had a card to work with, I might add Parhelia support.

It could be though that it would be better to create a new driver for it from scratch as I expect the Parhelia to be a brand new design. All other cards I mentioned are based on the Mystique. The later cards are only expanded and modified versions of every preceding model. This is the reason it's doable to build a unified driver for those cards.

TBJ: Will there be support for DVI?

Rudolf: I think I will be able to add support for DVI indeed on G550 and maybe G450, based on info you can find in the Linux codebase.
I happen to have a DVI monitor at my disposal, otherwise I would not consider adding support, because adding support without being able to test it yourself is very tricky if not impossible I think.

TBJ: Is it possible to reduce the resolution to 320x240? Having TvOut that supports that resolution would be an advantage for some users. (This comes from a user who wants to use his PC as a Media Center, so he would be far from the screen)

Rudolf: Currently I have no plans to try to add support for such low resolutions: I plan to support 640x480, 800x600 and 1024x768 overscan compensated (so with black borders around the picture) PAL and NTSC Desktop use output on G400-G550.

I'll also try to add video use output, being 640x480 and 720x480 NTSC modes. For PAL 768x576 and 720x576 resolutions are on my wishlist. Video modes are overscanning 1:1 modes. These modes will have no black borders around the screen, and they will offer the sharpest video output possible because they do not scale back.

I don't know exactly what the TVout chip can do resolution-wise because of the missing specs. One possibility for low-res output that does exist anyway would be scaling the output with some software. This could be used for low-res fullscreen video playback via a video consumer node for instance. One could also create a zoomed part of the Desktop on the TV this way in theory.

The MGA chip itself could also have some options to do a hardware zoom (I think it would be fixed 2x and 4x zoom then). I have not thought yet about doing something with this stuff, so that's why I am not certain about what can be done here.

In any case it would work the best using a video consumer node I think, and some special software that displays what you want on TV, be it a zoomed part of the Desktop or some video output...

I will add support for a video consumer node in the driver if TVout succeeds in getting good output quality. Currently it's not very good, and it only works on G400. With video consumer node support I mean that it will be possible to set different resolution, refreshrate and colordepth on both heads independantly using such a node.

On a final note I can tell you I am currently working on the TVout implementation: I have stripped down the code to what's actually used, and re-organized it to fit my own needs: it was Linux code before.

While TVout support has not improved yet, I am already gaining valuable knowledge of how it works on the Matrox cards. With this knowledge, and some more peeks at Linux code, I hope I will be able to finally improve the output quality while adding G450/G550 support. As soon as I get results, you will know it via the driver's website.

TBJ: Rudolf, I sent you a G200 and I remember you telling me another user also sent you a G200. Has there been many user contributions of this sort? People sending you cards?

Rudolf: I want to thank you again for sending me that card: it's very important to be able to work on cards you are going to support as I guess you all will understand.
Upto now I have received two G200's this way, and one G100 card. Because of this G100 and G200 support is a fact these days. Although some G200 cards exist used in the BeOS community that will not work fully OK with the driver. These cards are special editions of the G200 which I do not have here to test with unfortunately.

To be able to work on G400 and G450/G550 support I bought a G400 and a G550. The G400 was generously sent over here at a cheap price by a German BeOS user: in fact this card was the first one I got, and it was the reason I started working on the driver.

I bought a G550 brand new, so I could work on G450 and G550 support: these cards are almost the same. For the few differences the G450 has, I am bugging a hard-working German BeOS coder every now and then to do some tests for me. Not the ideal solution, but it will have to do for now: Can't buy them all you understand.

I think that the relatively small community is very generous to me: supporting me with some cards, testing help and feedback. Without all of these kinds of help creating an all-round good working driver would be next to impossible I think.

TBJ: You seem to be quite into hardware tinkering. Ever thought about looking into a USB-Geekport, as was suggest by Michael Phipps in an OBOS newsletter?

Rudolf: Hmm, I think I missed that newsletter, I'll see if I can find it later on. Anyway, I've been searching the web a bit to find out what this Geekport actually is, as I only knew it's name upto now.

It's a rather universal I/O device containing a multiplexed 12-bit ADC, a 4-channel 12bit DAC and some digital I/O lines. You can use it for instance to detect external events and control external devices. If the interface works fast enough, you can also generate audio on it for instanc, or digitize audio with it.
It's a typical device hardware/electronics engineers would have lying around to do some (electronics) hobbying with.

Well, the hardware in itself would be no problem for me to build as I am an electronics engineer officially. Actually I build these kind of devices on a 'daily' basis for my job: for instance I know the ADC used (MAX186: a serial interfaced ADC with 8-channel multiplexer and software range switching options).

Currently I still use the serial ports for these kind of devices though. I would have to learn more about howto write a USB driver in order to build a USB Geekport. I first started programming on BeOS by the way tinkering with a USB ZIPdrive, but I never completed that. It was recognized on R5, so at least I got 'some' result :-)

USB is a rather large subject to work with for starters, as its very universal. On top of that, someone needs to write a 'bugfree' USB bus manager, as the USB bus manager in R5 (manager V2) contains a serious error used for bulk-only transport that blocks the entire bus very easily.

You need to reboot in order to overcome that. In Dano BTW, the busmanager is fixed (V3). This was needed in order to be able to add mass_storage device support, such as the ZIP drives, CF flashcard drives, USB/IDE and USB/SCSI converters are. These devices mostly work with the bulk-only transport protocol as far as I know.

Apart from needing to learn the things I already mentioned, I don't think I'll start working on such a device. I think BeOS needs support for devices that are common good more desperately, so I would rather work on some other device, like a Nvidia card driver, or general USB support (as explained above)...
Although I wouldn't mind having such a USB Geekport to play around with ;-)

TBJ: Well, there you have it folks, the first of the two interviews with two excelent software writers. Hope you enjoyed. Stay tuned for Thomas' interview tomorrow.