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
[email protected]
https://lists.sourceforge.net/lists/listinfo/dri-devel
