On Thu, 2017-03-16 at 03:04 +0000, Emil Velikov wrote: > Your earlier reply mentioned that [you think that] xf86-video-nested > was a mistake without providing any justification why. It would be > great to have some information what is broken and/or architecturally > wrong with it or the other components mentioned just above. > > IIRC the only issues [with Xorg] pointed out so far were a) memory > consumption and b) providing a config file [via command line as > non-root]. With the latter being resolved IIRC.
xfree86 assumes that there's actual silicon (or something very willing to fake it, like vmwgfx or qxl) backing the screen, and that that device is in some way bound to the system's console. The first X-under- wayland driver was an xfree86 driver, and making that work involved changing the xfree86 core in a bunch of places to _stop_ making those assumptions (don't look at the pci bus, don't try to VT switch, get input from this other source, etc.). Why bother undoing those assumptions when you have a base class that makes none of them? A vaguely appropriate analogy (if we're considering only OpenGL) would be mesa/src/gallium. It's this whole other abstraction layer and maybe it buys you some things, but mesa/src/mesa is the real GL core and one does not need gallium to make a GL driver. You'd only use it if there were any benefit. And for hw/xfree86 there kind of isn't. Most of ScrnInfoRec (xfree86's subclass of ScreenRec) is stuff that should reasonably be in the base class. That it isn't is largely an artifact of the old regime, where the X Consortium releases were actually pretty boring, and though XFree86 was the thing most people ran there was not a lot of interest or effort in reducing the diff between the two, or moving useful functionality up to the dix layer. Which means the real goal, in terms of code annihilationism, is to rely on xfree86 less not more. We already have three nested servers. Xephyr and Xnest legitimately vary in their approach, one is an X11 proxy and the other owns its own pixels. Xdmx is largely a clever variation on Xnest, and they should converge in the future. What benefit does a nested driver for xfree86 add? Why increase dependence on a midlayer that shouldn't exist, and whose value is in assumptions that don't apply? Hence also my bafflement at people trying to build xfree86 on cygwin. You don't town the display, you don't own the input devices, why try to build a server that assumes those things? Darwin you could _maybe_ argue for, if >console at the login prompt still drops you to a text login, but even that's a reach because you'd still need to write new video and input drivers. - ajax _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
