Re: Native mode handling
Keith Whitwell <keith-CdwZJljFklH+2FeEXyspIVaTQe2KTcn/@public.gmane.org>
| Newsgroups | gmane.comp.freedesktop.xserver |
|---|---|
| Message-ID | <[email protected]> |
Jon Smirl wrote: > Is anyone else working on native mode handling? I've spent about three weeks now > breaking native mode handling for the Radeon out from Xfree and turning it into > a standalone library. Modes are hugely complicated and the code is no where near > finished. Radeon almost works but a lot of de-Xfree'ing of the code is needed. > > My plan is to build separately compilable layers that build on each other. > > 1) Kernel DRM driver > 2) Framework based on Xfree 2D driver minus the PCI bus and 2D drawing code. > This includes all of the mode code. There are two libraries, one board specific, > one common (DDC, I2C). Layer 1 is used to find the hardware. > 3) The existing standalone Mesa driver. Modified to use layer 2. > 4) xserver modified to use the GL API. > > A goal of layer 2 is to make it reusable by other projects. I like this idea of a standalone library that knows about the hardware a lot. I'm somewhat interested in taking on task (4), but I'm not sure if 1) it hasn't already been done somewhere, and 2) if I've really got the time & resources to devote to it... There's no need to wait for the rest of these tasks to be done before writing effectively an OpenGL-targetted DDX - it could simply run in a window on any GL-capable environment already existing. That wouldn't take into account the interaction tasks you're talking about below, but would tackle the interesting questions about the suitability of the existing GL drivers (and available extensions) for implementing legacy 2D operations. If new extensions are needed for reasonable performance, it should become fairly clear fairly quickly. > To get the system going it is assumed that the OS installer can get the right > Kernel DRM driver loaded. This will create the /dev/dri/card0 device. xserver > can open this device and get the device name (radeon) this name can then be used > to form the name for the layer 2/3 shared objects. They can be dlopen'd and > initialized. In a normal system no config file will be needed. > > If config files are needed I'd like to make my layer 2/3 use these in a format > independent manner (unlike how Xfree does it). So the idea is that layer 4 would > would hand in a query API. The drivers would call with standardized config > variable names, something like driver/card/head/var --> radeon/0/0/mode. Is > there any work happening for config files in xserver? Keith