From owner-freebsd-current@FreeBSD.ORG Sat Nov 8 15:09:15 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 417B31065677 for ; Sat, 8 Nov 2008 15:09:15 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 1377A8FC17 for ; Sat, 8 Nov 2008 15:09:14 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.2.57] (c-71-56-39-94.hsd1.ga.comcast.net [71.56.39.94]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id mA8F963U059369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Nov 2008 10:09:07 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Eygene Ryabinkin In-Reply-To: <5+tB+9b/go7regMZaz+M6h318XM@qm7gbYKMPO53E/nl+D5eD8YyL1A> References: <0E1DCF36-07A1-4A7F-8784-477709445C26@telenix.org> <1226086406.33599.22.camel@squirrel.corp.cox.com> <5+tB+9b/go7regMZaz+M6h318XM@qm7gbYKMPO53E/nl+D5eD8YyL1A> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-lZczdhP0AcKdWjyWM4TP" Organization: FreeBSD Date: Sat, 08 Nov 2008 10:08:59 -0500 Message-Id: <1226156939.1730.14.camel@wombat.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00, MIME_QP_LONG_LINE, RCVD_IN_PBL, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org, Chuck Robey Subject: Re: new X11 project X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2008 15:09:15 -0000 --=-lZczdhP0AcKdWjyWM4TP Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2008-11-08 at 17:31 +0300, Eygene Ryabinkin wrote: > Robert, good day. >=20 > 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 RedHa= t =20 > > > project. Among it's primary goals is to simplify the server, and =20 > > > since making things simpler (and hence more reliable) has been a =20 > > > lifelong primary goal of mine, I'm listening. My goal here, beyond =20 > > > trying to be helpful in pointing out something clearly important, is = =20 > > > to find out of anyone has done any research with a mind towards =20 > > > finding out the ultimate compatibility between FreeBSD and this new =20 > > > Wayland. I'm always worried that a Linux-person is going to =20 > > > "innocently" write something that requires us to become a Linux =20 > > > lookalike. > >=20 > > 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. >=20 > 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? >=20 > 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? >=20 > 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 > something? 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. robert. > > GEM is on my list to do sooner rather than later, but I haven't > > gotten it going yet. >=20 > I feel that GEM is rather useful for the DRM layer itself? At least > it is that it was written for... --=-lZczdhP0AcKdWjyWM4TP Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEABECAAYFAkkVq4sACgkQM4TrQ4qfROMdtwCfbckm5Cxuv1YL7NYjp7VIazBO xG8AnjqdziAHWRnFZEjg3uL89MFAWEC3 =XT9L -----END PGP SIGNATURE----- --=-lZczdhP0AcKdWjyWM4TP--