[Openchrome-devel] xf86-video-openchrome: configure.ac src/via_sii164.c src/via_sii164.h

[Luc Verhaegen]

On Fri, Aug 26, 2016 at 12:39:02AM +0200, Kevin Brace wrote:
> Hi Luc,
> 
> > Sent: Thursday, August 25, 2016 at 5:56 AM
> > From: "Luc Verhaegen" <libv at skynet.be>
> > To: "Kevin Brace" <kevinbrace at kemper.freedesktop.org>
> > Cc: openchrome-devel at lists.freedesktop.org
> > Subject: Re: [Openchrome-devel] xf86-video-openchrome: configure.ac src/via_sii164.c src/via_sii164.h
> >
> > On Thu, Aug 25, 2016 at 12:22:11PM +0000, Kevin Brace wrote:
> > > --- /dev/null
> > > +++ b/src/via_sii164.c
> > > @@ -0,0 +1,505 @@
> > > +/*
> > > + * Copyright 2016 Kevin Brace
> > > + * Copyright 2016 The OpenChrome Project
> > > + *                [http://www.freedesktop.org/wiki/Openchrome]
> > > + * Copyright 2014 SHS SERVICES GmbH
> > > + *
> > 
> > May i suggest that you remove the SHS copyright and add mine instead?
> > 
> > https://cgit.freedesktop.org/~libv/xf86-video-unichrome/tree/src/via_sii16x.c
> > 
> > That's a lot of similarities, with ordering and naming being quite 
> > similar. Then, xf86I2CMaskByte definitely is my copyright.
> > 
> 
> Thank you for bringing this issue to my attention.
> I do not use your code during my coding activity, so this is really the first time I became aware of the situation.
> In fact, I am rather surprised of some of the similarities between the code donated by Christian Jung of SHS SERVICES GmbH and your current code you wrote.
> 
> https://cgit.freedesktop.org/~libv/xf86-video-unichrome/tree/src/via_sii16x.c
> https://cgit.freedesktop.org/~libv/xf86-video-unichrome/tree/src/via_i2c.c
> 
> To this.
> 
> https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/?id=a8c2f04e2ef21e64f2e91dd6f3e237f80e8c80c6
> 
> In particular, the way Christian Jung defined the VT1632 record's members exactly match your naming convention.
> I also looked at xf86I2CMaskByte function, and it is line by line identical to your version in your via_i2c.c.
> Based on that, I think it is fair that I should include your name for via_vt1632.c / .h and via_sii_164.c / .h, but since Christian did add some lines of code to via_vt1632.c different from yours, I will not remove his copyright.
> There is some divergence of the way the code is written for VT1632(A).
> He definitely should have given you credit for your original work.
> I did not do the original code merge (James Simmons did) and I still had to fix several bugs before the code was even useful.
> I hope you are okay with my decision here.
>     Personally, I do not deal with uncredited code situation too often (this is really the first time in my life), but I attended a university in the United States where this was the norm for the master's degree program at this university's Electrical Engineering (ASIC / FPGA design is my background) and Computer Science / Computer Engineering / Software Engineering programs.
> Pretty much most of the students who do this originate from one country somewhere in the broader Asia (I will not specify which country, but take a guess. It is a very large population nation.), and many professors in these departments know this, but does very little to fight code copying (i.e., copying code among students / husband doing the coding assignments for the unprepared and uninterested wife since going to school allows her to change visa status, and allows the spouse obtain work permit during her "studies") since money (i.e., out of state tuition) they bring in speaks in volume to the administrators and tenured professors of this university.
> Furthermore, people from this particular nation represents 90% of the students of these master's program, and local Silicon Valley employers appear to "prefer" hiring them for computer / electronics technical jobs rather than the "play by the rule" more honest local American / permanent residency students. (I used to be one of them, so I know the corrupt hiring system of Silicon Valley pretty well.)
> Of course, it doesn't pay to be honest.
> Sorry for my unrelated rant about copying code and not attributing it, but it has affected my job prospects, so I wanted to chip in my 2 cents about it.
> 
> 
> > I suggest that you also fix vt1632, or that you unify this like i did, 
> > 10 years ago: 
> > https://cgit.freedesktop.org/~libv/xf86-video-unichrome/log/src/via_sii16x.c
> > 
> > If you are going to turn this into the unichrome driver with randr1.3 
> > support, then you better properly acknowledge the original author.
> > 
> > Luc Verhaegen.
> > 
> 
> Luc, I do not plan to adopt your code since they has been quite a divergence from your code and current OpenChrome code despite what you have pointed out in this particular situation.
> Regarding merging VT1632(A) and SiI 164 support code, that might happen someday, but I do not plan to do so for now.
> That being said, your code is a lot cleaner and neater than the terrible old (written by previous OpenChrome developers) OpenChrome code I deal with almost everyday.
> 
> Regards,
> 
> Kevin Brace

I do not think the SHS code adds that much, but thanks for acknowledging 
this. Some synapses tell me that i frowned over the vt1632 code years 
ago, but i had written off openchrome completely already then.

As for merging vt1632 with sii164, sii164 is _THE_ original DVI encoder. 
vt1632 is a direct and pin compatible clone.

As for the unichrome code, when all is said and done, you will have 
proven that it would've been easier to add new hardware support to 
the highly clean and structured unichrome display code than the other 
way around. But never mind me, you're only proving me right on things i 
was stating (and was being naysaid on, and forked from) more than a 
decade ago.

Luc Verhaegen.