[PATCH 0/4] Cursor's update inside kernel only

[Michel Dänzer]

On Mon, 2009-01-19 at 10:03 -0800, Jesse Barnes wrote: 
> On Friday, January 16, 2009 1:55 pm Rémi Cardona wrote:
> > Le 16/01/2009 21:21, Jesse Barnes a écrit :
> > > On Monday, January 5, 2009 12:55 pm Tiago Vignatti wrote:
> > >> Right now a thing that is annoying me is how others cursors, sw
> > >> rendered, could be implemented. I want to avoid two differents sets of
> > >> the same code in different contexts. IMHO conceptually all these cursor
> > >> update things must be in-kernel. Painting a cursor image seems to be
> > >> quite hard as we have to save/restore areas under the cursor. I remember
> > >> that anholt had an idea concerning this, but I do not remember details.
> > >
> > > I really like the idea of having this in the kernel for latency reasons,
> > > but yeah we do need to solve the sw case as well as implementing some
> > > acceleration code.  OTOH it might be reasonable to push the problem of
> > > multiple, large, and or funky format cursors out to userspace, since
> > > those are relatively uncommon (64x64 32 bit ARGB ought to be enough for
> > > everybody right? :).
> >
> > Not for firefox. Any drag&drop in gecko will result in huge ARGB
> > cursors. Even just dragging and dropping a tab results in a cursor
> > that's at least 150x20px.
> 
> Gah, yeah forgot about drag & drop of big icons...  Maybe Kristian was right 
> that all cursors should be done in software; hardware just doesn't provide 
> the flexibility desktops want these days.

Yeah, I suspect allowing the compositing manager to render cursors might
be more useful in the long term. Then we 'just' need to make sure the
composited cursors don't lag more than one frame behind the input
devices.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer