On Wed, 2007-04-11 at 10:40 -0700, Jesse Barnes wrote: > On Wednesday, April 11, 2007, Jesse Barnes wrote: > > Some people were asking about modeseting on #dri-devel this morning so I > > thought I'd post an update (airlied is asleep so we can blame him for > > all the problems :). > > > > The modesetting-101 branch of the DRM tree is coming along nicely. Much > > of X.Org's modesetting code has been pulled in (will look very familiar > > to those of you who've worked with X.Org's Randr 1.2 code), along with > > driver support code for Intel chipsets. > > > > Dave pulled over a bunch of it, and integrated the patches from Jakob > > (ioctl interface for modesetting) and I (initial port of some X.Org code > > along with DDC and i2c code) into the tree, got it working and wrote a > > simple drmfb driver to sit on top. > > > > Based on that, I've been working on making the i915 driver > > initialization less dependent on userspace for things, like mapping > > registers, allocating memory, setting modes, etc. I just checked in > > some code to initialize drmfb at load time and set the correct modes > > depending on output configuration (seems to work ok for external vga but > > lvds modes are still messed up somehow). > > > > It's all still very fragile at this point, so you probably won't want to > > play with it unless you're really interested in hacking on it. > > > > Some of the open questions we're wrestling with atm: > > o how do we free drm drivers to init a load time rather than > > addmap/etc. time? > > o how can we do TTM memory allocation at load time? depends on AGP > > init happening early, etc. > > o what should the initial config be? cloned? multihead? single, > > primary head with other heads initialized to a blank screen? > > and of course there's lots to do on the logistics front: output, crtc > > list management, locking, etc., and bugs in DDC probing for old monitors > > (need more delays and i2c poking). > > Oh, and if you want this to have any chance of working at the moment, > you'll need this patch too (I haven't pushed it for fear of breaking other > drivers), warning this was cut & pasted: > > diff --git a/linux-core/drm_stub.c b/linux-core/drm_stub.c > index f4da7da..13652eb 100644 > --- a/linux-core/drm_stub.c > +++ b/linux-core/drm_stub.c > @@ -113,10 +113,6 @@ static int drm_fill_in_dev(drm_device_t * dev, struct > pci_d > > dev->driver = driver; > > - if (dev->driver->load) > - if ((retcode = dev->driver->load(dev, ent->driver_data))) > - goto error_out_unreg; > - > if (drm_core_has_AGP(dev)) { > if (drm_device_is_agp(dev)) > dev->agp = drm_agp_init(dev); > @@ -136,6 +132,11 @@ static int drm_fill_in_dev(drm_device_t * dev, struct > pci_d > } > } > > + > + if (dev->driver->load) > + if ((retcode = dev->driver->load(dev, ent->driver_data))) > + goto error_out_unreg; > + > retcode = drm_ctxbitmap_init(dev); > if (retcode) { > DRM_ERROR("Cannot allocate memory for context bitmap.\n");
This is all very very nice. I don't see a problem in pushing this if drivers don't expose a load function though. Alan. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel