On Don, 2011-04-28 at 13:27 -0700, Jesse Barnes wrote:
> @@ -1114,7 +1169,7 @@ DRI2ScreenInit(ScreenPtr pScreen, DRI2InfoPtr info)
> ds->ScheduleSwap = info->ScheduleSwap;
> ds->ScheduleWaitMSC = info->ScheduleWaitMSC;
> ds->GetMSC = info->GetMSC;
> - cur_minor = 3;
> + c
On Fre, 2011-04-29 at 13:57 +1000, christopher.halse.rog...@canonical.com wrote:
> From: Christopher James Halse Rogers
>
> v2: Also pull out the drm_vblank_put call.
> Signed-off-by: Christopher James Halse Rogers
>
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer |
Hi,
while watching flash video in a browser I got:
irq 42: nobody cared (try booting with the "irqpoll" option)
Pid: 0, comm: swapper Tainted: GW 2.6.39-rc3-mm1_64+ #1423
Call Trace:
[] __report_bad_irq+0x31/0xc0
[] note_interrupt+0x194/0x1d0
[] handle_irq_event_percpu+0xe8/0x160
From: Christopher James Halse Rogers
v2: Also pull out the drm_vblank_put call.
Signed-off-by: Christopher James Halse Rogers
---
drivers/gpu/drm/drm_irq.c | 44 ++--
1 files changed, 18 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/drm_
On Thu, Apr 28, 2011 at 12:03:32PM -0500, Rob Clark wrote:
> On Mon, Apr 25, 2011 at 5:12 PM, Jesse Barnes
> wrote:
> > Looking for comments on this. ?Obviously if we're going to add a new type
> > of KMS object, we'd better get the ioctl more or less right to begin with,
> > which means having a
On Wed, Apr 27, 2011 at 11:12 PM, Jesse Barnes
wrote:
> On Wed, 27 Apr 2011 14:19:05 +0200
> Daniel Vetter 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 whe
On Apr 28, 2011, at 9:47 AM, Christopher James Halse Rogers wrote:
> On Wed, 2011-04-27 at 17:50 +0200, Mario Kleiner wrote:
>> On Apr 27, 2011, at 10:58 AM, dri-devel-request at lists.freedesktop.org
>> wrote:
>>> Message: 5
>>> Date: Wed, 27 Apr 2011 10:38:14 +0200
>>> From: Michel D?nzer
>>> S
OM_CRTC_ID ioctl, radeon uses
something different.
I'll see what I can come up with, but I don't think I'm sufficiently
familiar with the kms code to quickly come up with a nice API.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110428/5e64d8fc/attachment.pgp>
https://bugs.freedesktop.org/show_bug.cgi?id=36596
--- Comment #5 from Jason Cassell 2011-04-28 16:38:02
PDT ---
Created an attachment (id=46146)
--> (https://bugs.freedesktop.org/attachment.cgi?id=46146)
/proc/interrupts
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=em
https://bugs.freedesktop.org/show_bug.cgi?id=36596
--- Comment #5 from Jason Cassell 2011-04-28
16:38:02 PDT ---
Created an attachment (id=46146)
--> (https://bugs.freedesktop.org/attachment.cgi?id=46146)
/proc/interrupts
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=em
https://bugs.freedesktop.org/show_bug.cgi?id=36596
--- Comment #4 from Jason Cassell 2011-04-28 16:36:31
PDT ---
(In reply to comment #3)
> Does that involve wobbly windows or any other effects?
It's the same problem with and without wobbly windows.
One thing I noticed with wobbly windows is t
https://bugs.freedesktop.org/show_bug.cgi?id=36596
--- Comment #4 from Jason Cassell 2011-04-28
16:36:31 PDT ---
(In reply to comment #3)
> Does that involve wobbly windows or any other effects?
It's the same problem with and without wobbly windows.
One thing I noticed with wobbly windows is t
On Wed, 2011-04-27 at 23:20 -0600, Alex Williamson wrote:
> We're often using a shared interrupt line for nouveau, so we have
> to be prepared that it could be called at any point in time. If
> we've suspended the device via vga switcheroo and get a stray
> interrupt on the line from another devic
On Thu, 28 Apr 2011 13:27:19 -0700, Jesse Barnes
wrote:
> 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.
I
me: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110428/1bacbf2d/attachment.pgp>
On Thu, 28 Apr 2011 13:27:22 -0700, Jesse Barnes
wrote:
> 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
bit
event_type protocol. Seems like a reasonable approach.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110428/a42fc0d8/attachment-0001.pgp>
On Thu, 28 Apr 2011 14:33:58 -0700
Eric Anholt wrote:
> On Thu, 28 Apr 2011 13:27:19 -0700, Jesse Barnes
> wrote:
> > 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
On Thu, 28 Apr 2011 14:33:58 -0700
Eric Anholt wrote:
> On Thu, 28 Apr 2011 13:27:19 -0700, Jesse Barnes virtuousgeek.org> wrote:
> > 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 pack
On Thu, 28 Apr 2011 13:27:19 -0700, Jesse Barnes
wrote:
> 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.
>
CARD32 msc_hi B32;
> CARD32 msc_lo B32;
> CARD32 sbc_hi B32;
> -CARD32 sbc_lo B32;
> } xGLXBufferSwapComplete;
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110428/224366ee/attachment.pgp>
On Thu, 28 Apr 2011 13:46:30 -0700
Jesse Barnes wrote:
> On Thu, 28 Apr 2011 18:09:58 +1000
> Christopher James Halse Rogers
> wrote:
> > Ok. This appears to be surprisingly difficult. Particularly, the
> > vblank code indexes crtcs based on the driver-private numbering, and
> > there doesn't
On Thu, 28 Apr 2011 13:46:30 -0700
Jesse Barnes wrote:
> On Thu, 28 Apr 2011 18:09:58 +1000
> Christopher James Halse Rogers
> wrote:
> > Ok. This appears to be surprisingly difficult. Particularly, the
> > vblank code indexes crtcs based on the driver-private numbering, and
> > there doesn't
On Thu, 28 Apr 2011 18:09:58 +1000
Christopher James Halse Rogers
wrote:
> Ok. This appears to be surprisingly difficult. Particularly, the
> vblank code indexes crtcs based on the driver-private numbering, and
> there doesn't appear to be a generic interface to grab this number;
> Intel uses th
On Thu, 28 Apr 2011 18:09:58 +1000
Christopher James Halse Rogers
wrote:
> Ok. This appears to be surprisingly difficult. Particularly, the
> vblank code indexes crtcs based on the driver-private numbering, and
> there doesn't appear to be a generic interface to grab this number;
> Intel uses th
On Wed, 27 Apr 2011 10:32:36 +0200
Michel Dänzer wrote:
> On Mit, 2011-04-27 at 16:10 +1000, christopher.halse.rog...@canonical.com
> wrote:
> > From: Christopher James Halse Rogers
> >
> >
> > This is the least-bad behaviour. It means that we signal the
> > vblank event before it actually h
On Wed, 27 Apr 2011 10:32:36 +0200
Michel D?nzer wrote:
> On Mit, 2011-04-27 at 16:10 +1000, christopher.halse.rogers at canonical.com
> wrote:
> > From: Christopher James Halse Rogers > canonical.com>
> >
> > This is the least-bad behaviour. It means that we signal the
> > vblank event befor
On Wed, 27 Apr 2011 16:10:59 +1000
christopher.halse.rog...@canonical.com wrote:
> From: Christopher James Halse Rogers
>
> Signed-off-by: Christopher James Halse Rogers
>
> ---
> drivers/gpu/drm/drm_irq.c | 39 ---
> 1 files changed, 16 insertions(+), 23
On Wed, 27 Apr 2011 16:10:59 +1000
christopher.halse.rogers at canonical.com wrote:
> From: Christopher James Halse Rogers canonical.com>
>
> Signed-off-by: Christopher James Halse Rogers canonical.com>
> ---
> drivers/gpu/drm/drm_irq.c | 39 ---
> 1 files
On Wed, 27 Apr 2011 16:10:57 +1000
christopher.halse.rog...@canonical.com wrote:
> From: Christopher James Halse Rogers
>
> This is the least-bad behaviour. It means that we signal the
> vblank event before it actually happens, but since we're disabling
> vblanks there's no guarantee that it wi
On Wed, 27 Apr 2011 16:10:57 +1000
christopher.halse.rogers at canonical.com wrote:
> From: Christopher James Halse Rogers canonical.com>
>
> This is the least-bad behaviour. It means that we signal the
> vblank event before it actually happens, but since we're disabling
> vblanks there's no gu
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
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 best
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
--- a/configur
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 ++--
src/glx/dr
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 fi
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
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 ++--
src/glx/dr
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
--- a/configur
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 fi
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 best
Hi,
while watching flash video in a browser I got:
irq 42: nobody cared (try booting with the "irqpoll" option)
Pid: 0, comm: swapper Tainted: GW 2.6.39-rc3-mm1_64+ #1423
Call Trace:
[] __report_bad_irq+0x31/0xc0
[] note_interrupt+0x194/0x1d0
[] handle_irq_event_percpu+0xe8/0x160
On Mon, Apr 25, 2011 at 5:12 PM, Jesse Barnes
wrote:
> Looking for comments on this. ?Obviously if we're going to add a new type
> of KMS object, we'd better get the ioctl more or less right to begin with,
> which means having all the attributes we'd like to track, plus some
> padding, available
On Tue, Apr 26, 2011 at 5:01 AM, Alan Cox wrote:
>> A lot of older hardware had one overlay that could be sourced to any
>> crtc, just not simultaneously. ?The tricky part is the formats and
>> capabilities: alpha blending, color/chromakey, gamma correction, etc.
>> Even the current crtc gamma stu
2011/4/25 St?phane Marchesin :
> On Mon, Apr 25, 2011 at 16:22, Jesse Barnes
> wrote:
>> On Mon, 25 Apr 2011 16:16:18 -0700
>> Keith Packard wrote:
>>
>>> On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes >> virtuousgeek.org> wrote:
>>>
>>> > Overlays are a bit like half-CRTCs. ?They have a locat
On Thu, Apr 28, 2011 at 12:03:32PM -0500, Rob Clark wrote:
> On Mon, Apr 25, 2011 at 5:12 PM, Jesse Barnes
> wrote:
> > Looking for comments on this. Obviously if we're going to add a new type
> > of KMS object, we'd better get the ioctl more or less right to begin with,
> > which means having a
On Wed, Apr 27, 2011 at 11:12 PM, Jesse Barnes wrote:
> On Wed, 27 Apr 2011 14:19:05 +0200
> Daniel Vetter 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 whet
On Mon, Apr 25, 2011 at 5:12 PM, Jesse Barnes wrote:
> Looking for comments on this. Obviously if we're going to add a new type
> of KMS object, we'd better get the ioctl more or less right to begin with,
> which means having all the attributes we'd like to track, plus some
> padding, available f
On Apr 28, 2011, at 9:47 AM, Christopher James Halse Rogers wrote:
On Wed, 2011-04-27 at 17:50 +0200, Mario Kleiner wrote:
On Apr 27, 2011, at 10:58 AM, dri-devel-requ...@lists.freedesktop.org
wrote:
Message: 5
Date: Wed, 27 Apr 2011 10:38:14 +0200
From: Michel D?nzer
Subject: Re: [PATCH 2/3]
On Tue, Apr 26, 2011 at 5:01 AM, Alan Cox wrote:
>> A lot of older hardware had one overlay that could be sourced to any
>> crtc, just not simultaneously. The tricky part is the formats and
>> capabilities: alpha blending, color/chromakey, gamma correction, etc.
>> Even the current crtc gamma stu
2011/4/25 Stéphane Marchesin :
> On Mon, Apr 25, 2011 at 16:22, Jesse Barnes wrote:
>> On Mon, 25 Apr 2011 16:16:18 -0700
>> Keith Packard wrote:
>>
>>> On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes
>>> wrote:
>>>
>>> > Overlays are a bit like half-CRTCs. They have a location and fb, but
>>
On Wed, Apr 27, 2011 at 11:12 PM, Jesse Barnes
wrote:
> On Wed, 27 Apr 2011 14:19:05 +0200 Daniel Vetter wrote:
>> Imo the real problem with formats is stride restrictions and other hw
>> restrictions (tiling, ...).
>> ARM/v4l people seem to want that to be in the kernel so that they can
>> e.g.
ollowing patch fix tarball creation again (removed files and one
missing Makefile)
-- next part --
A non-text attachment was scrubbed...
Name: fix-tarball-again.diff
Type: text/x-patch
Size: 808 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110428/e9cc31d2/attachment.bin>
ning is appropriate there.
But at this point the vblank interrupts have been disabled, or at least
the driver's disable function has been called. Will that not mean that
any pending pageflips will wait indefinitely for a vblank interrupt
that's not going to come - ie: exactly the state we're warning against?
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110428/31165f16/attachment.pgp>
On Thu, 2011-04-28 at 15:54 +1000, Dave Airlie wrote:
> On Wed, 2011-04-27 at 23:20 -0600, Alex Williamson wrote:
> > We're often using a shared interrupt line for nouveau, so we have
> > to be prepared that it could be called at any point in time. If
> > we've suspended the device via vga switche
On Thu, 2011-04-28 at 15:54 +1000, Dave Airlie wrote:
> On Wed, 2011-04-27 at 23:20 -0600, Alex Williamson wrote:
> > We're often using a shared interrupt line for nouveau, so we have
> > to be prepared that it could be called at any point in time. If
> > we've suspended the device via vga switche
Nothing major, everyone must be on Easter holidays, the i915 one is
actually a fix for dual-gpu laptops where i915 caused radeon to do
something bad, the Kconfig one is because I see distros don't enable this
and its really needed for dual-gpu functionality to work at all.
Otherwise, just a co
On Wed, 2011-04-27 at 11:08 +0200, Michel Dänzer wrote:
> On Mit, 2011-04-27 at 18:58 +1000, Christopher James Halse Rogers
> wrote:
> > On Wed, 2011-04-27 at 10:32 +0200, Michel Dänzer wrote:
> > > On Mit, 2011-04-27 at 16:10 +1000, christopher.halse.rog...@canonical.com
> > > wrote:
> > > > Fro
... instead of comparing with DMA_ERROR_CODE, which will only work on
powerpc/sparc/x86.
Signed-off-by: Aurelien Jarno
---
drivers/gpu/drm/nouveau/nouveau_sgdma.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
b/drivers/gpu/drm
... instead of comparing with DMA_ERROR_CODE, which will only work on
powerpc/sparc/x86.
Signed-off-by: Aurelien Jarno
---
drivers/gpu/drm/radeon/radeon_gart.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon
On Wed, Apr 27, 2011 at 05:49:50PM +1000, Dave Airlie wrote:
> On Wed, Apr 27, 2011 at 3:34 PM, Aurelien Jarno wrote:
> > ... instead of comparing with DMA_ERROR_CODE, which will only work on
> > powerpc/sparc/x86.
> >
>
> So you wrote a patch that breaks it everwhere?
It seems I inverted the co
On Wed, 2011-04-27 at 17:50 +0200, Mario Kleiner wrote:
> On Apr 27, 2011, at 10:58 AM, dri-devel-requ...@lists.freedesktop.org
> wrote:
> > Message: 5
> > Date: Wed, 27 Apr 2011 10:38:14 +0200
> > From: Michel D?nzer
> > Subject: Re: [PATCH 2/3] drm: Warn if vblank state has become
> > inco
62 matches
Mail list logo
