I just did some further investigations. I can startx from the commandline or
login via gdm.

However, when I switch to vt1 and then back to X I can see X for a second and
then the
screen will go blank. Moreover, I found out that X will not crash. In fact, if I
press the
little button which turns off the LCD panel when the lid is closed, then the
panel will go ON and everything is just fine except for the brightness wich is
extremely low. If I release the button
the screen will go blank again.

I just found out the following: The vga card can output the signal to an
external monitor
and to the internal LCD. When I switch back from the console to X, the output is
set
to external only. Using the keybord I can switch back to internal only and
everything is
finde.

It is possible your soundcard was locking up the machine perhaps.  KDE
by default starts up sound effects and that has caused some machines to
lock.  I would think it to be a kernel bug if it occurs and is the case.
This may or may not be the problem you had.. hard to say.  Looks like it works
for you now though so I'm closing the bug.  Thanks.

No the problem still persists and it doesn't seem to be kde and or sound
related:

If I switch from a virtual console back to X11 the driver switches the output
signal from
the internal LCD to the connector for an external monitor. The same happens when
the
screen server is activated. I it is no big deal since I can switch the signal
back to the
internal LCD using some special keyboard sequences. However, it is quite
anoying.

I just did some furhter testing. The above two problems are only present with
gnome.
However, if I use gnome and change the screen saver in the configuration
application
and press the "OK" butten, the vga signal will be also changed to external only.

Sorry, the first sencence of my previous entry should read "are only present
with KDE".

Bill, Bero, Havoc - do you think this might be related to the DPMS problems
in xscreensaver/GNOME?

Oops, accidentally changed component to Efence somehow...
I'll blame it on Mozilla's relative crappiness for now..  yeah, that was it..

Um, only indirectly in that they might be querying/setting DPMS settings. Querying
the X server's DPMS settings should *not* cause it to switch the display,
though....

Does this problem still occur in our latest errata?

Yes the problem is still here in beta2 (XFree86-4.1.0-0.8.6).

Problem is still present in beta3

BTW, I just noted that if I don't boot the kernel into fb mode, it will
not be possible to get the "signal" back to internal. Instead the entire
display will turn from black to white. 

Unfortunately, we simply do not have the hardware available to look
into this issue.  XFree86 3.3.6 is more or less completely dead now.
There is no movement in its source code for just less than a year now.
Instead I recommend trying to use the 4.1.0 server, and disabling
acceleration if it doesn't work.  3.3.6 is no longer maintained at all,
however there is always a possibility that the 4.x driver maintainer
may still work on open issues in the 4.x driver.

Sorry we're unable to look into this matter.