On Friday 10 June 2005 20:13, Jon Smirl wrote: > Why don't we start with a two module system which is already 90% > written. There is nothing stopping it from being split into a three > module system later. I'm not against the three module system I just > don't want to create more work to do.
Because technically this patch is bogus if it ever gets merged back to DRM CVS. It will break BSD, <video/radeon_share.h> is a linuxism, and you've added that and calls to your new radeonfb stublets in shared-core. Moving the chip flags out of drm_pciids.h is a waste of time, they're just going to get regenerated from the text file. And apparently the reason you did that is to replace (dev_priv->flags & CHIP_HAS_HIERZ) with radeonfb_has_heirz(dev_priv->fb_handle). I don't see the win in pushing that info down to the radeonfb layer, since it apparently isn't needed there. Oh, and you broke HyperZ, because afaict you never initialize ->family to anything. Worse than that, struct radeonfb_info doesn't even have a ->family member. So this won't even _build_, let alone work. > My issue is with doing a bunch of work to support case #2 since #2 > will be eliminated by the new Xegl server. You keep saying that as though it were going to be true. And if you'd stop saying it the perceived hostility - on both sides - would probably go down quite a bit. We're all quite aware of what your goals are, we really don't need to be told them every five minutes. - ajax
pgpuURGKsndTQ.pgp
Description: PGP signature
