[PULL to discuss] Remove kdrive, Xnest, and Xvfb

[Jamey Sharp]

On Tue, Apr 3, 2012 at 4:41 AM, Jon TURNEY <jon.turney at dronecode.org.uk> wrote:
> On 27/03/2012 05:09, Jamey Sharp wrote:
>> However, our capstone project that just finished was a start toward
>> replacing the XQuartz DDX with a stock Xorg server and a special
>> client, and I'm hoping that XWin can go the same direction.
>
> This is certainly the approach I'd like to take, as well, rather than stuffing
> all the WM integration code into a client thread inside the X server.
>
> However, replacing the Win32 native XWin (as opposed to an XWin built to use
> the cygwin layer) with the Xorg DDX seems like it would involve a non-trivial
> amount of work, in effectively porting the Xorg DDX to the Win32 API.

I'd be really interested to know how much of the Xorg DDX relies on
POSIX and how much is straight C. The module loader is an obvious
candidate for pain, but once you turn off stuff like the PCI layer
that doesn't matter on Windows, how much non-portable stuff is left?

I'm going to propose another student capstone project in a couple of
weeks, and I haven't actually decided what to ask the students for
yet. If you can sort out pretty soon how much work is really involved
here, we could try getting a team of five or six students to do it
over the next six months. If we go that direction, I'd also need one
or two XWin developers to co-sponsor the project with me, committing
to being available for the platform-specific questions I can't answer.
It'd help if you could get to Portland at least once during the
project, too...

>> http://cgit.freedesktop.org/xorg/lib/libxcwm/
>
> Thanks.  I know you have mentioned this project previously and I'll try to
> make the time to take a look at it.

Much appreciated!

> Is there a way to support hardware-accelerated GL in that arrangement?

I hope so. :-) First, write Mesa and Xorg video driver bits that use
the platform-native accelerated rendering APIs, but only allocate
off-screen video memory, even for Window objects. If you can do
DRI-like 3D rendering on Windows, then at least the really expensive
part of 3D rendering can be accelerated, even if the libxcwm-based
client still uses GetImage to read back the results.

(For extra bonus points, use the glamor library in this driver to
hardware-accelerate 2D rendering as well. Wheee!)

After that, if you can also provide an OpenGL texture-from-pixmap
extension, then libxcwm can replace the slow GetImage path with a
hardware-accelerated blit from the back-buffers the server owns to the
native windows created by the libxcwm-based client. Combined with the
Composite extension's NameWindowPixmap request, this is just like a GL
compositor such as Compiz. That gets you fast updates of any
rendering, 2D or 3D, onto the real display.

Implementing texture-from-pixmap is the tricky part, because it
requires that processes in different address spaces be permitted to
share textures. Linux DRI can do that; Jeremy tells me that given the
public APIs on OS X, it's tricky at best. Does Windows allow it?

Jamey