[RFC] merged void driver

[Peter Hutterer]

On 6/11/10 24:47 , Tiago Vignatti wrote:
> On Fri, Nov 05, 2010 at 07:38:19AM -0700, ext Alan Coopersmith wrote:
>> Tiago Vignatti wrote:
>>> On Fri, Nov 05, 2010 at 10:21:33AM +1000, ext Peter Hutterer wrote:
>>>> I'm looking at having to fix a number of unmaintained drivers for ABI 12 and
>>>> because it's hopefully the last time I'll worry about multi-server support
>>>> for those drivers, I decided to see how much work it is to merge a driver.
>>>>
>>>> Current tree is on branch driver-merge in my xserver repo.
>>>> http://cgit.freedesktop.org/~whot/xserver/log/?h=driver-merge
>>>> Still rebasing where needed, but it's a start.
>>>>
>>>> My main grief at this point is the massive AM_CPPFLAGS define which I'd like
>>>> to see somewhere more central. In the current drivers, we can just use the
>>>> sdk directory, but these headers are all over the server's source tree.
>>>>
>>>> Any comments appreciated.
>>>
>>> Peter, can you please brief the motivation for merging specifically input void
>>> driver? I mean, we can start a server without input drivers, so why we would
>>> care about a void one?
>>
>> You could watch the video of the discussion at XDS that you slept through
>> where we discussed this.  8-)
>
> fair enough, Alan :)
>
>
>> The short summary is:  xf86-input-void&  xf86-video-dummy *ONLY* change
>> when the X server ABI changes - they never have to support new models of
>> the "null" hardware, so can both serve as examples of driver updates to
>> new ABI's, and will never need to be separately backported to an older
>> server by a LTS/enterprise distro that needs to support new hardware
>> with their existing stable server branch.
>
> My point is: input-void is useless (or am I missing something?) given the
> server can be started without input driver. So why bother with it? I'm not
> discussing about merge _this_ driver or not.

void isn't completely useless. it still creates a new device and can 
thus test the code paths the server takes during device initialization. 
i haven't used it for a while now because uinput does the same job 
better, but void does have its use.

otoh, because the use is so limited, it's the safest driver to port and 
least likely to cause massive flamewars. it's the ideal one to set up 
the build environment, and get the infrastructure in place.

i see void as the first step and it's a pragmatic one. I expect that 
merging void and the other drivers that have a few users only into the 
tree will reduce maintenance time. the common ones will stay outside for 
a while.

Cheers,
   Peter