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@ideasonboard.com
Reviewed-by: Sam Ravnborg sam@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
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? ;)