[RFC] Getting OpenChrome DRM mainlined into Linux kernel tree

[RFC] Getting OpenChrome DRM mainlined into Linux kernel tree

[Kevin Brace]

Hi,

I work on developing OpenChrome graphics stack for VIA Technologies Chrome integrated graphics.
I am looking to get OpenChrome DRM pulled into the Linux kernel tree in the near future.
This is not a pull request.
The code not quite ready for that, but I will like to start orienting my development activities towards getting OpenChrome DRM mainlined in the next one or two Linux kernel development cycles since OpenChrome DRM has been living outside the mainline kernel tree for 7+ years (at least since Year 2011).
    If someone reading this post is not too familiar with OpenChrome graphics stack, I did a presentation during XDC2017 that discussed the history of OpenChrome Project and its future plans.

https://www.x.org/wiki/Events/XDC2017/brace_openchrome.pdf

Since XDC2017, I have fixed many issues like standby resume and runtime screen resolution change crashes, and as a result, I am pretty confident now that OpenChrome DDX with OpenChrome DRM performing mode setting (KMS) is as reliable as OpenChrome DDX performing mode setting (UMS).
In the past week, I officially added two external DVI transmitters to the OpenChrome DRM (VIA Technologies VT1632(A) and Silicon Image SiI 164), and as a result, OpenChrome DRM KMS now has virtually identical display device support to the legacy OpenChrome DDX UMS.
This will allow a seamless transition from UMS to KMS.
    However, there are some areas of concern I have with OpenChrome DRM getting mainlined inside Linux kernel tree.
During XDC2017, I spoke with one or two developers that strongly urged me to convert to atomic mode setting from the Year 2008 vintage "legacy" KMS.
I declined this since I just got OpenChrome DRM ported to Linux 4.13 one week prior to XDC2017, but furthermore, I needed to stabilize the code itself since it was still pretty buggy compared to OpenChrome DDX UMS.
The reason OpenChrome DRM still uses "legacy" KMS despite its flaws is the fact that previous developer, James Simmons, started the development back in Year 2011 or so, and I have merely continued the development starting around Year mid-2016.
My personal wish is to get OpenChrome DRM "grandfathered" from the strong expectation of implementing universal plane and atomic mode setting since the code development started well before those two got incorporated into the DRM.
I can consider converting the code to support these two features down the road, but just for the initial mainlining, I will like to be exempted from it since it will likely delay the mainlining by 6 months or so.
    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?
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?
3) Almost all the functions start with "via_" instead of "openchrome_" at this point. Do I need to convert them all to "'openchrome_'?"
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.

Since the code size is quite substantial, I hope providing the cgit location for the code is adequate.
Here is the main code page.

https://cgit.freedesktop.org/openchrome/drm-openchrome/


At this time, the code development is being done on drm-next-4.18 branch.

https://cgit.freedesktop.org/openchrome/drm-openchrome/?h=drm-next-4.18


Here is the latest drm-next-4.18 branch OpenChrome DRM source code.
This is where the code to review is located.

https://cgit.freedesktop.org/openchrome/drm-openchrome/tree/drivers/gpu/drm/openchrome?h=drm-next-4.18


    The strong desire to get OpenChrome DRM mainlined is driven by the decisions major Linux distributions like Ubuntu and Fedora made in dropping OpenChrome DDX from their default installed graphics device driver list some years ago due to the lack of DRI2 and / or KMS support with OpenChrome.
This causes installation difficulties with non-technical computer users who wish to use VIA Technologies hardware with Linux, and I will like to resolve this situation by getting OpenChrome DRM mainlined and getting OpenChrome DDX back on their default installation list.

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

Re: [RFC] Getting OpenChrome DRM mainlined into Linux kernel tree

[Dave Airlie]

On 28 May 2018 at 11:28, Kevin Brace <kevinbrace@gmx.com> wrote:
> Hi,
>
> I work on developing OpenChrome graphics stack for VIA Technologies Chrome integrated graphics.
> I am looking to get OpenChrome DRM pulled into the Linux kernel tree in the near future.
> This is not a pull request.
> The code not quite ready for that, but I will like to start orienting my development activities towards getting OpenChrome DRM mainlined in the next one or two Linux kernel development cycles since OpenChrome DRM has been living outside the mainline kernel tree for 7+ years (at least since Year 2011).
>     If someone reading this post is not too familiar with OpenChrome graphics stack, I did a presentation during XDC2017 that discussed the history of OpenChrome Project and its future plans.

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.

> I declined this since I just got OpenChrome DRM ported to Linux 4.13 one week prior to XDC2017, but furthermore, I needed to stabilize the code itself since it was still pretty buggy compared to OpenChrome DDX UMS.
> The reason OpenChrome DRM still uses "legacy" KMS despite its flaws is the fact that previous developer, James Simmons, started the development back in Year 2011 or so, and I have merely continued the development starting around Year mid-2016.
> My personal wish is to get OpenChrome DRM "grandfathered" from the strong expectation of implementing universal plane and atomic mode setting since the code development started well before those two got incorporated into the DRM.
> I can consider converting the code to support these two features down the road, but just for the initial mainlining, I will like to be exempted from it since it will likely delay the mainlining by 6 months or so.

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.

>     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.

> 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.

> 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.

> 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.

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).

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.
_______________________________________________
openchrome-devel mailing list
openchrome-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/openchrome-devel

Re: [RFC] Getting OpenChrome DRM mainlined into Linux kernel tree

[Kevin Brace]

> 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.


> >     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
_______________________________________________
openchrome-devel mailing list
openchrome-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/openchrome-devel

Re: [RFC] Getting OpenChrome DRM mainlined into Linux kernel tree

[Sean Paul]

On Mon, May 28, 2018 at 6:50 PM Kevin Brace <kevinbrace@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

Re: [RFC] Getting OpenChrome DRM mainlined into Linux kernel tree

[Kevin Brace]

Hi Sean,

I do recall seeing you at XDC2017, I do not believe I spoke with you at the event.
I will not name the name, but I had one developer who strongly asked me to convert to atomic mode setting, but I refused due to the state of the code at the time.
Now, the KMS device support is mostly comparable to the existing UMS code path, so I can soon consider implementing universal plane and atomic mode setting.
I am okay with the OpenChrome DRM not being activated initially (i.e., Displaying "(Experimental)" status when running menuconfig), but I do want it directly inserted into the DRM tree from day one after the code is pulled in. (i.e., not getting inserted into the "staging" tree)
I believe the current code quality is good enough for this arrangement.

Regards,

Kevin Brace
Brace Computer Laboratory blog
https://bracecomputerlab.com


> Sent: Wednesday, June 13, 2018 at 1:07 PM
> From: "Sean Paul" <seanpaul@chromium.org>
> To: kevinbrace@gmx.com
> Cc: "Dave Airlie" <airlied@gmail.com>, dri-devel <dri-devel@lists.freedesktop.org>, openchrome-devel@lists.freedesktop.org
> Subject: Re: [RFC] Getting OpenChrome DRM mainlined into Linux kernel tree
>
> 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
> 
_______________________________________________
openchrome-devel mailing list
openchrome-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/openchrome-devel

Re: [RFC] Getting OpenChrome DRM mainlined into Linux kernel tree

[Daniel Vetter]

Hi Kevin,

On Wed, Jan 09, 2019 at 06:09:00PM +0100, Kevin Brace wrote:
> Hi Sean,
> 
> I do recall seeing you at XDC2017, I do not believe I spoke with you at
> the event.  I will not name the name, but I had one developer who
> strongly asked me to convert to atomic mode setting, but I refused due
> to the state of the code at the time.

That was at least me and Ben Skeggs. No point playing games, we're doing
open discussions here in the gpu subsystem.

> Now, the KMS device support is mostly comparable to the existing UMS
> code path, so I can soon consider implementing universal plane and
> atomic mode setting.  I am okay with the OpenChrome DRM not being
> activated initially (i.e.,
> Displaying "(Experimental)" status when running menuconfig), but I do
> want it directly inserted into the DRM tree from day one after the code
> is pulled in. (i.e., not getting inserted into the "staging" tree) I
> believe the current code quality is good enough for this arrangement.

Given how much cleaner the atomic helpers are, and how much simpler the
resulting drivers tend to be, I still think that's a bad idea. We do have
vboxvideo merged into staging, which still a non-atomic driver, but I
don't think that's helping anyone. It's definitely hurting refactoring to
have a driver outside of drm. And within drm imo a new non-atomic driver
doesn't make sense.

I've also never seen the code yet on dri-devel, so can't really give more
specific advise.

Cheers, Daniel

> 
> Regards,
> 
> Kevin Brace
> Brace Computer Laboratory blog
> https://bracecomputerlab.com
> 
> 
> > Sent: Wednesday, June 13, 2018 at 1:07 PM
> > From: "Sean Paul" <seanpaul@chromium.org>
> > To: kevinbrace@gmx.com
> > Cc: "Dave Airlie" <airlied@gmail.com>, dri-devel <dri-devel@lists.freedesktop.org>, openchrome-devel@lists.freedesktop.org
> > Subject: Re: [RFC] Getting OpenChrome DRM mainlined into Linux kernel tree
> >
> > 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
> > 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
openchrome-devel mailing list
openchrome-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/openchrome-devel

Re: [RFC] Getting OpenChrome DRM mainlined into Linux kernel tree

[Sean Paul]

On Wed, Jan 09, 2019 at 09:39:45PM +0100, Daniel Vetter wrote:
> Hi Kevin,
> 
> On Wed, Jan 09, 2019 at 06:09:00PM +0100, Kevin Brace wrote:
> > Hi Sean,
> > 
> > I do recall seeing you at XDC2017, I do not believe I spoke with you at
> > the event.  I will not name the name, but I had one developer who
> > strongly asked me to convert to atomic mode setting, but I refused due
> > to the state of the code at the time.
> 
> That was at least me and Ben Skeggs. No point playing games, we're doing
> open discussions here in the gpu subsystem.
> 
> > Now, the KMS device support is mostly comparable to the existing UMS
> > code path, so I can soon consider implementing universal plane and
> > atomic mode setting.  I am okay with the OpenChrome DRM not being
> > activated initially (i.e.,
> > Displaying "(Experimental)" status when running menuconfig), but I do
> > want it directly inserted into the DRM tree from day one after the code
> > is pulled in. (i.e., not getting inserted into the "staging" tree) I
> > believe the current code quality is good enough for this arrangement.
> 
> Given how much cleaner the atomic helpers are, and how much simpler the
> resulting drivers tend to be, I still think that's a bad idea. We do have
> vboxvideo merged into staging, which still a non-atomic driver, but I
> don't think that's helping anyone. It's definitely hurting refactoring to
> have a driver outside of drm. And within drm imo a new non-atomic driver
> doesn't make sense.

Yeah, given the pain experienced with vboxvideo in the past half-year, I'd
like to reverse my statement from June and vote against putting this in
staging.

We've waited this long for the openchrome stuff, we can probably wait a bit
longer until it's at least basically atomic.

Sean

> 
> I've also never seen the code yet on dri-devel, so can't really give more
> specific advise.
> 
> Cheers, Daniel
> 
> > 
> > Regards,
> > 
> > Kevin Brace
> > Brace Computer Laboratory blog
> > https://bracecomputerlab.com
> > 
> > 
> > > Sent: Wednesday, June 13, 2018 at 1:07 PM
> > > From: "Sean Paul" <seanpaul@chromium.org>
> > > To: kevinbrace@gmx.com
> > > Cc: "Dave Airlie" <airlied@gmail.com>, dri-devel <dri-devel@lists.freedesktop.org>, openchrome-devel@lists.freedesktop.org
> > > Subject: Re: [RFC] Getting OpenChrome DRM mainlined into Linux kernel tree
> > >
> > > 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
> > > 
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Sean Paul, Software Engineer, Google / Chromium OS
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel