Re: Latest on modesetting
I'm hijacking this thread a bit for a question. Currently we have a "feature" with the lvds code that powers my laptop display, which turns off the screen backlight at modeset, resulting in a near black screen. What should the default behavior be? Some suggestions: 1) leave it up to the apps (harder to write small simple apps) 2) restore previous power level (what if the screen doesn't have a previous state, or it was off) 3) always go full power (leave it up to the apps to power save) Cheers Jakob. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Latest on modesetting
On Wednesday, April 11, 2007, Keith Packard wrote: > > o what should the initial config be? cloned? multihead? single, > > primary head with other heads initialized to a blank screen? > > The X server has some built-in policy for what the starting mode should > look like. I think we should be able to build that into the kernel and > leave more complicated policies to user-mode. > > 1. Identify outputs with 'preferred' modes. > 2. If no preferred mode, pick an output, set it to 96dpi > 3. All other outputs get the closest mode which is no larger than > the mode selected above > 4. Fit CRTCs to the output configuration by searching for the best > match, scoring preferred modes 2, other modes 1, no mode 0. > 5. Clone everybody. > > Cloning seems like the obviously right plan to me; we want to make the > boot-up output visible, and we don't expect to need more than one > screen. The worst thing that could happen in clone mode is that the user > will see more than one copy of the boot messages. Right, bootup output is important (though its signal to noise is degrading with the proliferation of printks added to the bootup these days). But you could also argue (at least for GUI desktop usage) that desktop extension is preferable to cloning. For a text-only bootup (whether it be actual textmode or fbcon), a clone may make more sense, though then you run the risk of not being able to use your preferred mode on the 'main' display (e.g. laptop panel), don't you? Or does the 'fit' in step 4 above work in that situation? E.g. a laptop with a 1280x800 panel connected to an LCD with a 1024x768 display? For the kernel (special uses like debugging aside), I guess either cloning or just using the primary head would make the most sense. Detecting the other heads is necessary, and if cloning weren't in use, some sort of natively sized splash screen would let the user know that it was detected properly... Thanks, Jesse - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Latest on modesetting
On Wed, 2007-04-11 at 07:38 -0700, Jesse Barnes wrote: I can't answer the hard questions, but I think I've got a reasonable answer for the easy one... > o what should the initial config be? cloned? multihead? single, > primary head with other heads initialized to a blank screen? The X server has some built-in policy for what the starting mode should look like. I think we should be able to build that into the kernel and leave more complicated policies to user-mode. 1. Identify outputs with 'preferred' modes. 2. If no preferred mode, pick an output, set it to 96dpi 3. All other outputs get the closest mode which is no larger than the mode selected above 4. Fit CRTCs to the output configuration by searching for the best match, scoring preferred modes 2, other modes 1, no mode 0. 5. Clone everybody. Cloning seems like the obviously right plan to me; we want to make the boot-up output visible, and we don't expect to need more than one screen. The worst thing that could happen in clone mode is that the user will see more than one copy of the boot messages. I'm looking forward to our new DRM overlords. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - 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
Re: Latest on modesetting
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
Re: Latest on modesetting
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
Re: Latest on modesetting
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");
-
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
Latest on modesetting
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). Comments? Questions? A huge amount of the credit for this stuff belongs to keithp and anholt for the excellent, high quality X and driver code they've been putting together recently, making porting and debugging that much easier. Thanks, Jesse - 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
