If a given output is passed via new -output option, Xephyr will query
host X server for its info. If the following conditions are met:
a. RandR extension is enabled in host X server;
b. supported RandR version in host X server is 1.2 or newer;
c. the given output name is valid;
d. the given output is connected;
then Xephyr will get output's CRTC geometry and use it to set its own
screen size and origin. It's just like starting Xephyr in fullscreen mode,
but restricted to the given output's CRTC geometry (fake "Zaphod mode").
This is the main feature needed for Xephyr-based single-card multiseat
setups where we don't have separate screens to start Xephyr in fullscreen
mode safely.
Signed-off-by: Laércio de Sousa <laerciosousa@sme-mogidascruzes.sp.gov.br>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
With this patch, one can launch Xephyr with option "-screen WxH+X+Y"
to place its window origin at (X,Y). This patch relies on a previous
one that extends kdrive -screen option syntax to parse +X+Y substring
as expected.
If +X+Y is not passed in -screen argument string, let the WM place
the window for us, as before.
Signed-off-by: Laércio de Sousa <laerciosousa@sme-mogidascruzes.sp.gov.br>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This patch enhances current -screen option parsing for kdrive-based
applications. It can parse strings like
<WIDTH>x<HEIGHT>+<XOFFSET>+<YOFFSET>, storing X and Y offsets
in KdScreenInfo instances.
For negative values, this patch supports +-X+-Y (not -X-Y) syntax.
It will allow e.g. proper Xephyr window placement for multiseat
purposes.
Signed-off-by: Laércio de Sousa <laerciosousa@sme-mogidascruzes.sp.gov.br>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Nobody was using it.
v2: Merge the hunk that was accidentally in the previous commit into
this one.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
v2: Fix accidentally squashed-in change for dropping client from the
arguments, which should have been in the next commit.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com> (v2)
Privates are initially cleared to zero by dixInitPrivates().
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
It's been unused since mach64 was deleted, and now there's a helper in
core XV.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
XV was going against convention by having the core infrastructure
allocate the private on behalf of the DDX. I was interested in this
because I was trying to make multiple pieces of DDX be able to
allocate adaptors, and that wasn't going to work if DDX-specific code
was hung off of a single global screen private.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
The core was passing pointers to pxvs's nAdaptors and pAdaptors, and
the two hardware implementations were copying pxvs's nAdaptors and
pAdaptors into those pointers.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Since any DDX XV screen cleanup would need this same code for freeing
the tree of pointers for xv adaptors, move it to the dix.
v2: Unconditionalize the pPorts freeing, to match the block above it.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com> (v1)
As far as I can see, nothing has ever used this flag except possibly
the i.mx6 xorg ddx debug during bringup.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
As far as I can see (looking at trees on my disk, plus googling for
the term), nothing has ever used this flag
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
All users of glamor had the same value set, and it complicated things
for no reason.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
The usual mechanism for freeing a damage structure when the pixmap is
destroyed does not work for the screen pixmap as it isn't freed in the
normal way.
The existing driver cleanup function, scrfini, is called after the
wrapped CloseScreen functions, including damageCloseScreen, are called
and thus ephyr can't free the damage structure at that point.
Deal with this by providing an early CloseScreen hook in KdCloseScreen
which ephyr can use to free the damage structure before damage itself
shuts down.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
This should be useful for glamor development, so you can test both
paths (which are significantly different, and apparently
glamor_gradient.c was broken on GLES2 as of the import).
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The difference between the two is that XF86 has the clip helper that
lets you upload less data when rendering video that's clipped. I
don't think that's really worth the trouble, especially in a world of
compositors, so I've dropped it to get to shared code.
It turns out the clipping code was broken on xf86-video-intel anyway.
To reproduce, run without a compositor, and use another window to clip
the top half of your XV output on the glamor XV adaptor: the rendering
got confused about which half of the window was being drawn to.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
No code modifies it at runtime, and it's common to store string
literals to it.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Now that we don't have to worry about the generic adaptors code,
there's no need to have a list of pointers to different sets of
adaptors.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
glx will sometimes select a non-root visual, deal with that by
creating a suitable colormap and using that instead of attempting to
use the default colormap.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
I'm not sure what we'd do in this case anyways, other than fatal
error.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Make it clear that we intentionally ignore the -switchCmd return
value. This keeps GCC from emitting a warning when the server is
compiled with -D_FORTIFY_SOURCE=2.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
This reverts commit b5a61239e2.
Not only did I screw up and introduce a warning, it turns out
glXChooseFBConfig() explicitly ignores this attribute. Thanks, GLX.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Build fbcmap_mi.c once, rather than once for each DDX, and make it part of libfb
or libwfb convenience library.
Since 84e8de1271 we don't have fbcmap.c
This is a sort of revert of 17d85387d1
v2: Remove libkdrivestubs.la from configure.ac
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Gaetan Nadon <memsize@videotron.ca>
The XResizeWindow call wasn't replaced by the xcb equivalent, so we
were no longer setting the initial window size, only wm size hints.
Regression from commit a2b73da "Xephyr: start converting hostx.c over to
xcb"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74849
Signed-off-by: Julien Cristau <jcristau@debian.org>
Reported-by: Laércio de Sousa <lbsousajr@gmail.com>
Tested-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
Glamor has a mode where pixmaps will be constructed from numerous
small FBOs. This allows testing of the tiled pixmap code without
needing to create huge pixmaps.
However, the render glyph code assumed that it could create a pixmap
large enough for the glyph atlas. Instead of attempting to fix that
(which would be disruptive and not helpful), I've added a new pixmap
creation usage, GLAMOR_CREATE_NO_LARGE which forces allocation of a
single large FBO.
Now that we have pixmaps with varying FBO sizes, I then went around
and fixed the few places using the global FBO max size and replaced
that with the per-pixmap FBO tiling sizes, which were already present
in each large pixmap.
Xephyr has been changed to pass GLAMOR_CREATE_NO_LARGE when it creates
the screen pixmap as it doesn't want to deal with tiling either.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Looping around LoadExtension() meant that ExtensionModuleList was reallocated
on every extension. Using LoadExtensionList() we pass an array thus the
function can do the reallocation in one go, and then loop and setup the
ExtensionModuleList.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
v2: Update ephyr [Keith Packard]
v3: Eliminate const warnings in LoadExtensionList [Keith Packard]
Signed-off-by: Keith Packard <keithp@keithp.com>
This hasn't actually been a problem, since the server hasn't allocated
any glyphs before our glyph private initialization during
CreateScreenResources. But it's generally not X Server style to do
things this way.
Now that glamor itself drives both parts of glyphs setup, DDX drivers
no longer need to tell glamor to initialize glyphs. We do retain the
old public symbol so they can keep running with no changes.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
Fixes misrendering with cairogears. I had noticed the failure while
trying to figure out what was going on with traps. Cairogears was
apparently putting its results on the screen through putimage, which
is a texture upload, so the last GL drawing was done to the size of
the cairogears window, not the size of the xephyr screen.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
It broke after commit 9fe052d90c
"xephyr: Build support for rendering with glamor using a -glamor
option."
See http://tinderbox.x.org/builds/2014-03-07-0004/logs/xserver/#build
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
This is the same thing that Qt ended up doing to get DRI2's event
mangling to happen despite using an XCB event loop.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
v2: Avoid making the Ximage for the screen that we'll never use, and
drive the screen pixmap creation for glamor ourselves.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com> (v1)
Reviewed-by: Adam Jackson <ajax@redhat.com>
Any time the colormap is changed, the entire screen needs to be
repainted to match.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This lets us stop using the 'pointer' typedef in Xdefs.h as 'pointer'
is used throughout the X server for other things, and having duplicate
names generates compiler warnings.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
I'm not sure why ephyr thinks that ddxUseMsg shouldn't return, but
it's not declared to exit.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Xephyr wants ctrl+shift to grab the window, but that conflicts with
ctrl+alt+shift key combos. Remember the modifier state on key presses and
releases, if mod1 is pressed, we need ctrl, shift and mod1 released
before we allow a shift-ctrl grab activation.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>