[PATCH xserver] sdksyms: Tighten up the symbols we add to the magic table

[Adam Jackson]

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