Re: [PATCH 3/3] Install headers to $(includedir)/libdrm
Le 10/03/2010 13:13, Julien Cristau a écrit :
> any comments on this?
Reviewed-by: Rémi Cardona
The whole series looks nice. Just got me wondering why libdrm_intel
installs its only header in ${includedir} and not in /drm or /libdrm...
Cheers,
Rémi
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
Le 09/11/2009 00:14, Robert Noland a écrit : > There are any number of changes that may occur in libdrm that do not > impact the KBI and users should be able to get those features/bug fixes > without needing a new kernel. Absolutely. In fact, one of the biggest Intel performance wins lately was in a libdrm change [1] that had absolutely nothing to do with the kernel per se. Not having to force a new kernel down our users throat was very welcome. Cheers, Rémi [1] http://cgit.freedesktop.org/mesa/drm/commit/?id=3f3c5be6f908272199ccf53f108b1124bfe0a00e -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 0/4] Cursor's update inside kernel only
Le 19/01/2009 19:03, Jesse Barnes a écrit : > 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. Maybe there could be a way to prioritize input events over rendering requests within the server, but going full software for the cursor sounds like the best solution. It's only a pixmap after all... Cheers -- Rémi Cardona LRI, INRIA remi.card...@lri.fr r...@gentoo.org -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 0/4] Cursor's update inside kernel only
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. Cheers Rémi -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
