Thomas,
What you describe sounds reasonable and I'll look into updating the
patch. I'm not too keen on the driver specific flag you suggest,
since it makes it hard to use the ioctl in generic code. Maybe
drivers that can do pageflip from one of several fifos can expose a
driver specific ioctl
Kristian Høgsberg wrote:
Thomas,
What you describe sounds reasonable and I'll look into updating the
patch. I'm not too keen on the driver specific flag you suggest,
since it makes it hard to use the ioctl in generic code. Maybe
drivers that can do pageflip from one of several fifos can
Thomas Hellström skrev:
I described this in more detail and hopefully more coherently in my
email to Michel. If that's still not clear, follow up there.
I've read the mail and understand the proposal, thanks.
/Thomas
So, I've been doing some thinking over the weekend and
Kristian Høgsberg skrev:
2009/8/27 Thomas Hellström tho...@shipmail.org:
Kristian Høgsberg skrev:
---
Okay, here's the patch again with the locking fixed. Everything else is
the same. As for the potential problem with polling on the drm fd with
both dri1 and dri2 enabled, I
On Thu, 2009-08-27 at 17:33 -0400, Kristian Høgsberg wrote:
2009/8/27 Thomas Hellström tho...@shipmail.org:
b) It requires the master to act as a scheduler, and circumvents the DRM
command submission mechanism through the delayed unpin callback. If this
is to workaround any inability of
Thomas Hellström skrev:
What's protecting file_priv-event_list here?
You can test for list emptiness without taking the lock.
Are you suggesting accessing a member of a mutex protected struct
without taking the mutex?
Do you have a pointer to where
Michel Dänzer skrev:
On Thu, 2009-08-27 at 17:33 -0400, Kristian Høgsberg wrote:
2009/8/27 Thomas Hellström tho...@shipmail.org:
b) It requires the master to act as a scheduler, and circumvents the DRM
command submission mechanism through the delayed unpin callback. If this
is to
On Fri, Aug 28, 2009 at 5:19 AM, Michel Dänzermic...@daenzer.net wrote:
On Thu, 2009-08-27 at 17:33 -0400, Kristian Høgsberg wrote:
2009/8/27 Thomas Hellström tho...@shipmail.org:
b) It requires the master to act as a scheduler, and circumvents the DRM
command submission mechanism through
On Fri, 2009-08-28 at 08:57 -0400, Kristian Høgsberg wrote:
On Fri, Aug 28, 2009 at 5:19 AM, Michel Dänzermic...@daenzer.net wrote:
On Thu, 2009-08-27 at 17:33 -0400, Kristian Høgsberg wrote:
2009/8/27 Thomas Hellström tho...@shipmail.org:
b) It requires the master to act as a
On Fri, 28 Aug 2009 15:14:47 +0200
Michel Dänzer mic...@daenzer.net wrote:
One possible solution for this would be for the DRI2SwapBuffer request
to return the suggested set of buffers for the next frame, and then
for the client to block (which could involve a DRM event or whatever
if just
On Fri, 28 Aug 2009 10:08:10 +0200
Thomas Hellström tho...@shipmail.org wrote:
Why then exactly are events needed? and why are we required to track
the progress of the command fifo with events like jbarnes suggests,
and finally why is this mechanism not needed in the non-pageflipping
case? If
This mail is getting out of control... too many sub-threads going
on... maybe we shold break it out and talk about events vs kernel
scheduling and wait with the patch review until we've figured
something out.
2009/8/28 Thomas Hellström tho...@shipmail.org:
Kristian Høgsberg skrev:
2009/8/27
Kristian Høgsberg skrev:
This mail is getting out of control... too many sub-threads going
on... maybe we shold break it out and talk about events vs kernel
scheduling and wait with the patch review until we've figured
something out.
Sure.
b) It requires the master to act as a
Kristian Høgsberg skrev:
---
Okay, here's the patch again with the locking fixed. Everything else is
the same. As for the potential problem with polling on the drm fd with
both dri1 and dri2 enabled, I suggest that we just disable the dri1
sigio handler in the xserver. We'll do this in a
2009/8/27 Thomas Hellström tho...@shipmail.org:
Kristian Høgsberg skrev:
---
Okay, here's the patch again with the locking fixed. Everything else is
the same. As for the potential problem with polling on the drm fd with
both dri1 and dri2 enabled, I suggest that we just disable the dri1
On Tue, 2009-08-18 at 14:46 -0400, Kristian Høgsberg wrote:
On Tue, Aug 18, 2009 at 1:36 PM, Thomas Hellströmtho...@shipmail.org wrote:
Kristian Høgsberg wrote:
On Tue, Aug 18, 2009 at 3:52 AM, Thomas Hellströmtho...@shipmail.org
wrote:
Kristian Høgsberg wrote:
By sending an
Kristian Høgsberg wrote:
On Tue, Aug 18, 2009 at 6:12 PM, Thomas Hellströmtho...@shipmail.org wrote:
Kristian Høgsberg wrote:
On Tue, Aug 18, 2009 at 5:03 PM, Dave Airlieairl...@gmail.com wrote:
On Wed, Aug 19, 2009 at 2:12 AM, Keith Whitwellkei...@vmware.com wrote:
Kristian Høgsberg wrote:
2009/8/17 Thomas Hellström tho...@shipmail.org:
Kristian Høgsberg wrote:
This patch adds a vblank synced pageflip ioctl for to the modesetting
family of ioctls. The ioctl takes a crtc and an fb and schedules a
pageflip to the new fb at the next coming
+#undef set_base
+
struct drm_prop_enum_list {
int type;
char *name;
@@ -342,6 +344,34 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
EXPORT_SYMBOL(drm_framebuffer_cleanup);
/**
+ * drm_crtc_async_flip - do a set_base call from a work queue
+ * @work: work
Jesse Barnes wrote:
On Mon, 17 Aug 2009 22:22:34 +0200
Thomas Hellström tho...@shipmail.org wrote:
Kristian Høgsberg wrote:
This patch adds a vblank synced pageflip ioctl for to the
modesetting family of ioctls. The ioctl takes a crtc and an fb and
schedules a pageflip to the new
Kristian Høgsberg wrote:
2009/8/17 Thomas Hellström tho...@shipmail.org:
Kristian Høgsberg wrote:
This patch adds a vblank synced pageflip ioctl for to the modesetting
family of ioctls. The ioctl takes a crtc and an fb and schedules a
pageflip to the new fb at the next coming
I'm a little fuzzy on the details, this part of the patch was carried
over from Jesse's original work. I believe set_base is supposed to be
called with the struct mutex held.
We shouldn't be this sloppy about locking, and in particular we shouldn't
protect a callback with a lock without
On Tue, Aug 18, 2009 at 3:52 AM, Thomas Hellströmtho...@shipmail.org wrote:
Kristian Høgsberg wrote:
By sending an event back on the file descriptor we allow users of the
API to wait on the flip to finish in a standard poll or select
mainloop, where it can handle input from other sources while
, it should be fine.
Keith
From: Kristian Høgsberg [...@bitplanet.net]
Sent: Tuesday, August 18, 2009 8:31 AM
To: Thomas Hellström
Cc: Kristian Høgsberg; Jesse Barnes; dri-de...@lists.sf.net
Subject: Re: [PATCH] Add modesetting pageflip ioctl and corresponding drm
On Tue, 18 Aug 2009 09:32:50 +0200
Thomas Hellström tho...@shipmail.org wrote:
Jesse Barnes wrote:
On Mon, 17 Aug 2009 22:22:34 +0200
Thomas Hellström tho...@shipmail.org wrote:
Kristian Høgsberg wrote:
This patch adds a vblank synced pageflip ioctl for to the
modesetting
On Tue, 18 Aug 2009 08:08:24 +0200
Thomas Hellström tho...@shipmail.org wrote:
Kristian Høgsberg wrote:
2009/8/17 Thomas Hellström tho...@shipmail.org:
Kristian Høgsberg wrote:
This patch adds a vblank synced pageflip ioctl for to the
modesetting family of ioctls. The ioctl
On Tue, 18 Aug 2009 16:24:14 +1000
Dave Airlie airl...@gmail.com wrote:
+#undef set_base
+
struct drm_prop_enum_list {
int type;
char *name;
@@ -342,6 +344,34 @@ void drm_framebuffer_cleanup(struct
drm_framebuffer *fb) EXPORT_SYMBOL(drm_framebuffer_cleanup);
/**
On Tue, Aug 18, 2009 at 2:08 AM, Thomas Hellströmtho...@shipmail.org wrote:
Kristian Høgsberg wrote:
Perhaps TTM bo read/write could use ioctls like the gem pwrite/pread
ioctls? The only way we can get asynchronous notifications from the
drm to userspace is through readable events on the drm
On Tue, 18 Aug 2009 09:17:23 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
Exactly what in the generic modesetting code is protected by the
struct mutex here?
I'm a little fuzzy on the details, this part of the patch was
carried over from Jesse's original work. I
Kristian Høgsberg wrote:
On Tue, Aug 18, 2009 at 3:52 AM, Thomas Hellströmtho...@shipmail.org wrote:
Kristian Høgsberg wrote:
By sending an event back on the file descriptor we allow users of the
API to wait on the flip to finish in a standard poll or select
mainloop, where it can
On Tue, Aug 18, 2009 at 1:36 PM, Thomas Hellströmtho...@shipmail.org wrote:
Kristian Høgsberg wrote:
On Tue, Aug 18, 2009 at 3:52 AM, Thomas Hellströmtho...@shipmail.org
wrote:
Kristian Høgsberg wrote:
By sending an event back on the file descriptor we allow users of the
API to wait on
actors shouldn't be
double-guessing that.
Keith
From: Kristian Høgsberg [...@bitplanet.net]
Sent: Tuesday, August 18, 2009 11:46 AM
To: Thomas Hellström
Cc: Kristian Høgsberg; Jesse Barnes; dri-de...@lists.sf.net
Subject: Re: [PATCH] Add modesetting pageflip
: Kristian Høgsberg; Jesse Barnes; dri-de...@lists.sf.net
Subject: Re: [PATCH] Add modesetting pageflip ioctl and corresponding drm
event
We don't put clients to sleep until they try to render to the new
backbuffer. For direct rendering this happens when the client calls
DRI2GetBuffers
[...@bitplanet.net]
Sent: Tuesday, August 18, 2009 11:46 AM
To: Thomas Hellström
Cc: Kristian Høgsberg; Jesse Barnes; dri-de...@lists.sf.net
Subject: Re: [PATCH] Add modesetting pageflip ioctl and corresponding
drm event
We don't put clients to sleep until they try to render to the new
On Tue, 18 Aug 2009 12:10:34 -0700
Keith Whitwell kei...@vmware.com wrote:
This seems wrong to me -- the client doesn't need to sleep - all it's
going to do is build a command buffer targeting the new backbuffer.
There's no problem with that, it should be the preserve of the GPU
scheduler
Høgsberg; Thomas Hellström; Kristian Høgsberg;
dri-de...@lists.sf.net
Subject: Re: [PATCH] Add modesetting pageflip ioctl and corresponding drm event
Anyway, to me this discussion is more of a future directions one than
a blocker for this particular patchset. AFAICT the only thing that
needs
On Wed, Aug 19, 2009 at 2:12 AM, Keith Whitwellkei...@vmware.com wrote:
I think the bug in question was because somebody (Jon Smirl??) removed the
empty apparently unused poll implementation from the drm fd, only to
discover that the X server was actually polling the fd.
If this code adds
On Tue, Aug 18, 2009 at 5:03 PM, Dave Airlieairl...@gmail.com wrote:
On Wed, Aug 19, 2009 at 2:12 AM, Keith Whitwellkei...@vmware.com wrote:
I think the bug in question was because somebody (Jon Smirl??) removed the
empty apparently unused poll implementation from the drm fd, only to
Kristian Høgsberg wrote:
On Tue, Aug 18, 2009 at 5:03 PM, Dave Airlieairl...@gmail.com wrote:
On Wed, Aug 19, 2009 at 2:12 AM, Keith Whitwellkei...@vmware.com wrote:
I think the bug in question was because somebody (Jon Smirl??) removed the
empty apparently unused poll
On Wed, Aug 19, 2009 at 07:03:41AM +1000, Dave Airlie wrote:
On Wed, Aug 19, 2009 at 2:12 AM, Keith Whitwellkei...@vmware.com wrote:
I think the bug in question was because somebody (Jon Smirl??)
removed the empty apparently unused poll implementation from the
drm fd, only to discover
Jesse Barnes wrote:
Anyway, to me this discussion is more of a future directions one than
a blocker for this particular patchset. AFAICT the only thing that
needs fixing with this patch is my lock confusion (struct_mutex vs
mode_config). Or would you like something substantial changed with
On Tue, Aug 18, 2009 at 6:12 PM, Thomas Hellströmtho...@shipmail.org wrote:
Kristian Høgsberg wrote:
On Tue, Aug 18, 2009 at 5:03 PM, Dave Airlieairl...@gmail.com wrote:
On Wed, Aug 19, 2009 at 2:12 AM, Keith Whitwellkei...@vmware.com wrote:
I think the bug in question was because
On Wed, Aug 19, 2009 at 8:03 AM, Luc Verhaegenl...@skynet.be wrote:
On Wed, Aug 19, 2009 at 07:03:41AM +1000, Dave Airlie wrote:
On Wed, Aug 19, 2009 at 2:12 AM, Keith Whitwellkei...@vmware.com wrote:
I think the bug in question was because somebody (Jon Smirl??)
removed the empty
On Wed, Aug 19, 2009 at 09:07:55AM +1000, Dave Airlie wrote:
On Wed, Aug 19, 2009 at 8:03 AM, Luc Verhaegenl...@skynet.be wrote:
On Wed, Aug 19, 2009 at 07:03:41AM +1000, Dave Airlie wrote:
On Wed, Aug 19, 2009 at 2:12 AM, Keith Whitwellkei...@vmware.com wrote:
I think the bug in question
On Tue, Aug 18, 2009 at 7:12 PM, Luc Verhaegenl...@skynet.be wrote:
And on the flip side of this, what you do is purely technical, always.
#dri-devel 00:05 +airlied krh: you've been smirled
Yeah, I was wondering about that, I thought the word was smirl-rolled :D
cheers,
Kristian
On Wed, Aug 19, 2009 at 09:22:10AM +1000, Dave Airlie wrote:
On Wed, Aug 19, 2009 at 9:12 AM, Luc Verhaegenl...@skynet.be wrote:
On Wed, Aug 19, 2009 at 09:07:55AM +1000, Dave Airlie wrote:
On Wed, Aug 19, 2009 at 8:03 AM, Luc Verhaegenl...@skynet.be wrote:
On Wed, Aug 19, 2009 at
On Wed, Aug 19, 2009 at 9:31 AM, Luc Verhaegenl...@skynet.be wrote:
On Wed, Aug 19, 2009 at 09:22:10AM +1000, Dave Airlie wrote:
On Wed, Aug 19, 2009 at 9:12 AM, Luc Verhaegenl...@skynet.be wrote:
On Wed, Aug 19, 2009 at 09:07:55AM +1000, Dave Airlie wrote:
On Wed, Aug 19, 2009 at 8:03 AM,
On Wed, Aug 19, 2009 at 01:31:06AM +0200, Luc Verhaegen wrote:
Dave,
Ask yourself whether your statement, the one i replied to, was a
technical contribution, or something else?
Luc,
Just ... stop. This is embarassing.
Daniel
pgp6apJk0Gjf4.pgp
Description: PGP signature
On Tue, Aug 18, 2009 at 6:31 PM, Thomas Hellströmtho...@shipmail.org wrote:
Jesse Barnes wrote:
Anyway, to me this discussion is more of a future directions one than
a blocker for this particular patchset. AFAICT the only thing that
needs fixing with this patch is my lock confusion
Kristian Høgsberg wrote:
This patch adds a vblank synced pageflip ioctl for to the modesetting
family of ioctls. The ioctl takes a crtc and an fb and schedules a
pageflip to the new fb at the next coming vertical blank event. This
feature lets userspace implement tear-free updating of the
On Mon, 17 Aug 2009 22:22:34 +0200
Thomas Hellström tho...@shipmail.org wrote:
Kristian Høgsberg wrote:
This patch adds a vblank synced pageflip ioctl for to the
modesetting family of ioctls. The ioctl takes a crtc and an fb and
schedules a pageflip to the new fb at the next coming
2009/8/17 Thomas Hellström tho...@shipmail.org:
Kristian Høgsberg wrote:
This patch adds a vblank synced pageflip ioctl for to the modesetting
family of ioctls. The ioctl takes a crtc and an fb and schedules a
pageflip to the new fb at the next coming vertical blank event. This
feature lets
On Mon, Aug 17, 2009 at 4:36 PM, Jesse Barnesjbar...@virtuousgeek.org wrote:
On Mon, 17 Aug 2009 22:22:34 +0200
Thomas Hellström tho...@shipmail.org wrote:
Kristian Høgsberg wrote:
This patch adds a vblank synced pageflip ioctl for to the
modesetting family of ioctls. The ioctl takes a
A couple of years ago, any attempt to return anything else than 0 from
drm poll resulted in an X server error.
http://freedesktop.org/bugzilla/show_bug.cgi?id=1505. The fix mentioned
in the bug was actually to return 0 from drm poll, and a comment about
this is still present in drm.git. The
On Mon, Aug 17, 2009 at 7:14 PM, Dave Airlieairl...@gmail.com wrote:
A couple of years ago, any attempt to return anything else than 0 from
drm poll resulted in an X server error.
http://freedesktop.org/bugzilla/show_bug.cgi?id=1505. The fix mentioned
in the bug was actually to return 0 from
On Tue, Aug 18, 2009 at 9:54 AM, Kristian Høgsbergk...@bitplanet.net wrote:
On Mon, Aug 17, 2009 at 7:14 PM, Dave Airlieairl...@gmail.com wrote:
A couple of years ago, any attempt to return anything else than 0 from
drm poll resulted in an X server error.
2009/5/8 Kristian Høgsberg k...@bitplanet.net:
From: Kristian Høgsberg k...@redhat.com
This patch adds a vblank synced pageflip ioctl for to the modesetting
family of ioctls. The ioctl takes a crtc and an fb and schedules a
pageflip to the new fb at the next coming vertical blank event.
57 matches
Mail list logo
