input thread [was Re: [PATCH v2] input: constify valuators passed in by input drivers.]

[Ville Syrjälä]

On Fri, Aug 13, 2010 at 05:53:53PM +0200, ext Aaron Plattner wrote:
> On Fri, Aug 13, 2010 at 08:09:24AM -0700, Adam Jackson wrote:
> > On Fri, 2010-08-13 at 08:51 -0300, Fernando Carrijo wrote:
> > > And to be honest, it seems to me that the precautions taken by the
> > > smart scheduler to penalize hungry clients isn't enough in certain
> > > circumstances. Firefox abusive usage of XPutImage comes to my mind,
> > > even though I'm completely unaware of the reasons that make the cost
> > > of this operation to be so expensive.
> > 
> > PutImage sucks because it's at least two copies through the unix socket,
> > one from the client down to the kernel and one back up from the kernel
> > to the server.  Once you've done that you still have to get the data
> > into the driver's storage, which is either a memcpy into host memory
> > somewhere or DMA up to the video card.  However, the way it's
> > implemented now, that's all synchronous; even if you DMA it up to VRAM,
> > you have to block the server until the DMA completes.
> > 
> > ShmPutImage is a bit better in that it elides the socket copies, but
> > that last memcpy or DMA still has to fire, and it still completes
> > synchronously; the server won't advance to the next request until it's
> > done.
> 
> I know it's nitpicking, but this is false at least for our driver.
> {Shm,}PutImage is pipelined and you can have a potentially large number of
> them in flight at a time.

So you just hope that the client doesn't corrupt the data before the DMA
finishes? Or do you memcpy() to some temp buffer and DMA from there?

It seems to me that the original intent was to allow fully async
ShmPutImage hence the shm completion event. Unfortunately the actual
implementation assumes that the operation is synchronous and sends
the event immediately. The same issue is replicated in the Xv code.
And of course no client seems to use the events.

-- 
Ville Syrjälä