On 26 August 2016 at 04:04, Kevin Brace <kevinbrace@xxxxxxx> wrote: > Hi Emil, > >> Hi Kevin, >> >> On 26 August 2016 at 01:19, Kevin Brace <kevinbrace@xxxxxxx> wrote: >> >> > I do not want to be seen as stopping progress, but there are still people who use less than current hardware (myself and countless others) or non Big 3 x86 graphics (NVIDIA, AMD, and Intel) for things like thin clients. >> >> [snip] >> > Anyway, regarding the move to DRI2 / KMS so that DRI1 can be discontinued, I am not personally against it in the long run, but the work on it has stalled. >> > >> Afaict nobody is discontinuing DRI1, but marking it as BROKEN. Why you >> may ask - simply because there has been virtually zero development >> effort (general refactoring do not count) and serious testing, for >> those drivers over the last 5+ years. >> > > If I am correct, OpenChrome DDX's Xv and XvMC still uses DRI1 if I am correct. > That being said, I have not really touched that part of the code. (I have been working on mainly fixing display detection and standby resume issues for the past 6 months since I obtained commit privilege.) > Guess I should have put stronger emphasis on _serious testing_. And yes, most people here are familiar with your work on the DDX side and the previous one by James. > >> FWIW I would strongly recommend leaving UMS at peace and working >> towards KMS. Having a hybrid UMS/KMS stack is possible, but it's far >> too picky and time consuming even for larger teams. >> On the forward porting efforts - DRM evolves rapidly so one could >> consider starting from scratch. Wire up the (atomic?) mode setting >> side first then think about the render side of things. >> >> Regards, >> Emil >> > > Here is the drm-openchrome's new DRM James Simmons (the previous OpenChrome developer who did tremendous work between 2011 to early 2015, but has completely disappeared) worked on. > > https://cgit.freedesktop.org/openchrome/drm-openchrome/tree/drivers/gpu/drm/via > > I do not mean to criticize you, but how easy is it to start from scratch when there is that much code I will have to replace? As suggested above - start small. Here is a more comprehensive list: Stage 1: KMS (display only) driver, without any custom ioctls/uapi that works ~ok with the modesetting ddx. Only a single working output (type) is needed and the driver should be ok to merge upstream. 1 pick a trivial (ideally atomic) KMS driver as a base 2 add the stubs, consider using CMA at first. 3 pick a single display engines/resources (VGA, HDMI...) and wire it up. 4 add hw module/engines only when needed by the above. 5 make sure it's working OK(ish) with the modesetting ddx. Stage 2(?) As you can now drive an output you can continue with a) the other output types b) look into PM or c) start on the render side of things. If the last one - once the driver has achieved milestone push towards upstream inclusion. 1 Reconsider CMA vs other memory management, fb and other HW specifics 2 Pick one usespace component - mesa/ddx. 3 Design _new_ UAPI, get initial code (kernel and userspace), do very rough benchmarking/perf analysis 4 Get X, glxgears or XXX (sort of) working. ... Profit ;-) That's enough divergion from the original thread from me. If we have anything else can we keep it separate ? Sorry for hijacking the thread. Emil _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
