On Wed, 2007-04-11 at 19:13 +0100, Alan Hourihane wrote:
> 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.
Whoops. Ignore that comment. Just got in from a long distance travel and
obviously hadn't drunk enough coffee.
But don't ignore the first comment, this is still very very nice.
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
