Thomas Kurschel Interview.

As promised yesterday, we have for you the second interview of this "Two-for-one deal", this time Thomas Kurschel steps under the spotlight (with no water) to answer our and our readers' questions. 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?

Thomas: Hi. I'm a computer scientist who has finished his Diplom (comparable to a Master of Science) last year and since then I've been working in the optics industry for a small, relatively young company.
I like listening to music, swimming, wandering, reading in encyclopedias to impress friends with useless knowledge and stuff like that ;) Apart from that I'm quite interested in low-level coding, I like seeing all the bits flowing around. Well, if they flow at all.

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

Thomas: Trapped by the "even bad news are good news" phenomenon I downloaded the Personal Edition September 2001 when things got worse with Be Inc. Actually, it was back in 1998 when a guy told me about a new OS called BeOS, but when I checked the compatibility list, both my soundcard and my graphics card weren't supported, so it took me 3 years to give BeOS a second chance.

This time everything went fine (apart from the "you can boot BeOS from Win98, but you shouldn't" problem) and I was quite impressed by the snappiness once the system booted. Having a Dual-Celeron, I first checked the number of processors the OS found, and was surprised that both were working. The GUI was incredible easy to use and I didn't need to bother with the command line or driver installation, everything could be reached with the mouse. The attribute system was quite a new thing to learn but turned out to be very powerful.

To be honest: I was looking for a nice GUI-based OS for quite some time and even considered "rolling my own", but this is just feasible as - aeh - writing your own OS ;) Even though I'm a programmer, I like GUIs, dislike command lines and being a male person, I always want to understand how things work. And this is exactly what BeOS offers.

In terms of using, BeOS started as being a toy, or rather a puppet where you pull out a leg, take a look what's inside and plug it in again, just for the sake of knowledge. Shortly after the first contact, Be's IP got acquired by Palm, which made me afraid of loosing the new toy, so I bought a Professional Edition, Gobe and the BeBible.

This was over a year ago, now I write my email under BeOS, smiling when I get another email with a faked attachment type, use NetPositive for surfing, being sure that no JavaScript popup bothers me, do some coding and use it for giving interviews. Ah - I forgot something: playing MP3s. Unfortunately, digital out doesn't work on my laptop, well - let's see what can be done there...

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

Thomas: I think programmers, especially Open Source programmers, are selfish. The most important reason to start a project is "hey: I always wanted to know how this works, let's try coding it!". And the other is "Why for god sake doesn't this program work as I want it to? Hm, let's fix it." For me, the main reason to start coding at all was to play a bit with BeIDE. It's a bit simple, but it looks professional, is easy to use and it's bundled with the OS. Very developer friendly. Furthermore, you have the lovely BeBook which described every aspect of BeOS, is well-structured and offers you nice introductions to all the pieces of BeOS. The only missing thing was a proper project.

But this got solved faster then I wanted it to: for the first test, I installed BeOS on a small partition on my old hard disk. When I got the Professional Edition, I thought that this was the right time to give BeOS the honour of getting a partition on the new hard disk. As you may guess, this was it - the disk was connected to a new Promise Controller and couldn't be found.

I tried every trick, but there was no way. So I started to search for some documentation about IDE controllers and took a look at the linux kernel sources. I had never coded a driver before, so I had no clue how to do that. Fortunately, I found the HPT366 driver on BeBits and asked the author to give me the source code (Be was so kind to send him the original source code of the generic PCI controller driver). I was really impressed how simple and elegant it was coded and I had to add a few lines only to get support of my Promise controller.

Having my first driver, I thought that other users may have the same problem and thus published it on BeBits. Since then I wrote the IDE replacement driver and the Radeon driver and I have received lots of feedback, including much consisting of a simple "thank you", and this makes me feel sure that this was worth it.

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

Thomas: 3D is certainly an important but also a very huge project. I have quite some 3D programming background, but there are many, many important things that have to be done first, so there is no real time frame when I'll take care of this. Certainly, I cannot do that alone, and the very short product cycles of 3D hardware makes it almost impossible to be up to date (think about Radeon 9700 support, which is still not finished).

I don't know about Zeta and hardware OpenGL, so I cannot make any statement about that.

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

Thomas: I spoke to Bernd at the last BeGeistert and he asked whether he could add my drivers to Zeta. Sure, he can; the more people use my drivers the more it was worth the effort writing them. In general I'm more into OpenBeOS then Zeta as drivers are one of those things that _must_ be for free and open sourced. But in general I think that Zeta can be critical for BeOS to survive: the coder community of BeOS is not that large and until it reaches a critical mass where everything is taken care of automatically, as under Linux where you will always find someone who provides your wished driver or the missing app, we need a commercial BeOS, Zeta, or whatever you want to call it.

A spare time coder can always drop a project for various reasons, but a commercial distributor has a basic interest to keep things rolling and will make sure that a successor is found for the project. This does not mean that once BeOS/Zeta gained enough traction we don't need commercial projects anymore, but especially in the startup time such projects are critical, at least in my opinion.

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?

Thomas: Let me first answer the last question: I haven't contacted Darkwyrn up to now. I think he has quite enough work to get a replacement for the existing app_server, so feature requests are probably bit early now.

Back to missing driver functionality (warning! this is really technical): the list of 2D acceleration functions is certainly I bit short, which is probably because Be tried to find a least common denominator of all cards. Some functions aren't even used, like the transparent blit, so I didn't bother implementing them (I don't even know what this function is expected to do, so I think _no_ implementation is better then a wrong one).

These functions share one property: both the source and the destination must be on screen and this restriction renders them useless. What you really want is copying/stretching/whatever something from a bitmap onto screen, but this is impossible as bitmaps are stored in main memory whereas graphics cards need them to be in their local graphics memory to do something with them (there are exceptions, but this doesn't help you if you want to design a hardware-independent driver interface).

What we need is the ability to create bitmaps in graphics memory to use 2D acceleration on them. As graphics memory is a limited resource, the system cannot assure that this is possible, so it either has to refuse the creation of further bitmaps once the graphics memory is full (bad idea in a multi-tasking environment), or it has to store all bitmaps in main memory and copy them into graphics memory whenever the application wants to use them like OpenGL does with textures (but as copying data from graphics memory back to system memory is a very, very, very slow process, this can lead to problems if they are modified and must give way for other bitmaps), or the system must have the chance of dropping bitmaps if it runs out of graphics memory like DirectDraw does (but this is probably only acceptable for games where bitmaps can be recreated or reloaded on demand). Whatever way you choose, this will lead to quite some changes in the app_server, so it's not really feasible until the new app_server is done.

So, it's not a question which functions have to be added or how they can be accessed, but how to make use of them. Meanwhile, the only thing you can do is adding some hack which has to be replaced sooner or later anyway. (whoever asked this question can contact me directly to continue discussion).

TBJ: Is there any way the two of you 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.

Thomas: Actually, the sample driver provided by Be is kind of a tutorial. The source code is pretty much documented and they even provide a tool to test the driver. When I started writing the Radeon driver, I just took the sample code, which acts like a questionnaire where you have to fill in the missing pieces. What is probably missing is an introduction where to start, so if there is demand, I can consider writing one.

TBJ: You released the driver's source code not long ago. How involved are you still in it's development? And didn't the release cause a problem with ATI?

Thomas: Actually, I released it already some months ago, but almost no one noticed ;) Currently, the driver works really stable on my computer and most features I need are implemented and almost all bugs fixed. The only missing thing is TV-out support, which I cannot implement as there is no documentation provided by ATI.

I asked them about it, but they told me that this would touch both their own and MacroVision's IP (perhaps they are just paranoid that I might disable MacroVision's copy protection), so it's quite unlikely that TV-Out will ever be supported. The only missing bit is support of Video capturing, TV tuner and newer Radeons. As the cards I own have none of these features, there is little left I can do.

In terms of ATI, I'm quite surprised about their support. Of course, there are always wishes left (like providing spec for Radeon 9700 ;), but in contrast to many other companies they are cooperative. When I started development, I didn't want to register at ATI (which is required to get any support, including specs) because I feared that this would render publication of source code impossible.

I told ATI about this issue, and they replied that publishing wouldn't be a problem as long as I send them the code first so they can remove sensible information. I have no clue what piece of information this could be, but up to now they always gave me an OK for publication (it takes appr. 2 week for their review, so there will always be a delay on BeBits between binary and source code release).

TBJ: What new features can we expect in the new Radeon driver? Or is it mostly a bug-fixing release?

Thomas: In terms of new features, I only want to add bug fixes and support of newer cards. As written, the driver supports all features my cards provide (apart from TVOut, but I wrote about that in the interview), so unless I get new hardware I cannot add new features. But if anyone wants to add some, he or she is always welcome.

TBJ: Will you, or anyone else be working on the old video capture drivers for Radeons?

Thomas: I talked to Chasan last year about the capture driver. At this time, he suffered under complete data loss and thus couldn't really help me. He pointed me to Frederik but at this time my BeOS development stalled a bit because of lack of time, and so it got forgotten. I just wrote an email to Frederik to find out what the current state is.

Basically, I cannot continue developing of this driver as I have no Radeon with capturing support. This is currently the main reason why no further release have been made: strange as it may sound, but I'm out of unsupported hardware, and driver writing without hardware is like application programming without a computer.

TBJ: Though it hasn't been updated in a while, are you still working on the IDE Replacement Driver?

Thomas: Here we have the same state as for the Radeon driver: all the hardware I have access to is supported, so I can hardly add support for other controllers (like for recent CMD controllers - I tried to write a patch but it didn't work, so I had to give up). Once in a while some issue is reported, like problems with PIO 4 mode CD-ROMs, but some guys have the problem and others don't, so I have no clue whether it really is the PIO mode or something else. Apart from this, the driver is quite stable.

he next step I do is rewriting the IDE Replacement Driver from scratch. Though it works nicely, there are copyright issues if I publish the sources. So, in order to get an open source driver, I discarded the entire driver and started a complete redesign. The new driver will be a SCSI/IDE driver mixture and will support new features like 48 bit LBA support and elevator sort (i.e. if there are multiple concurrent disk requests, they get sorted to minimize head seek time - don't know how much this will gain, but I thought implementing this is cool ;)

The reason for combining IDE and SCSI is because they have more things in common then you would expect: IDE CD-Rom drives, Zip-drives and everything that's not a hard driver but connected via IDE executes SCSI commands encapsulated in a special IDE command. This means that if you write a SCSI CD-Rom driver, you almost have a IDE CD-Rom driver, so it makes sense, at least in my opinion, to merge IDE and SCSI. A nice side-effect will be that we get some parts of the SCSI driver chain.

Initially, I wanted to write the driver for NewOS, but soon it turned out that many, many things I needed were missing and the system itself was to fragile for this quite complex driver. So it came to standstill. Currently, I've back-ported the driver to BeOS and now I'm adding missing functionality as the driver was never finished. I cannot give you a time frame, but certainly I want to get that thing running.

TBJ: Do you plan on including U160/U320 - SCSI Support?

Thomas: Even though the new driver will be a mixed SCSI/IDE driver, I'll first try to write a compatibility layer to be able to use existing BeOS controller drivers. As I haven't got SCSI in my system, I won't be able to write new SCSI drivers. About 9 months ago, a guy offered me to borrow his U160 controller, but currently there's just much to much work to be done for the IDE part, and driver writing involves lots of testing (and lots of breaking support of previously working system), so you can really only provide support for hardware if you have it in your test system or in your drawer to plug it in whenever you are afraid of having broken the driver.

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)

Thomas: Supporting resolutions like 320x240 is possible (though I had to add some extra code as every line must be drawn on screen twice in this low-resolution mode, which will probably break some calculations). But as TvOut is not supported by the driver, this mode will probably be of little use. If you are still interested, send me an email. (PS: if anybody misses some other resolution, please tell me and I'll see what I can do).

TBJ: Will the Radeon 9700 (and now the 9500) be supported anytime soon? Is it planned?

Thomas: I started adding Radeon 9500/9700 support, but without hardware this is an almost impossible task (and ATI hasn't released any specs yet, so I have to pinch the missing pieces from XFree86). I've tried to debug it on the base of beta-testers, but currently I'm a bit in a fix. I think there are only few bugs left, but I simply can't find them. So if you are a coder and the proud owner of a Radeon 9500/9700 and have the skills to debug a graphics driver (well, whatever that means ;), please help me finishing the driver!

TBJ: How about support for the All-in-Wonder cards? More specifically the TV Tuner and Video-In connectors found on this cards.

Thomas: It's the usual problem: I don't own one, so I cannot provide support. Apart from that I have to ask ATI to provide me specs about these features. So, currently - no.

TBJ: Wow, they're not only great coders, they give great answers too. Thanks to Thomas and once to Rudolf for taking their time to answer our and our readers' questions. Keep up the great work! And thanks to our readers for contributing to this interview.