On Thu, Jan 31, 2019 at 10:36 AM Eric Anholt <e...@anholt.net> wrote:
> Alyssa Rosenzweig <aly...@rosenzweig.io> writes: > > >> There's u_pipe_screen_get_param_defaults() that you really want to be > >> using to avoid regressions when people add new pipe caps. You can get > >> rid of a lot of your switch statement that way, too. > > > > Oh, good to know. Is that newer? I'm pretty sure that whole block was > > copied from vc4 at some point ;) > > > >> We should probably be sticking the kmsro entrypoints in a shared group, > >> since there's nothing specific for the KMS . Looks like we haven't been > >> doing that, though. > > > > Yeah, I had the same thought, but I didn't want to disrupt other drivers > > yet (since that delays merge due to pinging more people). > > > >> These are both things we can change later. I'm mostly excited to see > >> you finally in-tree! > Hear, Hear! Whatever merge/patch you do is Acked-by: Jason Ekstrand <ja...@jlekstrand.net> It's about time! > > ^_^ > > > > Should either of the above issues be resolved in a v2 now, or just a > > follow-up patch after merging? > > Follow-up, imo. New drivers have a long awkward period where they > wouldn't pass review the way we would for incremental development, but > continuing to work out-of-tree means rebase pain and losing git history. > > (If you have git history out of tree that you'd like to retain when > merging in, I'm happy to try helping with that. I've done fun git > surgery before) > Doing merge commits for new drivers is not unheard of and preserves history (if the history is something you want to preserve). --Jason
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
