On Sun, 2005-06-26 at 18:54 -0400, Vladimir Dergachev wrote: > Hi all, > > I have fixed known issues with r300 DRM driver: > > * r300_emit_unchecked_state properly fallbacks to > r300_emit_carefully_checked_state() when asked to set > touchy registers (i.e. those with offsets). > > * r300_emit_raw properly checks LOAD_VBPNTR packet that all > offsets are ok. > > * all of these copy user data exactly once. > > The next step is to discuss what else is needed for successful merge > into the main DRM CVS. > > * What are the requirements for a patch to be accepted ? > > * Can R300 developers get CVS access ? > > * What else do we need in R300 DRM module ? > (Besides working PCIE - Dave what are wishes in this regard ?)
I was just looking at r300 code today for my own system. A few things that I think ought to happen for the merge: - Clean up style. Unindented blocks of code, weird whitespace (closing brackets on the same column as the block containing it, rather than the surrounding block), lack of wrapping at 80 columns, etc. - r300_emit_unchecked_state should get renamed (r300_check_and_emit_state?) and its all-caps warnings removed. Things I noticed that aren't top priority: - DRM_COPY_FROM_USER_UNCHECKED in r300_emit_cliprects should be a DRM_COPY_FROM_USER, I think. - Axe the comment about "can't afford to let userspace control something that locks up the graphics card so easily" in R300_CMD_END3D handling. There are too many ways to hang a graphics card with DRI for us to try to stop the user from doing so. - r300_reg_flags should probably be in the dev_priv rather than a global. And something I've wondered about for a while: - Is the __user annotation supposed to mean "this is a value from userland that should be checked for use" or "this is a pointer to somewhere in userland that needs to be copy_from_usered before use?" For CVS access, please get the r300 developers to submit their ssh v2 public key, preferred username, email address, and full name to fd.o bugzilla under "sitewranglers", noting that they should get access to mesa and dri. When that starts happening, I'll be sure to poke daniels about getting the accounts made. For the client driver code, I'm thinking it would be a good idea to repocopy it over (thus maintaining CVS history). If you agree with this, whenever its time to do that merge we should have a 1-day rest so that sf.net will make a clean tarball of the current cvsroot, which the sf.net project admin (you) could grab and hand off to me to put the bits in the right place in Mesa CVS. -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
