Using 2.6.35.7 (this patch is against drm-intel-next 7dcd249, but untested),
I changed 945's self refresh to work without the need for the driver to
enable/disable self refresh manually based on the idle state of the gpu.
This is much better than enabling/disabling self refresh for various
reasons
On Mon, Oct 4, 2010 at 7:43 PM, Keith Packard wrote:
> +.BI "Option \*qHotplug\*q \*q" boolean \*q
> ...
> + {OPTION_HOTPLUG, "HotPlug", OPTV_BOOLEAN, {0}, TRUE},
It probably doesn't matter, but it would be nice to be consistent with
the captialization. "Hotplug" or "HotPlug".
Gei
On Mon, 4 Oct 2010 20:13:33 +1000, Dave Airlie wrote:
> We don't do dynamic connectors now, so adding locking with no way of
> actually really testing it would just mean you'd probably have just as
> much pain when you do add dyanamic connectors.
I looked in the radeon and nouveau drivers and bo
From: Adam Jackson
This connects the kernel uevent indicating monitor hotplugging to the
RandR notification events so that X applications can be notified
automatically when monitors are connected or disconnected.
This also adds a configuration option to disable hotplug events.
V2: missed a #ifd
On Mon, 4 Oct 2010 15:13:17 +0200
Jan-Hendrik Zab wrote:
> On 03/10/10 08:04 -0700, Jesse Barnes wrote:
> > On Thu, 2 Sep 2010 23:37:26 +0800
> > Zhenyu Wang wrote:
> [snip]
> > > Adam, I believe this one causes regression on PCH eDP port as
> > > for bug 27220. It changes behavior in mode_set p
On Mon, Oct 4, 2010 at 1:08 AM, Keith Packard wrote:
> From: Adam Jackson
> ...
> +++ b/src/intel_driver.c
> @@ -107,6 +107,7 @@ typedef enum {
> OPTION_DEBUG_FLUSH_BATCHES,
> OPTION_DEBUG_FLUSH_CACHES,
> OPTION_DEBUG_WAIT,
> + OPTION_HOTPLUG,
> } I830Opts;
>
> static OptionInfoRec I
On Sun, 03 Oct 2010 16:06:07 -0700, Keith Packard wrote:
> On Sun, 03 Oct 2010 22:05:13 +0100, Chris Wilson
> wrote:
>
> > It appears that all users (crtc and encoders) are tracking dpms_mode, in
> > one form or another. Should we move this to core?
>
> Sounds like a good idea. Would you prefe
On Mon, Oct 4, 2010 at 6:49 PM, Chris Wilson wrote:
> On Sun, 3 Oct 2010 19:36:26 -0700, Keith Packard wrote:
>> Cancel the output polling work proc before acquiring the struct mutex
>> to avoid acquiring the work proc mutex with the struct mutex
>> held. This avoids inverting the lock order see
On Sun, 3 Oct 2010 19:36:26 -0700, Keith Packard wrote:
> Cancel the output polling work proc before acquiring the struct mutex
> to avoid acquiring the work proc mutex with the struct mutex
> held. This avoids inverting the lock order seen when the work proc
> runs.
I thought this was part of D
On Sun, 3 Oct 2010 16:08:16 -0700, Keith Packard wrote:
> From: Adam Jackson
>
> This connects the kernel uevent indicating monitor hotplugging to the
> RandR notification events so that X applications can be notified
> automatically when monitors are connected or disconnected.
The obvious que
On 03/10/10 08:04 -0700, Jesse Barnes wrote:
> On Thu, 2 Sep 2010 23:37:26 +0800
> Zhenyu Wang wrote:
[snip]
> > Adam, I believe this one causes regression on PCH eDP port as
> > for bug 27220. It changes behavior in mode_set path to program
> > FDI link properly.
> >
> > I think above part shou
11 matches
Mail list logo