On Mon, May 28, 2018 at 6:50 PM Kevin Brace <kevinbr...@gmx.com> wrote:
> > Well done on getting this far. Merging this is definitely going to be
> > non-trivial. Being out of tree for so long means you've ended up in a
> > place that will require retracing a bunch of steps to get upstream.
> Just to clarify what is going on, while OpenChrome DRM (drm-openchrome
> repository) has been living outside of the mainline tree since Year 2011, I
> started tracking drm-next branch of Linux DRM tree very closely since
> September 2017.
> The current leading edge OpenChrome DRM code compiles against Linux 4.16, and
> when drm-next branch is updated to Linux 4.17 rc6 or rc7 code, the
> drm-next-4.18 branch (the present leading edge branch) will pull in the code.
> While I have removed drm/via subdirectory from the current drm-next-4.1*
> branches, I will restore it per your suggestion regarding VIA DRM.
> That being said, almost all the development activities of OpenChrome DRM goes
> on inside drm/openchrome subdirectory, and maybe you have some insights I am
> not aware of, but I would think it is a matter of creating a subdirectory
> drm/openchrome, and sticking OpenChrome DRM code there.
> That's how I have developed the code from some point on and have not
> encountered any side effects due to this.
> > I'm not going to insist on atomic modesetting, but I think it would
> > definitely make the driver simpler and easier for someone to review,
> > and I'm open to Daniel insisting on it. I think you'd be getting close
> > to clean slating most of this driver at that point, which considering
> > some bits below might not be the worst idea.
> Okay, I will still stay with the position of wanting OpenChrome DRM to be
> "grandfathered" from the universal plane and atomic mode setting
> implementations for the initial mainlining, although I am open to those two
> items being added to the TODO list for the future.
I think I was one of those developers asking you to switch to atomic
(iirc, i encouraged you to start working on kms instead of ums). I
know this is a personal project that you've been working on in your
spare time (which is awesome!), so while I still encourage you to
convert the driver, I don't have a problem with you doing the
conversion in mainline. I think hiding under staging until the
conversion is complete is a pretty reasonable compromise.
> > > Other than the universal plane and atomic mode setting, I have
> > > several other concerns.
> > >
> > > 1) James left some unfinished acceleration related code inside OpenChrome
> > > DRM, but I do not plan to activate it for the initial mainlined version.
> > > Do I need to remove the code?
> > Yes.
> Okay, I was thinking I will have to do this, so I wanted to bring it up.
> I will start working on this in a week or so.
> > > 2) James appears to have implemented custom Libdrm ABI / API calls. I do
> > > not plan to activate it for the initial mainlined version. Do I need to
> > > remove the code?
> > Yes.
> Same as the previous answer.
> > > 3) Almost all the functions start with "via_" instead of "openchrome_" at
> > > this point. Do I need to convert them all to "'openchrome_'?"
> > It would be nice, but possibly not essential.
> I was thinking I "should" do this, but I wanted to see if the maintainer
> prefers me to do this.
> I will start working on this after I get the unfinished acceleration related
> code removed.
> > > 4) Is the essentially deprecated VIA DRM going to be removed from the
> > > Linux kernel tree? VIA DRM is DRI1 based, and OpenChrome DRM supersedes
> > > VIA DRM for obvious reasons. Since OpenChrome DRM supersedes VIA DRM, I
> > > strongly support deleting VIA DRM from the Linux kernel tree.
> > No, since it shouldn't cause any problems with this, the current via
> > drm code is only enabled if userspace DRI1 stuff is around, I'm not
> > even sure there's a mesa driver that can use it at all.
> Okay, I will leave VIA DRM alone.
> If someone else wants to remove it someday, I am okay with that.
> I believe the DRI1 Mesa code for VIA has been gone since Mesa 8, so nobody
> really uses VIA DRM anymore other than OpenChrome DDX.
> OpenChrome DDX can operate without DRI1.
> That being said, I do have plans to work on updating drm/r128, drm/savage,
> drm/mga, and drm/sis eventually to support at least KMS using personally
> developed reusable code base.
> When this happens (this has not really happened yet due to OpenChrome DRM
> taking so much of my development time), the existing DRI1 code will need to
> be tossed out.
> Will that be okay, or will they need to be implemented in a separate
> > I'm also not sure how the VIA output bridges are wired up, but we've
> > grown a lot of code for external bridges now and it might be that the
> > sil164 stuff could reuse that (or not).
> The external video bridge interface (VIA calls it DVP, Digital Video Port)
> varies by the model, but for your information, OpenChrome DRM supports about
> 12 different generations of VIA Chrome (not counting S3 Graphics Chrome
> graphics) integrated graphics.
> In the Intel graphics world equivalent, it is roughly comparable to Gen 2 to
> Gen 4 graphics, sans the DirectX 10 functionality from Gen 4.
> Due to the number of VIA Chrome devices OpenChrome DRM needs to support, I
> personally prefer having a tighter integration of external transmitters /
> encoders with the OpenChrome DRM so that the end user has the best user
> At least for VIA Technologies VT1632(A) DVI transmitter, I have verified full
> standby resume restoration capabilities on VT1632(A), along with display
> applet turn on / off capabilities, and I will assume OpenChrome DRM's own SiI
> 164 DVI transmitter code should have similar results.
> Based on these points, I prefer to keep the current SiI 164 code as is rather
> than having to interface to someone else's SiI 164 code.
> I plan to add several more external transmitter / encoder support after the
> code is mainlined, but most of them are going to be VIA developed LVDS
> transmitters / TV encoders that only VIA used it with VIA Chrome integrated
> > This might be a candidate for a drm staging if we can get an initial
> > review and a decent TODO list together for it.
> > Dave.
> Dave, just to let you know that I strongly believe OpenChrome DRM is ready to
> be inserted into the mainline tree without having to spend time inside the
> staging tree.
> Since XDC2017, I have almost solely focused on fixing code death traps, and
> it is nearing an end in focusing the development resources in that area.
> I have neglected adding acceleration related features to concentrate on
> improving the reliability of OpenChrome DRM.
> Based on my own testing with a dozen and a half VIA Chrome graphics based
> devices, I feel comfortable that OpenChrome DRM KMS is ready to replace the
> existing OpenChrome DDX UMS.
> After OpenChrome DRM is mainlined, I plan on adding acceleration related
> features, along with adding universal plane and atomic mode setting support.
> Kevin Brace
> Brace Computer Laboratory blog
> dri-devel mailing list
dri-devel mailing list