This is a discussion on Re: new X11 project - FreeBSD ; On Sat, 2008-11-08 at 17:31 +0300, Eygene Ryabinkin wrote: > Robert, good day. > > Fri, Nov 07, 2008 at 02:33:26PM -0500, Robert Noland wrote: > > On Fri, 2008-11-07 at 13:52 -0500, Chuck Robey wrote: > > > It's ...
On Sat, 2008-11-08 at 17:31 +0300, Eygene Ryabinkin wrote:
> Robert, good day.
> Fri, Nov 07, 2008 at 02:33:26PM -0500, Robert Noland wrote:
> > On Fri, 2008-11-07 at 13:52 -0500, Chuck Robey wrote:
> > > It's discussing a new X11 project, going by the name Wayland, a RedHat
> > > project. Among it's primary goals is to simplify the server, and
> > > since making things simpler (and hence more reliable) has been a
> > > lifelong primary goal of mine, I'm listening. My goal here, beyond
> > > trying to be helpful in pointing out something clearly important, is
> > > to find out of anyone has done any research with a mind towards
> > > finding out the ultimate compatibility between FreeBSD and this new
> > > Wayland. I'm always worried that a Linux-person is going to
> > > "innocently" write something that requires us to become a Linux
> > > lookalike.
> > I haven't spoken to krh about it, but the userland component likely
> > won't be all that difficult to port. The more complex issue is all the
> > back-end kernel support that will be needed.
> Do you really think that it is really needed to include all modesetting
> stuff to the FreeBSD kernel? What's wrong with the current
> implementation for the, say, Radeon userland drivers in this respect?
> AtomBIOS and company needs not to be in the kernel. Sure, DRM is
> already a part of the kernel, but it is the "real" need -- physical
> access to the hardware (with the more-or-less fast response) is needed.
> But what is the point in having the pure userland code in the kernel?
> I understand that Wayland has only 3000+ lines of code, but I feel
> that the complexity is just moved to the other places. Am I missing
The objective of kernel mode setting is not to put a full blown xserver
in the kernel. The goal is to optionally allow the kernel to take
enough control of the hardware to for example avoid flickering when X
starts. As it is now, if you get a panic while in X, it results in
either an obscure system hang or spontaneous reboot. In my opinion one
of the key advantages of kms, will be the ability to get panic messages
out to the user/developer while in graphics context. It should also
allow us to have a nice pretty graphical boot if we choose to, think
OSX. Another advantage that we get will be an improved ability to
handle suspend/resume events. This will also benefit folks who have to
use the vesa fb now. As I said, I haven't really scoped the work yet,
but much of this is already in drm, it just depends on the X server to
tell drm what to do.
> > GEM is on my list to do sooner rather than later, but I haven't
> > gotten it going yet.
> I feel that GEM is rather useful for the DRM layer itself? At least
> it is that it was written for...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)
-----END PGP SIGNATURE-----