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

[Jesse Barnes]

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.

-- 
Jesse Barnes, Intel Open Source Technology Center