From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jon Smirl Date: Fri, 01 Jul 2005 23:18:08 +0000 Subject: Re: sysdev_class use from DRM Message-Id: <9e47339105070116182211c953@mail.gmail.com> List-Id: References: <9e473391050624071263dfbea7@mail.gmail.com> In-Reply-To: <9e473391050624071263dfbea7@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: linux-hotplug@vger.kernel.org On 7/1/05, Greg KH wrote: > Last kernel summit I thought this was all hashed out. I guess the > people not there didn't agree... There are more layers to the problem.=20 For example there is a bunch of redundant code between radeonDRM and radeonfb. To make the embedded people happy things are set up so that radeonfb can be run standalone and a merged radeonDRM can optionally be loaded. Since radeonfb is always there you put all of the redundant code into radeonfb, right? But radeonDRM has shared source with BSD. The BSD people started howling when I tried to remove the redundant code since they don't have an radeonfb equivalent to put it into. Then there is the pure architecture group. This group wants to define a small layer that works as a multiplexer and let you plug fbdev and DRM into it. This is a great idea if you have someone lined up to modify 67 fbdev drivers on ten different platforms/archs. Next is defense of backwards compatibility. Right now the rules of VT swap are that after swap another driver can reset the card and wipe it's memory, then when you VT swap back to the first driver it has to gracefully recover all of it's state. This was fine where there were 14 VGA registers but now we have 500 registers and 256MB of video memory. Trying to tamper with the rules of VT swap sets off major screams from groups like DirectFB. At a higher level the problem is tied into the Xserver. The server community is split right now between the EXA group and Xgl. EXA extends the current XAA model of doing almost every in user space and having platform independent drivers. Xgl take the philosophy that the OpenGL stack is the device driver and it can be as platform dependent as it wants. Then the Xgl server which sits on top is platform independent. This is really hurting because it is splitting our very small number of driver developers. There is still no agreement on the very basic concept of a single driver being in charge of the hardware and other are subordinate to it. I've also left out another dozen side arguments, like should mode setting be in-kernel or out? Another unsettled area is consoles and the kernel. If I put two graphics cards in a system should I get two consoles with VT's? Right now the kernel supports a single console, there is a 100K line patch to make it support more than one. I think it is crazy to further the current VT mess and I want to push console support into user space. (there would still be an in-kernel emergency console with no VTs). > Hey, how about at KS/OLS we (anyone who cares about this) sit down and > hash it all out and produce code that does this? With a working patch, > it should be simple to get it into the tree and then everyone can move > on. I am still uncommitted to coming. We have a new set of eight month old twins and I can't get permission to leave. The compromise may be to bring the wife, twins and nanny. This is not an easy area to get consensus on. You can get agreements from small groups but when it expands the agreements fall apart. It may require that someone like Linus bless a roadmap for video development and then reject anything that is not on the roadmap. With road we are on right now we are going to end up with ten different half finished systems. > I don't want to see any silly workarounds like what you are being forced > to do to happen. >=20 > thanks, >=20 > greg k-h >=20 --=20 Jon Smirl jonsmirl@gmail.com ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=CCk _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel