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.pinch...@ideasonboard.com> > > > > > > Reviewed-by: Sam Ravnborg <s...@ravnborg.org> > > > > > > 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 > 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. - 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. The second issue is easy to solve by commenting out auto-update (not sure if Daniel will like that though :-)), and the third one isn't really a blocker, but the first one currently prevents me from using dim. -- Regards, Laurent Pinchart _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
