Date: Wed, 3 Mar 1999 21:24:39 -0700
From: Elizabeth Coolbaugh <cool@rdnzl.eklektix.com>
To: Linux Weekly News <lwn@rdnzl.eklektix.com>
Subject: XFree86 notes

For this talk, I was unfortunately unable to get to the first twenty
minutes.  This was particularly bad, because attendance was so high
that people were standing and spilling out into the hall.  Having
verified that even if I could get into the room, I couldn't see the
slides and I couldn't hear, I took advantage of some knowledge gleaned 
from being a speaker and snuck around through the back door, sitting
behind the stage curtains, so that I was able to hear Dirk Hohndel
speak even if I couldn't see the slides.

My view of the talk, therefore, may be biased based on the missing
twenty minutes or the lack of visual aids.  I thought of buying one of 
the audio tapes of the talk, but it wasn't available yet when I
checked and I'd have to go back to the hotel to the rental car to
play it ...

>From what I heard, the major goal of the XFree86 4.0 upcoming release
was not new features, though they may be in there.  The major goal was 
to radically redesign XFree86 for two purposes:

        1) to support features that would encourage vendors to
        produce their own open source drivers for release in
        parallel with drivers for windows

        2) to make XFree86 more enjoyable to work with, decreasing
        the massive spin-up cycle required to deal with the current
        105 million lines of code.  

The last was new to me.  They are having problems finding developers.
There is a mistaken impression out that their code development is
closed.  This is not correct.  If you are interested in working with
XFree86, you need to contact them and tell them what you'd like to do, 
but they'll be happy to bring you into the team.  They have about 470
developers on their lists, but due to the arcane nature of the code
and the investment required to learn it well enough to contribute,
less than 10% of the developers are actually providing new code.
The new design of XFree86 should decrease the required investment and
perhaps re-kindle enthusiasm and bring them some new developers.

On the issue of features to encourage vendors to develop drivers for
hardware, the motivation for that is fairly easy to understand.  New
hardware comes out on such a rapid release schedule that it is hard
for them to stay motivated to produce drivers for the newer cards.  A
board comes out and it may be three months until a driver is
available.  At that point, newer hardware is already being released,
so your driver will be appreciated, but won't actually reduce the
flood of people demanding drivers, since they will already be wanting
drivers for newer cards.  The only way to fix this is to get vendors
to produce the drivers.  To encourage them, you can compile a small
module following their published API that can be compiled and then
integrated into the X server without requiring a rebuild of the
actual X server.  Of course, this encourages both vendors and
developers.  Anything that keeps you from waiting around while
millions of lines of code are compiling ...

There are some other features that he mentioned and there are probably 
more listed out on their web site, but I won't go look right now.
They will be providing an easy ability for end-users to switch
performance modes.  They'll be providing support for multiple heads
with a single desktop, even across non-identical video cards.  They
will be exposing more of the hardware features past the Xserver so
that applications can take advantage of them if they wish.

What are their plans for the future?  Right now, they want to get 4.0
out.  He hopes to have an XFree86 4.0 tutorial at the LinuxWorld in
August.  

Questions from the audience?

[from here to the end, it is written like a transcription.  However,
it is *not* verbatim, I can't type that fast!  Deviation from what
the speaker said is definitely possible.]

What about drivers for non-Intel hardware?  

        Already supported on alpha, powerppc and Intel, we are working
on Sparc.  Our drivers will be ported if we have access to the
hardware.
The popular ones will be included.  

For future cards, if vendors only provide binary drivers, will they
support non-Intel hardware?  

        We're trying to educate them to release their information and
do the drivers in open-source, to undersand that wider availability of
the software sells more hardware.

Improved color management?  

        No work to his knowledge, but that doesn't mean it isn't
happening.  We are focusing on the 4.0 release.  


Which video company would you recommend for their cooperation with
drivers, particularly with keeping a driver for a long time?

        Answering that is hard for me because if I mention one vendor
or another, it may damage other potential vendor relationships.  If
the vendor chipsets change, they may not be able to get information
for us.  Look at a card that works today, that suits your needs, then
buy 20 of them.

Have we considered to move to a more open development model?  

        It is open.  Tell us who you are and what you want to do and
we'll let you in.  The vendors can understand a large international
team, but they want a single face to interface with.  Answering
support questions takes too much of our time already.  We do all of
it.  By limiting non-controlled development, we limit contacts or
questions for binaries we did not create or that contain modifications
to them.

Laptops?  

        Laptops are very difficult.  We are talking to vendors, ibm,
etc., about getting early access to hardware.  It is easy to get them
to donate $25 boards, it is much harder to get them to donate twelve
$4,000 laptops.  Toshiba is obviously a hard case, since they haven't
gotten the "message".

Are you in active dialogue with the GGI project?  

        No.  I don't think graphic drivers belong in the kernel.
Maybe very, very tiny hooks for specific purposes.

Digital flat panels?  

        They are a little harder.  They have special chipsets to
handle them and there is no standards for the way they are programmed.
We are talking to the vendors about releeasing specs, but I can't tell
you when anything will happening.

Rotating the display?  

        Actually harder than it sounds.  Very easy to rotate pictures,
but rotaring the fonts is actually very hard.  There will be support
for the XV extension.  Still looking for the deeloper (hint,hint) that
will integrate this.

DVD player?  

        Not yet.  

Input devices?  

        You can add support for any input device.  We'll
support mice.

Multi-heads, what about multiple keyboards?  

        I don't think so.  Maybe if you start a different server for
each keyboard, if each one grabs the right video card, the right
keyboard and the right mouse.  My question is why?

OLE?  copying and pasting of graphic objects?  If applications
implement their own, they can't interoperate.  

        X shouldn't support it.  It is a desktop issue.  

The hardware acceleration features that you are exposing to the user,
is alpha transparency one of them?  

        No it is not.  It is a 3D feaure.  The X server is a 2D
server.

Four months to release?  Is that to bleeding edge or to sense of
humor?  

        It is a real release deadline.  We've built a schedule, we've
committed to it, I think we can make it (of course I was optimistic
last year, but I've learned a lot since then).

Will you have support for the SGI Visual Workstation?  

        Are you going to send me one?  If you do, we'll support it.

If you have multiple heads, do all of them have to have the same
resolution?  

        No, the multiple heads don't have to have the same resolution.
However, there will be portions of the screen that aren't visible to
you on the smaller resolution screen so you drag or drop onto an area
you can't reach.  It might be relatively useless in reality.

Escaping out of a blank screen if you have a misconfigured
configuration file?  

        If the server is *hung*, you have to reboot.  It
is extremely hard to reset a graphics card after it goe apeshit.

There are some hooks in the kernel for implementing key
combinations to kill the current processes.  

        This doesn't help.  If the graphics card is in an undefined
state, it is hard to fix them.  Some cards have a software string for
reset,
but for most of them, there is nothing that you can do.  I use a
system with all of my files provided via NFS for just this reason.
That way, my files survive even if I have to power the machine off
and on because the hardware locks up too fast to  info to be flushed
to the disk (hello fsck).

Someone asked for a feature that doesn't exist.  His response was no,
but it would be easy to add.  Just go do it.  If you want a new
feature in Windows 98, just go pray.

What if you want to link code into the server to make it faster?  

        I'll have to think about that.  It might work but there are
security issues.  In principle it is possible, but the performance
gain is unlikely to be large.  Would rather see development elsewhere
to improve performance (gave examples).  Rather limited access to C
functions.

Mixing 16bit and 24 bit on the same screen, same head, 16bit for
performance, 24 bit for higher color?

        Theoretically possible, but don't know of any hardware that
supports it, which means that you'd have to implement it in software.
Hardware would be fast, via software it would be slow and not worth
doing.

Future of the X windows system and the X protocol (coming from a
standardization guy)?

        The development of X is running into finance difficulties.
There are very big companies interested in keeping up X, but they are
annoyed with the "free riders", that so many companies benefit and yet
don't share in the costs.  I am optimistic that it will continue.  If
the X effort fails, we'll continue and take over.

Will we be able to change the color depth without restarting the X
server?  

        No.  There could be a way for restarting it on the fly, but
uh, I don't like it.  There are much better ways, e.g. saving states
via the desktop, that are a better approach.

[The End]