Hi Marco, Disclaimer: I'm mostly lurking around, barring the occasional patch so please take my input with a grain of salt. On 1 June 2017 at 23:46, Marco Diego Aurélio Mesquita <marcodiegomesquita@xxxxxxxxx> wrote: > Hi Devs! > > On Thu, Jun 1, 2017 at 8:59 AM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote: >> Hi All, >> >> This is a resend of a patch I send out a while back, rebased on top >> of 4.12-rc3. Back then the main comment was can you try to make this >> driver use the drm_simple_kms_helper stuff? Unfortunately I have >> not had time yet to look into this. >> >> Recently I've been contacted by Marco Diego Aurélio Mesquita (in the Cc) >> who wants to work on getting this driver ready for mainline. >> >> He has has some questions / ideas about how to do this, so the >> main reason for reposting this is to give him a thread to reply to >> which provides context for his questions / ideas. >> > > Hans, thanks for citing me. > > I'm an owner of a c120 miniprojector and would like to have this > driver on mainline. As far as I could test (previous versions) it > works reasonably well. From what I've seen[1], main obstacle for this > driver been mainlined is the duplicated code from the udl driver. > > I've been playing with the code of this driver for a few days and I > think that moving the common code between the udl and gm12u320 is a > sound idea. It would greatly simplify the code of both drivers and > both would become much smaller. > > Since I'm a coder myself, I would like to do it myself. Common code > and differences from both drivers are very easy to spot and moving > that into a common lib is something that I think a can do without any > problems. The only reason I still have not started it is because I > don't know if such work would be accepted. > > So, my question for you devs is: do you agree in factoring out some > code from the udl driver so that both drivers (udl and gm12u320) can > be smaller and simpler? > > If the answer to this question is yes, then I'll start coding and plan > to comeback just to ask about minor details about what is really > specific (even if equal) for any driver and what is not. > As Daniel mentioned in the earlier thread, factoring out things can be done as a follow-up. On the other hand, I _think_ that the blocker for this driver that it's not doing atomic mode setting. There's some example resources in Daniel's blog [1], although you could skim through any of the existing drivers that were converted recently (git log -p | grep DRIVER_ATOMIC) -Emil [1] http://blog.ffwll.ch/ _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
