, 2010-05-21 at 15:02 -0700, Jesse Barnes wrote:
On Sat, 22 May 2010 00:57:30 +0300
Maxim Levitsky maximlevit...@gmail.com wrote:
On Fri, 2010-05-21 at 00:14 +0300, Maxim Levitsky wrote:
On Thu, 2010-05-20 at 09:28 -0700, Jesse Barnes wrote:
On Thu, 20 May 2010 04:27:07 +0300
On Sun, 6 Jun 2010 17:36:24 +0100 (BST)
James Simmons jsimm...@infradead.org wrote:
On Fri, 9 Apr 2010 15:10:50 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
This set of 3 patches makes it a little more likely we'll get panic
output onto the screen even when X is running
to unbind the fbcon interface
first, my script is like this:
echo 0 /sys/class/vtconsole/vtcon1/bind
rmmod i915
rmmod drm_kms_helper
rmmod drm
modprobe i915
echo 1 /sys/class/vtconsole/vtcon1/bind
If unload and re-load doesn't work please file a bug and see if you can
bisect it.
Thanks,
--
Jesse
Allows us to track each process that requests and completes events.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/drm_irq.c |8 ++
drivers/gpu/drm/drm_trace.h | 57 --
include/drm/drmP.h |2 +
3 files
).
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index b3779d2..32f67cb 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -315,8 +315,9 @@ static void drm_fb_helper_on(struct fb_info
. Much of the
drm source has doxygen rather than kdoc style comments though, I need
to clean those up before I can actually include the source generated
info in the drm.tmpl.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing
information
over the IPC that needs to be performed anyway in order to open a surface.
That's the part I had trouble with as well. Passing the blob through
the kernel saves a little IPC but also seems unnecessary, and so rubs
against my kernel minimalist side...
--
Jesse Barnes, Intel Open Source
configuration into something they couldn't change. :)
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman
Make drm_edid_read take a new argument, edid_read, to allow drivers to
provide their own EDID fetch routine. Export the bit banging DDC over
i2c version of the EDID fetching routine and make the drivers use it.
This sets the stage for GMBUS support in the Intel driver.
Signed-off-by: Jesse
Use the GMBUS interface rather than direct bit banging to grab the EDID
over DDC. The hope is that this method will be more reliable than bit
banging for fetching EDIDs from buggy monitors or through switches.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915
On Wed, 21 Jul 2010 08:54:30 +1000
Dave Airlie airl...@redhat.com wrote:
On Tue, 2010-07-20 at 15:44 -0700, Jesse Barnes wrote:
Make drm_edid_read take a new argument, edid_read, to allow drivers to
provide their own EDID fetch routine. Export the bit banging DDC over
i2c version
On Wed, 21 Jul 2010 09:27:54 +1000
Dave Airlie airl...@redhat.com wrote:
On Tue, 2010-07-20 at 16:05 -0700, Jesse Barnes wrote:
On Wed, 21 Jul 2010 08:54:30 +1000
Dave Airlie airl...@redhat.com wrote:
On Tue, 2010-07-20 at 15:44 -0700, Jesse Barnes wrote:
Make drm_edid_read take
On Tue, 20 Jul 2010 16:34:39 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Wed, 21 Jul 2010 09:27:54 +1000
Dave Airlie airl...@redhat.com wrote:
On Tue, 2010-07-20 at 16:05 -0700, Jesse Barnes wrote:
On Wed, 21 Jul 2010 08:54:30 +1000
Dave Airlie airl...@redhat.com wrote
, whitespace isn't top of my
priorities most days.
I think you should just reject it, unless it comes as part of a series
with actual work in it. At least that's been my policy lately...
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel
flush any previous writes to
shut off the pipe before waiting. So adding a POSTING_READ() above it
might help? But that still doesn't explain why it would cause the
hangcheck timer to notice a hang...
--
Jesse Barnes, Intel Open Source Technology Center
here now? Can you
check and see if we're timing out in the wait_for_vblank function?
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
bytesperline;
if (dev == NULL) {
em28xx_isocdbg(dev is null\n);
return;
}
+ bytesperline = dev-vbi_width;
if (dma_q == NULL) {
em28xx_isocdbg(dma_q is null\n);
Look fine to me.
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
shouldn't change behavior since we ought to
time out on waiting on vblank in that case, and the timeout is the same
as the msleep we used to use.
The second one looks like a good change, but really the pipe off change
is separate from the plane disable bug fix.
--
Jesse Barnes, Intel Open Source
Keith Packard kei...@keithp.com wrote:
On Sun, 3 Oct 2010 08:10:48 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Do these fixes help with the DP issues you've been seeing, Keith?
Seems like the first one shouldn't change behavior since we ought to
time out on waiting on vblank
trying to run 'xrandr' again.
don't you do this already? both radeon/nouveau handle DP replug fine,
I thought Intel would have been where I stole the code from.
There is some code to handle the interrupts, but I'm not sure if it's wired up.
I think we rely on polling right now.
--
Jesse Barnes
() call to pass an argument
to indicate if this is an entry or an exit from an atomic kernel mode
set change. Individual drm drivers can properly save and restore
state accordingly.
Signed-off-by: Jason Wessel jason.wes...@windriver.com
CC: Jesse Barnes jbar...@virtuousgeek.org
CC: David
in
the !HAS_PCH_SPLIT case. Does this patch achieve the same thing as
yours? Maybe we were leaving a stale PFIT value in place...
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds
index f1a6499..bc1e1c1 100644
On Mon, 18 Oct 2010 21:13:59 +0200
Arnd Bergmann a...@arndb.de wrote:
On Monday 18 October 2010 20:56:48 Jesse Barnes wrote:
Hm, the LVDS code should take care of panel fitting in
the !HAS_PCH_SPLIT case. Does this patch achieve the same thing as
yours? Maybe we were leaving a stale PFIT
On Mon, 18 Oct 2010 21:57:05 +0200
Arnd Bergmann a...@arndb.de wrote:
On Monday 18 October 2010 21:28:01 Jesse Barnes wrote:
On Mon, 18 Oct 2010 21:13:59 +0200
Arnd Bergmann a...@arndb.de wrote:
On Monday 18 October 2010 20:56:48 Jesse Barnes wrote:
Hm, the LVDS code should take
or init_display once we've
figured out there's no LVDS. It's cool that the panel fitter still has
an effect even on non-LVDS platforms though, maybe we really should
treat it as a part of the CRTC rather than the LVDS encoder after all.
--
Jesse Barnes, Intel Open Source Technology Center
to volunteer to maintain this subsystem (I know
how much you love backlights, maybe you'd like to do it?) or you need to
get this patch over to akpm.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel
On Wed, 1 Dec 2010 19:41:31 +
Chris Wilson ch...@chris-wilson.co.uk wrote:
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Kristian Høgsberg k...@bitplanet.net
Cc: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/drm_irq.c | 19 ++-
1 files changed
},
{ DRM_MODE_CONNECTOR_LVDS, LVDS, 0 },
{ DRM_MODE_CONNECTOR_Component, Component, 0 },
- { DRM_MODE_CONNECTOR_9PinDIN, 9-pin DIN, 0 },
What kernel version did these options first show up in? Does any
other tools rely on the spaces?
And it's ugly; can't we fix grub instead?
--
Jesse Barnes, Intel Open
approximately nothing about libdrm or
any userspace graphics stuff whatsoever.
Yeah, libdrm has a test program called vbltest; it should do what you
need.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel
routing.
Acked-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
: Aggressively disable vblanks
To: Andy Lutomirski l...@mit.edu, Jesse Barnes
jbar...@virtuousgeek.org, Chris Wilson ch...@chris-wilson.co.uk,
David Airlie airl...@linux.ie
Cc: intel-...@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Message-ID: yunfwtrrepv
).
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
) || IS_GEN6(dev))
+ dev_priv-lvds_use_ssc = 0;
if (dev_priv-lvds_use_ssc) {
if (IS_I85X(dev))
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel
power
related. Can you try this patch?
If it doesn't work, can you send me the output of intel_reg_dumper from
before you turn off the display and after you try to turn it back on?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b
report was incorrect --
I was using -rc7 when I thought I was using -rc8. :(
Can you confirm that the above doesn't break your setup just in case we
need to apply it?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing
On Thu, 30 Dec 2010 00:09:56 +0100
Alex Riesen raa.l...@gmail.com wrote:
On Wed, Dec 29, 2010 at 22:53, Jesse Barnes jbar...@virtuousgeek.org wrote:
Doesn't change anything here. Display stays blank.
Sounds like your problem is separate from SSC then, more likely related
to panel power
On Thu, 30 Dec 2010 00:35:15 +0100
Alex Riesen raa.l...@gmail.com wrote:
On Thu, Dec 30, 2010 at 00:20, Alex Riesen raa.l...@gmail.com wrote:
On Thu, Dec 30, 2010 at 00:13, Jesse Barnes jbar...@virtuousgeek.org
wrote:
After closing and opening the lid (displays backlight is back
On Thu, 30 Dec 2010 10:49:33 +0800 (SGT)
Jeff Chua jeff.chua.li...@gmail.com wrote:
On Thu, Dec 30, 2010 at 4:16 AM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Randy, Jeff and Alex, does the below help at all? If so, it may be the
minimal fix we want for 2.6.37.
Jesse,
Yes
these needs? It would be a
bigger API, but presumably would allow us to share fbs between early
boot and subsequent, accelerated usage. We'd still need to settle on
the basic allocation API, but we seem to manage that on the server
side...
--
Jesse Barnes, Intel Open Source Technology Center
help any?
Dave.
Arg. It's been ok on my ILK systems, but Chris has found some issues with out
watermarking code iirc; apparently we're underflowing the display FIFO, causing
all sorts of trouble. If it works before the pull of Dave's tree, can you
bisect?
Thanks,
--
Jesse Barnes, Intel Open
to trigger the watermark related issues
you've found?
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, 11 Jan 2011 11:25:39 -0800
Linus Torvalds torva...@linux-foundation.org wrote:
On Tue, Jan 11, 2011 at 11:12 AM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Have you tried reproducing it using xset dpms force off or similar?
That doesn't seem to do anything bad.
In fact, I
On Wed, 12 Jan 2011 14:31:33 -0800
Linus Torvalds torva...@linux-foundation.org wrote:
On Wed, Jan 12, 2011 at 2:22 PM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Ah, ok. So it could be our internal FDI link is underrunning; it goes
between the CPU and PCH and carries display bits
for rc6, though we probably should.
The bisect is interesting, I'd have expected a failure when we
re-enabled rc6 on ILK or when we fixed up the ring buffer init.
The cleanup patch should be just that, but at least reverting it
shouldn't cause any trouble.
--
Jesse Barnes, Intel Open Source
On Tue, 01 Feb 2011 16:57:37 +
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Tue, 1 Feb 2011 08:31:12 -0800, Jesse Barnes jbar...@virtuousgeek.org
wrote:
The bisect is interesting, I'd have expected a failure when we
re-enabled rc6 on ILK or when we fixed up the ring buffer init
the cleanup wasn't sufficient?
Francesco, if you revert the cleanup patch you bisected to, what
does /sys/kernel/debug/dri/0/i915_drpc_info report?
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
On Wed, 9 Feb 2011 09:50:47 -0800
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Wed, 09 Feb 2011 17:09:10 +
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Wed, 9 Feb 2011 13:52:38 +0100, Francesco Allertsen
fallert...@gmail.com wrote:
On Wed, Feb 02, 2011 at 09:59:54AM +
On Wed, 9 Feb 2011 09:53:26 -0800
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Wed, 9 Feb 2011 09:50:47 -0800
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Wed, 09 Feb 2011 17:09:10 +
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Wed, 9 Feb 2011 13:52:38 +0100, Francesco
,
--
Jesse Barnes, Intel Open Source Technology Center
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1018,6 +1018,8 @@ static int i915_drpc_info(struct seq_file *m, void *unused
break;
}
+ seq_printf(m, RSTDBYCTL: 0x%08x\n
On Fri, 11 Feb 2011 08:28:37 +0100
Francesco Allertsen fallert...@gmail.com wrote:
On Thu, Feb 10, 2011 at 03:25:33PM -0800, Jesse Barnes wrote:
Does this kernel have the problem patch included? Or is it reverted?
That was without the patch reverted, now I've reverted
On Thu, 3 Mar 2011 17:34:53 -0600 (CST)
Ilija Hadzic ihad...@research.bell-labs.com wrote:
The fix/improvement I propose is to extend the request.type field
in drmVBlank structure with additional 5 bits that I call high_crtc
(there are lots of unused bits in that field). 5 bits covers for 32
On Fri, 11 Mar 2011 02:35:45 +0100 (CET)
Indan Zupancic in...@nul.nu wrote:
drm/i915: Fix DPMS and suspend interaction for intel_panel.c
When suspending intel_panel_disable_backlight() is never called,
but intel_panel_enable_backlight() is called at resume. With the
effect that if the
think we need a more generous sprinkling of those around the CRTC
helper code in general...
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri
to get pulled out into
a separate function...
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
ioctl to abusing
the old one.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Fri, 18 Mar 2011 18:13:11 -0500 (CDT)
Ilija Hadzic ihad...@research.bell-labs.com wrote:
On Fri, 18 Mar 2011, Jesse Barnes wrote:
I like the new param check, but I'd still prefer a new ioctl to abusing
the old one.
It's not abusing it but extending the interface
On Mon, 21 Mar 2011 19:19:43 +
timofonic timofonic timofo...@gmail.com wrote:
So if KMS is so cool and provides many advantages over fbdev and
such... Why isn't more widely used intead of still relying on fbdev?
Why still using fbdev emulation (that is partial and somewhat broken,
it
On Mon, 21 Mar 2011 20:50:20 +0100
Geert Uytterhoeven ge...@linux-m68k.org wrote:
On Mon, Mar 21, 2011 at 20:25, Jesse Barnes jbar...@virtuousgeek.org wrote:
On Mon, 21 Mar 2011 19:19:43 +
timofonic timofonic timofo...@gmail.com wrote:
So if KMS is so cool and provides many advantages
makes reallocation of the framebuffer
somewhat difficult.
IIRC plymouth or whatever Fedora is using these days uses the KMS APIs
though...
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
features it would provide (output
management, memory management, execution management)
3) its got documentation
Jeez, some people want it all.
You looking for docs for the ioctls and such?
--
Jesse Barnes, Intel Open Source Technology Center
the assertion checks we
have now, so we may have just been masking other problems without
knowing it.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman
. We could be meaner about
things and SIGILL the app, but often it's an innocent bystander, and
the real problem is kernel object synchronization and/or the DRI driver
generating bad commands.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri
, but it does seem a likely candidate.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
userspace is forward and backward compatible). This is more
work for us, but I think it benefits the user in the end. And it could
be worse, at least we're not still dealing with memory layout
compatibility between the DRM, fbdev, DDX and DRI drivers anymore!
--
Jesse Barnes, Intel Open Source
, I've split it into separate
functions entirely, leaving the old one alone. If, after awhile we've
decided that they really are mostly the same and we have things working
well, we can consider merging them again, but only after extensive
testing across generations.
--
Jesse Barnes, Intel Open Source
the same as above)
Hm, ok so on resume we're checking GPU busyness, which is normal, but
end up hanging on the spinlock? Do you see what scrolls by above the
text you took a picture of (probably a task hung message?).
Does this happen reliably? Does a previous kernel work ok?
--
Jesse Barnes
On Sat, 2 Apr 2011 09:24:10 +0900
Norbert Preining prein...@logic.at wrote:
Hm, ok so on resume we're checking GPU busyness, which is normal,
but end up hanging on the spinlock? Do you see what scrolls by
above the text you took a picture of (probably a task hung
message?).
More than
We've already seen that apps want to monitor the display config, and
some (like upowerd) poll for changes since we don't provide a
notification for general mode config changes, just hotplug events. So
add a new drm event, with CHANGE=1 set in the event, to allow for it.
Signed-off-by: Jesse
EDID 1.4 digital monitors report the bit depth supported in the input
field. Add support for parsing this out and storing the info in the
display_info structure for use by drivers.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/drm_edid.c | 54
EDID 1.4 digital displays report the color spaces they support in the
features block. Add support for grabbing this data and stuffing it into
the display_info struct for driver use.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/drm_edid.c | 10 ++
include
On Fri, 15 Apr 2011 15:13:02 -0400
Adam Jackson a...@redhat.com wrote:
On 4/15/11 2:40 PM, Jesse Barnes wrote:
@@ -1461,6 +1462,15 @@ static void drm_add_display_info(struct edid *edid,
info-bpp = 0;
break;
}
+
+ if (edid-features DRM_EDID_FEATURE_RGB
On Fri, 15 Apr 2011 14:29:50 -0400
Adam Jackson a...@redhat.com wrote:
On 4/15/11 2:22 PM, Jesse Barnes wrote:
EDID 1.4 digital monitors report the bit depth supported in the input
field. Add support for parsing this out and storing the info in the
display_info structure for use
On Fri, 15 Apr 2011 12:19:31 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Fri, 15 Apr 2011 15:13:02 -0400
Adam Jackson a...@redhat.com wrote:
info-color_formats = DRM_COLOR_FORMAT_RGB444;
if (edid-features DRM_EDID_FEATURE_YCRCB444)
info-color_formats
On Fri, 15 Apr 2011 15:36:22 -0400
Adam Jackson a...@redhat.com wrote:
On 4/15/11 3:19 PM, Jesse Barnes wrote:
Or is there a CEA block extension that allows for more granularity?
CEA has bits for the two YCbCr formats too, which we should also parse
since there's plenty of 1.3+CEA
EDID 1.4 digital monitors report the bit depth supported in the input
field. Add support for parsing this out and storing the info in the
display_info structure for use by drivers.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/drm_edid.c | 55
be fairly extensible if new surface formats were added.
Maybe you're thinking it's not enough to support all the misc ones out
there though?
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
On Sat, 16 Apr 2011 06:42:44 +1000
Dave Airlie airl...@gmail.com wrote:
On Sat, Apr 16, 2011 at 6:39 AM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Sat, 16 Apr 2011 06:10:07 +1000
Dave Airlie airl...@gmail.com wrote:
-
+#define DRM_COLOR_FORMAT_RGB444 (10
EDID 1.4 digital displays report the color spaces they support in the
features block. Add support for grabbing this data and stuffing it into
the display_info struct for driver use.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/drm_edid.c |6 ++
include/drm
On Sat, 16 Apr 2011 06:42:44 +1000
Dave Airlie airl...@gmail.com wrote:
On Sat, Apr 16, 2011 at 6:39 AM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Sat, 16 Apr 2011 06:10:07 +1000
Dave Airlie airl...@gmail.com wrote:
-
+#define DRM_COLOR_FORMAT_RGB444 (10
to make sure you didn't want other changes.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
an overlay object instead of a CRTC.
Overlays are a bit like half-CRTCs. They have a location and fb, but
don't drive outputs directly. Add support for handling them to the core
KMS code.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/drm_crtc.c | 219
On Mon, 25 Apr 2011 16:16:18 -0700
Keith Packard kei...@keithp.com wrote:
On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Overlays are a bit like half-CRTCs. They have a location and fb, but
don't drive outputs directly. Add support for handling them
On Mon, 25 Apr 2011 16:35:20 -0700
Stéphane Marchesin stephane.marche...@gmail.com wrote:
On Mon, Apr 25, 2011 at 16:22, Jesse Barnes jbar...@virtuousgeek.org wrote:
On Mon, 25 Apr 2011 16:16:18 -0700
Keith Packard kei...@keithp.com wrote:
On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes
On Mon, 25 Apr 2011 16:37:46 -0700
Keith Packard kei...@keithp.com wrote:
On Mon, 25 Apr 2011 16:22:16 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Yes, that matches my understanding as well. I've deliberately made the
implementation flexible there though, under the assumption
On Mon, 25 Apr 2011 20:28:20 -0400
Alex Deucher alexdeuc...@gmail.com wrote:
On Mon, Apr 25, 2011 at 7:22 PM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Mon, 25 Apr 2011 16:16:18 -0700
Keith Packard kei...@keithp.com wrote:
On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes
jbar
it seems a
logical path ?
Thanks Alan, of course that's a good idea, I'll see about integrating
the two.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org
On Tue, 26 Apr 2011 18:20:03 +0300
Ville Syrjälä syrj...@sci.fi wrote:
On Mon, Apr 25, 2011 at 04:16:18PM -0700, Keith Packard wrote:
On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Overlays are a bit like half-CRTCs. They have a location and fb
On Wed, 27 Apr 2011 14:19:05 +0200
Daniel Vetter dan...@ffwll.ch wrote:
Hi Jesse,
I like it. It's a bit of a chicken-egg api design problem, but if a
proof-of-concept
implementation exists for an embedded chip plus something to check whether
it's good enough to implement Xv on ancient hw
The defintion of the swap complete event was wrong; XEvents are only 32
bytes long, and with padding the swap event was longer. So use some
creative packing to get all the bits we want transmitted. Requires a
proto version bump.
---
configure.ac |2 +-
glxproto.h | 13 +
2
The swap complete event wasn't being handled fully; because XEvents are
only 32 bytes long, we were getting junk for the sbc_lo value. If the
server supports it, unpack the new structure, otherwise just return 0
for the sbc value instead of garbage.
---
configure.ac|4 ++--
XEvents are limited to 32 bytes, so use some creative stuffing to fit
all the bits we'd like to supply.
---
configure.ac |2 +-
dri2proto.h |9 +
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/configure.ac b/configure.ac
index 5b78d6b..9505f56 100644
---
I obviously failed to count the swap event structure size after adding
and removing fields a few times, and didn't even account for padding. The
end result is that clients today won't receive the sbc_lo field at all,
and so will likely stuff junk into that field on the client side (or
zero at
Use the new swap event structure packing and send it to the client if
possible. This means tracking client version information when clients
connect. If they don't support the new packing, they'll get the old
bits and fill junk into their sbc values when they receive the event.
If they do support
);
wake_up_interruptible(e-base.file_priv-event_wait);
trace_drm_vblank_event_delivered(e-base.pid, e-pipe,
e-event.sequence);
could be pulled out into a separate function for both to use.
--
Jesse Barnes, Intel Open
that,
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
same for the first patch now that you've addressed my cleanup issue.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
to
drm_vblank_get failing (i.e. the driver enable_vblank hook should fail
if the corresponding crtc is off). At least that's how it's supposed
to work.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel
the refcount was nonzero at
this point?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, 28 Apr 2011 13:46:30 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Thu, 28 Apr 2011 18:09:58 +1000
Christopher James Halse Rogers christopher.halse.rog...@canonical.com
wrote:
Ok. This appears to be surprisingly difficult. Particularly, the
vblank code indexes crtcs based
On Fri, 29 Apr 2011 09:20:31 +0200
Julien Cristau jcris...@debian.org wrote:
On Thu, Apr 28, 2011 at 13:27:22 -0700, Jesse Barnes wrote:
diff --git a/glx/glxdri2.c b/glx/glxdri2.c
index d979717..654b4ae 100644
--- a/glx/glxdri2.c
+++ b/glx/glxdri2.c
@@ -192,8 +192,17
On Thu, 28 Apr 2011 13:27:18 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
I obviously failed to count the swap event structure size after adding
and removing fields a few times, and didn't even account for padding. The
end result is that clients today won't receive the sbc_lo field
1 - 100 of 836 matches
Mail list logo
