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. Sean > > > > 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 > subdirectory? > > > > 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 > experience. > 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 > graphics. > > > > 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. > > Regards, > > Kevin Brace > Brace Computer Laboratory blog > https://bracecomputerlab.com > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
