Don't build XF86Misc or XF86Vidmode in hw/xfree86/dixmod when it's been
explicitly disabled in configure, or we don't have the proto modules
installed.
Instead of removing the preference bit marking the hardware declared mode
preference, leave it in place and just move the user preferred mode to the
front of the list while marking it with the USERPREF bit which will cause it
to be selected by the initial mode selection code.
Hide getline call by checking for glibc. If not, use fgetln instead. Even
though this section is now #ifdef'ed for linux only, this should help make
it more portable if non-linux folks end up wanting it.
It contains static paths, fails to build on non-glibc, and apparently just
exists to support distributions managing binary drivers and open-source drivers
together. Also restores previous code for fallback to vesa if nothing is
detected.
Right now we default to "all" which gives us a situation much like before,
but when the "typical" option is implemented, we can change the default and
reduce the number of visuals the GLX module bloats the X server with.
Instead of the fragile setup where we filter the modes common between the
DDX generated GLX visuals and the DRI driver generated fbconfigs, we now
just take the fbconfigs returned by the DRI driver to be our supported set.
A lot of EDID writers apparently end up stuffing centimeters (like the
maximum image size field) into the detailed timings, instead of millimeters.
Some of them only get it wrong in one direction. Also, add a quirk to let
us mark the largest 75hz mode as preferred, which will often be used for
EDID 1.0 CRTs.
If none is present, a default one will be created. This will be attached
to either the first device section in the xorg.conf (allowing you to
specify something like using EXA without having a screen section) or a
default screen section if none is present in the file.
This will allow the screen to not explicitly have a device section. If
this is the case and there is a device section in the xorg.conf, the first
one will be used. If there is no device section at all, a default one will
be created that loads the automatically determined module.
This is what we're currently shipping in Debian. Enables the ability for
drivers to ship a text file listing PCI ID's they support, and have the
server read them on startup when no driver is specified. This works, but
isn't the final solution.
* hw/kdrive/ephyr/ephyr.c:
(ephyrInitScreen): try and detect when the host has no
DRI support. In that case, switch to the -nodri behaviour.
When in the -nodri case, make sure not to skip glx visual
initialisation.
* hw/kdrive/ephyr/ephyrinit.c:
(ddxProcessArgument): disabling visual init here
is bad because it gets disabled even when we want
to use software GL, leading to Xephyr :1 -nodri
crashing in mesa.
We can now launch GL or XV apps in any of the
Xephyr screens we want.
* hw/kdrive/ephyr/hostx.c,h:
(hostx_get_window):
(hostx_create_window): make these functions be screen
number aware.
* hw/kdrive/ephyr/XF86dri.c : fix some compiler warnings.
* hw/kdrive/ephyr/ephyrdri.c:
(ephyrDRIQueryDirectRenderingCapable),
(ephyrDRIOpenConnection),
(ephyrDRIAuthConnection),
(ephyrDRICloseConnection),
(ephyrDRIGetClientDriverName),
(ephyrDRICreateContext),
(ephyrDRIDestroyContext),
(ephyrDRICreateDrawable),
(ephyrDRIGetDrawableInfo),
(ephyrDRIGetDeviceInfo): in all those functions, don't forward
the screen number we receive - from the client - to the host X.
We (Xephyr) are always targetting the same X display screen, which is
the one Xephyr got launched against. So we enforce that in the code.
* hw/kdrive/ephyr/ephyrdriext.c:
(EphyrMirrorHostVisuals): make this duplicate the visuals of the host X
default screen into a given Xephyr screen. This way we have a chance
to update the visuals of all Xephyr screen to make them mirror those
of the host X.
(many other places): specify screen number where required by the api
change in hostx.h.
* hw/kdrive/ephyr/ephyrglxext.c: specify screen number where required
by the api change in hostx.h
* hw/kdrive/ephyr/ephyrhostglx.c: don't forward the screen number we
receive - from the client - to the host X.
We (Xephyr) are always targetting the same
X display screen, which is
the one Xephyr got launched against. So we enforce that in the code.
* hw/kdrive/ephyr/ephyrhostvideo.c,h: take in account the screen number received
from the client app. This is useful to know on which Xephyr screen we
need to display video stuff.
* hw/kdrive/ephyr/ephyrvideo.c: update this to reflect the API change
in hw/kdrive/ephyr/ephyrhostvideo.h.
(ephyrSetPortAttribute): when parameters are not valid
- they exceed their validity range - send them to the host anyway
and do not return an error to clients.
Some host expose buggy validity range, so rejecting client for that
is too harsh.
* hw/kdrive/ephyr/hostx.c,h:
(hostx_has_xshape),
(hostx_has_glx),
(hostx_has_dri): added these new entry points
* hw/kdrive/ephyr/ephyrdriext.c:
(ephyrDRIExtensionInit):
check presence of DRI and XShape extensions before
trying to use them.
* hw/kdrive/ephyr/ephyrglxext.c:
(ephyrHijackGLXExtension):
check presence of glx extension before we use it.
* hw/kdrive/src/Makefile.am: use fb/fbcmap_mi.c
and not fb/fbcmap.c. This allows kdrive to take advantage of
extensions redefining the entry points of micmap.c stuff.
For instance it allows Xephyr to have a working GL, which is not
possible otherwise, because GL redefines mInitVisualsProc
to initialise its visuals.