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
_______________________________________________
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
