[PULL to discuss] Remove kdrive, Xnest, and Xvfb
Jamey Sharp
jamey at minilop.net
Mon Mar 26 17:37:37 PDT 2012
On Mon, Mar 26, 2012 at 4:31 PM, Keith Packard <keithp at keithp.com> wrote:
> On Mon, 26 Mar 2012 16:13:46 -0700, Jeremy Huddleston <jeremyhu at apple.com> wrote:
>> Most functionality of these servers can be provide by Xorg with either
>> the nested or dummy video driver.
+1 for deleting these obsolete DDXes. I'd suggest deleting Xdmx as well.
> I'm all for deleting the code. I would like to have some idea of what
> you mean by 'most' here -- is there any significant functionality which
> isn't provided by the xf86-video drivers?
I don't have a complete list, but here are some things.
Timothy Meade thinks there may be some bugs in xf86-video-fbdev
compared to Xfbdev, and had other complaints when I tried to remove
Xfbdev a year ago:
http://lists.x.org/archives/xorg-devel/2011-May/022177.html
Xvfb has -fbdir and -shmem options to allocate the framebuffer in a
mmap'd file or a shared memory segment, respectively. Surely nobody
cares? If somebody does, patches copying the code from Xvfb to
xf86-video-dummy should be easy to write.
Xnest has options for configuring the created window. Again, I doubt
anyone cares, but it's easy functionality to re-introduce in
xf86-video-nested if someone wants to.
I think Xephyr has support for some extensions that may not be
supported when using xf86-video-nested. Perhaps Xv and DRI? Or maybe
DRI support was in patches that never got merged, like the Xephyr XCB
patches.
Xdmx has a complicated GLX proxy to support indirect GL spanning
multiple ScreenRecs under Xinerama. It might be nice to find a way to
merge that into DIX or the xfree86 DDX. Bonus points if Mesa had a
multihead libGL that could delegate direct rendering for each
ScreenRec to an appropriate libGL. :-)
Generally, I think Xdmx may have support for some extensions that Xorg
doesn't support when Xinerama is turned on, and it'd be nice to copy
that over.
It might be nice to have backwards-compatibility shell scripts for the
replaced programs that convert their command-line arguments into a
suitable xorg.conf and then run the real server.
That's everything I can think of. I'm not convinced any of those are
worth waiting for before deleting these DDXes.
Jamey
More information about the xorg-devel
mailing list