On Mon, Mar 09, 2020 at 10:29:42PM +0200, Laurent Pinchart wrote: > Hi Sam, > > On Mon, Mar 09, 2020 at 08:45:41PM +0100, Sam Ravnborg wrote: > > On Mon, Mar 09, 2020 at 09:01:27PM +0200, Laurent Pinchart wrote: > > > On Mon, Mar 09, 2020 at 08:00:47PM +0100, Sam Ravnborg wrote: > > > > On Mon, Mar 09, 2020 at 08:42:10PM +0200, Laurent Pinchart wrote: > > > > > The OrtusTech COM43H4M85ULC is a DPI panel, set the connector type > > > > > accordingly. > > > > > > > > > > Signed-off-by: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> > > > > > > > > Reviewed-by: Sam Ravnborg <sam@xxxxxxxxxxxx> > > > > > > > > I assume you will apply to drm-misc-next - OK? > > > > > > I still haven't got around to using dim :-) > > > > I can manage - so the entry level is pretty low. > > > > My lame and simple workflow > > > > dim update-branches > > # save patch from mutt > > cat mbox | dim apply Why don't you just pipe the thing into dim straight from mutt? That's what I do. Followed by some amount of dim extract-tag also piped in from mutt. > > git rebase etc. > > dim checkpatch <= if I make changes while applying > > #build testing > > dim push > > > > > > And when I do my own stuff: > > dim update-branches > > git checkout -b sam-my-stuff > > hacking-hacking > > commit, commit > > git rebase --exec "dim add-missing-cc" HEAD~5 > > > > > > dim can do much more than that - but the above is > > the few dim commands I use. > > This help me to do things remotely correct. > > > > So maybe this is as good as any time to try out dim? > > As good as any, and as bad as any I suppose :-) > > There are a few things I don't like with dim, and I haven't found time > yet to see how to fix (how live with :-) them yet. Among those issues > are > > - dim requires the kernel tree to be under $DIM_PREFIX. This is my main > issue, as I have one kernel tree per project, with and develop for > different subsystems in each. I would like dim to instead handle any > kernel tree regardless of where it is located on the disk, without > requiring me to add another DRM-specific tree to my workflow. > > - The script auto-updates itself, and I find that to be a security issue > that I'm not comfortable with. What do you mean it auto updates? Never seen anything like that. > - The dim script makes a special case of intel repositories internally, > which I don't find very fair. Maybe that can be considered as a > compensation for Intel's efforts in DRM development, but a model where > the community maintaining drm-misc has to resolve conflicts with > drm-intel before it reaches drm-next bothers me. It doesn't special case Intel repos. It just merges all the repos listed in the config file to create a new drm-tip. There are Intel repos, AMD repos, and various other repos. The point is to keep drm-tip always up to date and working (*). And if you manage to create a conflict you can't solve you can always ping someone who can. Also hoefully no one should be seeing all that many conflicts due to rerere (unless you actually created a new conflict that is). * why would anyone run anything else but drm-tip anyway? ;) -- Ville Syrjälä Intel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
