On Mon, May 28, 2018 at 6:50 PM Kevin Brace <kevinbrace@xxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
